A question to Giant Swarm users regarding updating a service definition

Question.md

Dear users,

we have an important question for you regarding the improvement of one aspect of our product.

When you create a service on Giant Swarm using the service definition (usually in a swarm.json file), after creation of the service you currently can't modify your service.

We know that many of you want this to change. The question is, how would you like this to work?

1) Submitting new swarm.json

• The user modifies her/his swarm.json file as used by a running service,
• then executes the appropriate CLI command to apply this modified definition to the service.
• The backend creates an action plan about what has to change between the current service and the new definition. This plan may be shown to the user for confirmation.
• The plan is then executed.

2) Atomic Transactions

• We provide atomic commands/methods for changing specific parts of a service. Every possible change has some specific command grammar. Examples:
  • Adding a component mycomponent to service myservice: swarm update add-component myservice mycomponent
  • Adding an image setting to a component: swarm update set-image myservice/mycomponent myimage
• The user executes these commands according to needs.

Which approach do you prefer and why? Or do you have different requirements?

Please use the comment function here, send us an email to support@giantswarm.io or discuss in our Gitter chat.

If you guys add support for the second one, if I do swarm update add-component myservice mycomponent then swarm cat swacker will definitely show a different result from my local swarm.json. So it can cause problem if I like to push next time from scratch (because my swarm.json is not updated). In that case if you guys provide something like git, I think it would be great.
(Disclaimer: I don't have enough experience in micro-service or docker)

One use-case I am currently thinking about is adding an nginx in front of another component. How would you do that with the 2. approach? One would add-component the nginx, but how do you change the port mapped to your domain to the newly created nginx-component? Seems to me you would need to add a lot of commands and the user has to know about all of them and apply them in the correct order. The 1. approach would push that complexity to you guys having to implement that action-plan planner, but lowering the burden of the user.
My ideal approach would work something along the lines of database migration tools, like flyway, where I would specify changes to my architecture and check them into my repository, allowing me to see the versions of the infrastructure.