> > > >> 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. > > Thanks, we ended up opting for logging a debug message when trying to disable 'static', and otherwise following Trevor and your suggestion. The conclusion is captured at https://tickets.puppetlabs.com/browse/PUP-5353?focusedCommentId=286407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-286407 .
-- 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%2B0%2By9TsOa_nEeJ0ERgOhfZ_SZe-3bkuX9XoJX64G7-bQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
