Issue #7583 has been updated by R.I. Pienaar.
James Turnbull wrote: > Is there scope to use the same :confine model as Puppet? Would that be a > good solution? I'd love to see plugins in Puppet/MCollective become closer in > style at least. I did consider it of course but rejected the idea ultimately for a few reasons: In Puppet you have a clear feature list that you can check against - things like do you have rails etc - and the plugins tend to map well to these features. Not the case with mcollective as agents tend to have nothing to do with the internal abilities of the mcollectived. So the feature wise thing isnt really great In Puppet and Facter you have a clear set of facts, its a controlled system and today you know you should always have operatingsystem for example. This isnt the case in mcollective as the fact source is pluggable and as we know from recent devops-toolchain list discussions there's no hope of a unified fact view coming any time soon so there's nothing there for me to rely on fact wise. In fact I'd say my choice of samples are bad since facts is just an unreliable medium to use for confinement in mcollective so I am going to use something else in the eventual documentation for this feature. You have a few other things in the puppet confine system like for_binary etc but really its all too restrictive. MCollective agents can do a ton of things and can have any number of dependencies. You might have a agent running in a JVM that should only work if JMX is enabled. Or a agent that should ony work if some gem can be loaded etc. There really is so many cases of what you might want to confine on that there isnt much hope for the puppet model to map well into mcollective, things like: <pre> confine :exists => path, :for_binary => true </pre> Thats nice and all and appropriate for puppet but ultimately too restrictive for MC agent. And I'd say has been proven to be too restrictive even in facter - see how many facts like the ec2 one has more or less come up with its own confine system since the built in one has too many assumptions and not enough freedom. Next there's an established pattern in writing agents and how you declare hooks, authorization etc and this proposed model fits in better with the rest of the agent design. In the long run this will become more complex, when DDLs are ready by the servers too I will move this in there and I will then also create a per action validation system. You could have a package agent that can do yum clean and also apt-get update, you need to disable the apt related actions on redhat. In those cases I think there might well be some scope for something similar to the confine system - but probably more like how puppet validates if a provider should work or not really. And finally, I hate the word confine. ---------------------------------------- Feature #7583: Plugin Activation - Configuration and Supportability Checks https://projects.puppetlabs.com/issues/7583 Author: Ken Barber Status: Accepted Priority: Normal Assignee: R.I. Pienaar Category: Core Target version: 1.3.x Keywords: Branch: ripienaar/feature/master/7583 Affected mCollective version: MCollective plugins that exist on a system should have a mechanism for being enabled/disabled based on a) checks that the plugin does itself to make sure it _can_ run - like checking for any dependencies they need or b) a user defined switch in a configuration file somewhere. This way - we can distribute plugins on all systems using something trivial like Puppet pluginsync and have an administrator either disable/enable them selectively. It will also mean that plugins that could not possibly work - like an iptables plugin on FreeBSD - will disable itself. One technique would be to provide a method in the plugin called 'activate?' which when called returns a true or false. The abstract parent provides behaviour which checks a configuration file for example - but other checks such as searching for executables can also be done. We could also mimic the :contraint behaviour in Puppet providers for certain plugins to only work based on facts checks such as supported operating systems. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
