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. > 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. 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. For more options, visit https://groups.google.com/d/optout.
