On Mon, Apr 11, 2016 at 8:35 AM, John Bollinger <john.bollin...@stjude.org> 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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
