search

coreos / fleet

fleet ties together systemd and etcd into a distributed init system
Apache License 2.0
2.42k stars 302 forks source link

Define support for multiple MachineOf values #954

Open bcwaldon opened 10 years ago

bcwaldon commented 10 years ago

Per the systemd unit file spec, multiple MachineOf values can be defined in a unit file. fleet currently only respects the first value, ignoring the rest. From the user's POV, it is not clear what fleet is doing when multiple values are provided. This needs to be cleared up. There are a couple of decisions to make:

The first question to answer is that of allowing multiple values: yay or nay?

1) If we decide to support multiple values, does fleet then require that all values are matched when deciding where it can be scheduled, or at just one? 1a) Do we support the systemd convention of "clearing" the list by using an empty option? For example:

[X-Fleet]
MachineOf=foo.service
MachineOf=bar.sevice
MachineOf=
MachineOf=ping.service
MachineOf=pong.service

...would render to MachineOf=ping.service,pong.service

2) If multiple values are not supported, should we take the last value in the list, or stick with the first as we do today? systemd convention dictates the last should be used. Maybe the unit should just be be considered invalid if multiple values are provided?

crawford commented 10 years ago

Regarding your first point:

If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a logical AND is applied). Condition checks can be prefixed with a pipe symbol (|) in which case a condition becomes a triggering condition. If at least one triggering condition is defined for a unit, then the unit will be executed if at least one of the triggering conditions apply and all of the non-triggering conditions. http://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionArchitecture=

bcwaldon commented 10 years ago

So that seems to say that ConditionX and ConditionY must both be respected, but it doesn't really clarify what to do in the case that ConditionX is defined multiple times.

This also complicates things as MachineID basically trumps all other options, which is contrary to the "the unit will be executed if all of them apply" point.

bcwaldon commented 10 years ago

After some offline discussion, I'm leaning towards making MachineOf match a single value, which also means it shouldn't support glob-matching. This is for several reasons:

  1. once you want to use MachineOf to match multiple units, you're better off figuring out how to break those hard dependencies
  2. the original use-case of MachineOf was solely for sidekick units, which defines a single unit who is the batman unit to a given robin unit
  3. glob-matching implies a list of values, so that's not supportable if MachineOf is a single literal unit

systemd supports "clearing" an option by defining it with an empty value, but I do not believe our unit file parser supports this yet. We need to look into this.

To solve the original goal here of clarifying what happens when you provide multiple values for MachineOf, we should just reject unit files in the validator code if MachineOf is defined multiple times.

jonboulle commented 10 years ago

This also complicates things as MachineID basically trumps all other options, which is contrary to the "the unit will be executed if all of them apply" point

MachineID is mutually exclusive with other options so this isn't really an issue

bcwaldon commented 10 years ago

@jonboulle Does fleet actually reject units that have MachineID as well as other X-Fleet options in the validator?

I'm really just trying to point out that we've already diverged from what @crawford quoted.

jonboulle commented 10 years ago

Yes, it does. I agree there's an issue here, just wanted to be clear that we shouldn't have to worry about that particular rabbit hole