On Mon, Apr 11, 2016 at 8:35 AM, John Bollinger <[email protected]> wrote:
> > > On Thursday, April 7, 2016 at 1:44:47 PM UTC-5, Michael Smith wrote: >> >> PUP-5353 <https://tickets.puppetlabs.com/browse/PUP-5353> notes an >> inconsistency between the RedHat and Systemd providers (on EL7) in how they >> treat the `static` state returned by `systemctl is-enabled`. >> >> Based on the systemctl description >> <https://www.freedesktop.org/software/systemd/man/systemctl.html> of >> `static`, this is a disabled state that cannot be enabled because it has no >> "[Install]" section. >> >> On the other hand, `chkconfig` will return that the service can be >> started, which the RedHat provider interprets as being enabled. >> > > >> My interpretation of `static` is that enabling the service has no >> meaning, and trying to manage whether it's enabled should fail. It's enable >> status should report `static`. >> >> > > Let's be very careful here. I think part of the problem is that systemd > and Puppet have slightly different ideas about what "enable" means. In > particular, the core problem seems to be that Puppet assumes (not > unreasonably) that successfully "enabling" a service leaves that service in > the "enabled" state, whereas with systemd / systemctl, "enabling" a unit > that is initially in the 'static' enablement state is a no-op, and > therefore succeeds without changing the enablement state. > > In fact, although the docs describe 'static' enablement status as "not > enabled", it also is not 'disabled', as that is a distinct status. The > fact that systemd has ten (ten!) enablement statuses whereas Puppet > recognizes only two should be a big red flag. > The question of how to deal with more states (systemd's 10 enablement statuses), some of which can't be enforced, seems interesting. Have any thoughts on it? > > > >> My question for the mailing list is: >> - Which interpretation makes the most sense to Linux admins? >> > > > I quibble slightly with your interpretation. It is manifestly incorrect > to say that "enabling the service has no meaning," whether you're talking > about systemctl or (current) Puppet. I would say rather that enabling the > unit has no *effect* (though this relies systemctl's sense of "enable"), > and also that its status cannot be accurately captured by a non-nullable > boolean flag. > > Inasmuch as an attempt to enable a unit with 'static' enablement status > does not in fact effect a change in that unit's status, it could be > reasonable to interpret that as a failure -- the specified state is not set > -- but only if 'static' does not map to 'enabled' (which it currently does > not). > > One could argue that a systemctl unit with 'static' enablement status > should not map to any Service instance in the first place, as I suppose is > the case for units having either of the two 'masked' statuses. Such a unit > does not, in fact, represent a service in the normal sense. > > > >> - Would it be a breaking change to make it an error to manage the >> `enable` property of a service that can't be enabled/disabled? >> >> > > Yes, of course it would be. Catalogs that are now applied successfully, > albeit with vacuous changes, would instead fail. Note also that PUP-5353 > has an unreported dual: attempting to manage a 'static' systemd unit to be > *dis*abled currently succeeds without applying any changes (or so I > assume). That also would break. > > Moreover, if the behavior change you describe were implemented by > modifying the data type of Service's 'enabled' property, as you seemed to > suggest, then all Service providers, including custom ones, would break > (though perhaps the resulting flaws would not immediately be evident). > Consider also that if you define another distinct allowed value for > Service.enabled, then it should be possible to assert that value, even if > there is no way to change a service into that state -- it would not be > sensible for managing a 'static' unit to be 'static' to fail. > > Without regard to implementation details, it seems to me that the simplest > non-breaking fix for PUP-5353 would be to make 'static' enablement status > always be in-sync. This coincides with systemctl's dynamic behavior and > is at odds with Puppet's state-based model of the system, but there's no > non-breaking way to make Puppet Service resources model this aspect of the > state space of systemd units. If that approach sticks in your craw, then > you could consider refusing to map 'static' systemd units to Service > resources at all. That, too, would be a breaking change, but it's > conceivable that you would find it more acceptable. > > I err on providing more feedback when trying to do things that don't make sense - like apply Puppet's enable/disable states to a static service - but accept that this would make applying the same resource across multiple systems difficult. Making it always in-sync would work. Displaying the state as enabled if queried is probably the best fit for Puppet's concept of enabled/disabled, as it's check `systemctl is-enabled` returns 0 (enabled) for `static` status. > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/85d4437b-ea66-497d-b13a-a4d3f302ecc9%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/85d4437b-ea66-497d-b13a-a4d3f302ecc9%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CABy1mM%2BArMPofewm0%3D2PK8zLBK_8uUC4irq1vCZTU5eA_p01PQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
