Some general questions

[AndreasEntscheffPinter]

Hello 🙂

I already was successful in installing byodc in a goole cloud kubernetes cluster a few weeks ago.
I created everything needed in the sandbox portal (cashbox 23ca4176-7c93-40ae-8a15-ab2b1276c522) and connected the queue for this to a test-database-server using the mysql-connection-string. My tests all went well.

Yesterday I wanted to create the production environment. So I created a completely new kubernetes cluster at google cloud. I did exactly the same steps as weeks ago by using the notes I took then. To test it I just changed the mysql-connection string for the existing cashbox 23ca4176-7c93-40ae-8a15-ab2b1276c522 in the sandbox portal to point at our production database server. (Of course I did rebuild configuration at the cashbox after that).
When I tried sending the Cashbox Restart request (/api/Echo) I saw mysql-connection-timeout errors in the container logs.

I assumed firewall issues between the cluster and the db-server and played around with that a bit, but I was not successful.
So I tried setting another mysql-connection string at the queue that points to the test-database-server again that already worked before, to check, if there's a problem in general with my cluster. (Again I clicked rebuild configuration at the cashbox after setting the new mysql-connection-string). I still saw the myql-connection timeouts in the container logs. After checking things for around 1 hour I gave up.

This was all yesterday. Today in the morning I just clicked the Cashbox Restart request (/api/Echo) again without doing anything else and it suddenly worked. I also could send the Initial Operation Receipt. It seemed to use the test-database-server now.

Question(s) 1:
Is it possible that the change of the mysql-connectionstring was just processed somewhen during the night? Or is this maybe just taking very long in general? If yes, what can I expect here, 2 hours, 3 hours...?

Question 2:
The helipad baseurl in the config file I used to create the cluster is https://helipad-sandbox.fiskaltrust.cloud.
What would be the correct url to use if we go live, is it just https://helipad.fiskaltrust.cloud without the "sandbox"?

Question 3:
Did actually something change in byodc that makes it use more CPU/memory now? This time I needed to adjust the CPU value a bit in the config because I got an insufficient CPU/memory error in my google cloud container. I didn't have to do this a few weeks ago when I tested this the first time.

[ghost]

Hi Andreas,

let me please address them one by one

Is it possible that the change of the mysql-connectionstring was just processed somewhen during the night? Or is this maybe just taking very long in general? If yes, what can I expect here, 2 hours, 3 hours...?

This should be a more or less instantaneous change but it still requires a restart of the middleware. You mentioned you did rebuild the configuration, but did you restart as well?

Reason behind that is, the rebuild creates a new configuration object for that cashbox (based on the available settings) but only the restart lets it take actual effect on the cashbox instance, as this is when the cashbox actually fetches the newly built configuration data.

What would be the correct url to use if we go live, is it just https://helipad.fiskaltrust.cloud without the "sandbox"?

That's absolutely correct. However what is the motivation for your question? Is this rather about some network settings or are you planning on manually modifying the configuration? If it was the latter, I'd advise against that as the sandbox and the production are two completely separated environments and you can't just move it from one to the other and if you download a production launcher, that will already come with proper hostnames.

Did actually something change in byodc that makes it use more CPU/memory now?

Did you update any of the package version in-between?

[AndreasEntscheffPinter]

@fiscoal
Hi Alexander 🙂 Thanks for your reply!

This should be a more or less instantaneous change but it still requires a restart of the middleware. You mentioned you did rebuild the configuration, but did you restart as well?

No, I didn't restart the middleware! Didn't think that this could be the solution, thank you.

What would be the correct url to use if we go live, is it just https://helipad.fiskaltrust.cloud without the "sandbox"?

That's absolutely correct. However what is the motivation for your question?

I already tested everything weeks ago using a test-db-server and test-cluster at our side and the sandbox portal at fiskaltrust side.
Now I want to set up a production environment that uses a different db-server and cluster. But before we let customers use this environment I wanted to do a last test with the existing sandbox-cashbox.

... are you planning on manually modifying the configuration? If it was the latter, I'd advise against that ...

Actually I AM planning to manually modify the configuration. I followed the instructions at https://github.com/fiskaltrust/product-de-bring-your-own-datacenter to create byodc in a google-cloud kubernetes cluster.
To get the configuration file I did...
helm show values fiskaltrust/bring-your-own-datacenter > config.yaml
and then I installed doing...
helm install bring-your-own-datcenter fiskaltrust/bring-your-own-datacenter --namespace bring-your-own-datacenter -f config.yaml
My plan for setting up the production cluster is to just modify config.yaml and put in the production helipad.
Then create the cluster completely newly with that configuration.
What speaks against that?
My current test-cashbox at the sandbox portal will be abandoned - real customer cashboxes will get set up at the production fiskaltrust portal. Our fulfillment team will set up the cashboxes for customers in the production portal and as I understood it, they will just put in the mysql-connectionstring that points to our production-db-server into the queue-configuration and everything should work fine.
I hear the first time about "downloading a production launcher" - I don't think we need a launcher (but I'm a bit unsure now).

For clarification, let me explain briefly what we need (and what I already tested successfully at the test-environment I created) - maybe I understood something wrongly and the setup process works completely different for production than for the sandbox (but then... what's the sandbox worth if it's a completely different thing?):
Our software is cloud-software running at a webserver in our google-cloud-environment and our german customers will use a client that's provided by us. The customers need fiskaltrust to sign receipts. When they sign a receipt, the client sends a request to our webserver. The webserver calls the fiskaltrust middleware (that's also sitting in the same google-cloud-environment) to sign the receipt. The customer can then use the client again to retrieve a PDF from the webserver with the QR-code. All data and data-processing is done at our database-server that's again sitting in the same google-cloud-environment, so the whole cashbox is at our side.
I think a "launcher" is only need if the cashbox is running at the customers location, isn't it?

Thanks for your help and support in advance 🙂 Andreas

[ghost]

No, I didn't restart the middleware! Didn't think that this could be the solution, thank you.

No worries :), but yeah, a change in the configuration always requires a restart to take effect.

Actually I AM planning to manually modify the configuration. I think a "launcher" is only need if the cashbox is running at the customers location, isn't it?

Apologies, my bad, I completely skipped the cluster part. Yeah, the launcher part is when you run it as standalone setup. In your case changing the configuration directly should also work, please just keep in mind, the sandbox and production really are two different environments and you'll also need to adjust the cashbox IDs and access keys. Apart from that, the sandbox hostnames are all suffixed with -sandbox, so your take on Helipad was correct.

[AndreasEntscheffPinter]

Thanks @fiscoal for your quick reply!
Then everything is clarified from my side 🙂
Wish you a good weekend, Andreas

[ghost]

Thanks, great weekend to you too.