integrate functionality for managing and updating global units

[puja108]

basically look into if we can somehow integrate what we did in https://github.com/giantswarm/fleet-unit-replicator

[xh3b4sd]

I would like to talk about that. So lets assume I have a fleet cluster running having three machines in it. Then I am starting a global unit that is scheduled to each of the three machines. Now I want to update the global units. There are different cases and needs possible.

I don't care, just update the shit

I have no concerns whatsoever. The only thing I want to achieve is to update the units. This rather special case is currently no problem and can be done by fleetctl itself already. The update command of inagoctl is moire comfortable here, but anyway. This kind of update works.

one after another

I have concerns about updating all units at the same time, so I want to update one unit, check if everything is good, and go ahead with the update procedure. Unfortunately that is the nature of global units. The Global=true feature of fleet is not sufficient here. We would need to schedule and maintain a dynamic number of units to always fit the number of available machines in the cluster. This approach would work, but does not work only using a command line tool. Some daemon would be required to watch events happening during the lifetime of my "global" units I want to run and update in a smart way.

rolling update

I have concerns about downtime in general. My setup needs to provide HA. Here we have the same problem as above. Fleet's Global=true feature is not good enough. There needs to be an authority that watches and does things.

As we see there is probably no simple solution we can provide using inagoctl. What do you guys think? Lets have a talk. @JosephSalisbury @zeisss @Nesurion

[JosephSalisbury]

I think this ticket has the potential to expand into a "do we want to have a client-server architecture" discussion. I'd say it'd be a good idea to collect some examples of cases we would like to support in the future (this is one of them), and see what that looks like for future design.

[JosephSalisbury]

Instead of trying to decide this inside this issue :D

[xh3b4sd]

Other points coming to my mind.

• Lock actions on resources to e.g. prevent concurrent updates of the same slices.
• Get slice identification right by using a centralized store.

[hectorj2f]

+1 on this feature ;)