On Monday, April 11, 2016 at 12:20:22 PM UTC-5, Michael Smith wrote: > > > > On Mon, Apr 11, 2016 at 8:35 AM, John Bollinger <john.bo...@stjude.org > <javascript:>> wrote: >
> 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? > There are really only two main alternatives from the perspective of Puppet's configuration model: 1. model the additional states on the existing resource type via additional properties or additional allowed values for existing properties, or 2. model resources in some states via altogether different resource types. The latter is appealing from a consistency perspective for handling resources with an immutable piece of state, such as systemd services having 'static' enablement status: if we take it as a matter of the definition of "service" that services are either enabled or disabled and can be switched between those two states, then it follows that a systemd 'service' unit that has 'static' enablement status is not, in fact, a "service" by our definition. More generally, it should be self-evident that no *immutable* piece of state is well modeled as a value of a *mutable* Puppet property. Where one does model an aspect of machine state as a property, Puppet should be able to determine whether that property is in sync, should recognize and accept that property being in sync, and should fail if it attempts unsuccessfully to change the property's actual value on a target node. This is what you suggested for PUP-5353; the problem there is that you also want to avoid a breaking change. There is a bit of grey area here, however, in that resource property values are not necessarily mutually exclusive. Consider, for example, the 'ensure' property of the Package or File resource type: if you ensure a File 'present' or a Package 'installed' then that encompasses several possible specific states. In fact, in the Package case, it encompasses an unspecified, unbounded, and perhaps unknown number of possible specific states for any given instance at any given time. Going back to systemd, the approach that both Trevor and I suggested is close to considering 'static' as a property value that is encompassed by both of the recognized states of the 'enabled' property. That's not quite what I described before, because the Service resource does not recognize 'static' enablement in its own right. It would also be novel in that as far as I am aware, it would make Service.enabled the only property I can think of that with recognized values that overlap without one subsuming the other. Nevertheless, it's not necessarily inconsistent to treat 'static' enablement as simultaneously both enabled and not enabled, as opposed to neither. I think it is inconsistent, however, to consider 'static' enablement as one of those but not the other. > 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. > > You could, of course, have Puppet emit a warning when it manages the enablement status of a service that initially has 'static' status. That would perhaps be better than accepting silently. Or perhaps not. The need to be able to answer a query for the state with exactly one of the two defined alternatives constitutes a bit of a sore spot, but I'm inclined to think that's the least bad alternative currently available. 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/e0509517-eaea-46ae-a1f8-de93549c2eb0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
