Thanks Marek, this is helpful. I'll work on an RFC to try and hash out some of the details.
On Tuesday, August 2, 2016 at 9:58:59 AM UTC-4, Marek Hulán wrote: > > Hello > > thanks for the write up. first of all - I find it useful. Not only for > users but > for plugin developers too. I encountered this scenario several times > already, > I'd like to extend ENC from plugin. For example in foreman_openscap we > provide > puppet module to configure scap client and we need to add the manifest to > all > hosts on which certain policy should be applied. In other words we need to > add > class and parameters for it into the ENC output. We would find the same > thing > useful in remote execution to configure ssh keys. > > So I wonder if we should add some helpers to Foreman core that would allow > register "mutators" and your plugin could use it and just add the UI that > allows adding rules that would add mutators. Or other plugins might depend > on > your plugin to use mutators. I lean towards that we provide such mechanism > in > core, so PRs against core would be welcome (from me at least). > > It might be worth of suggesting through our RFC repo - > https://github.com/theforeman/rfcs see PRs for examples > > Anyway let me know if I can help somehow with your effort. > > -- > Marek > > On Monday 01 of August 2016 10:36:11 Jon McKenzie wrote: > > Quite a while ago I posted a thread > > < > https://groups.google.com/forum/#!searchin/foreman-users/%22smart$20classes > > %22|sort:relevance/foreman-users/8BMaCeDXsM4/dVv5XSPqR7kJ> to the > Foreman > > Users group asking about the concept of "smart classes", i.e. the > ability > > to dynamically assign Puppet classes (similar to smart class parameters) > > depending on fact or other data. I didn't get any responses, and > > ultimately, our team ended up doing something > > straightforward and created hostgroups for each permutation of Puppet > > classes that we had in our environment (rather than sink development > time > > into solving the problem in a different way). Predictably, this has > become > > somewhat annoying to maintain as our environment has grown. > > > > I started thinking more about this recently, and came up with what I > think > > might be a workable solution to this type of requirement. Let me know > what > > you think. > > > > The basic problem is that Foreman's model for categorizing hosts is a > > little bit too rigid to handle certain use cases. For my environment, > there > > are two basic issues: assigning a class based on fact or parameter data, > > and removing inherited classes based on the same. I could imagine other > > scenarios as well, however, for example retrieving a class parameter > value > > from an external system (rather than storing it statically within > Foreman). > > > > For users who can't accomplish their host classification with the > builtin > > tools, there would be a "safety valve" of sorts -- a Foreman > administrator > > could define little bits of code that mutate the Foreman-generated ENC > data > > arbitrarily (sort of like ENC middleware), based on fact or other data > > about the host. This would work in the following way: > > > > The admin would define ENC "mutators" in a configuration directory, e.g. > > /etc/foreman/mutators.d. There would be a standard API for these > mutators > > that might look something like this: > > > > Mutator.create(:some_mutator_name) do |enc, facts| > > if facts[:ipaddress] =~ /^10\./ and > !enc[:classes].has_key?('some::class') > > enc[:classes]['some::class'] = nil > > end > > enc > > end > > > > (where `facts' is a hash of the requesting host's facts and `enc' is the > > standard ENC data returned by Foreman's node classifier) > > > > When the Foreman server boots, it would load these mutators out of the > > config dir. When a Puppet server requests ENC data for a host, Foreman > > would retrieve the ENC data as normal, and then run the mutators against > > that data in some configurable order. Each mutator would return the > mutated > > ENC, and this would be passed on to the next mutator in the chain. At > the > > end of the chain, the final ENC data would be passed back to the Puppet > > server to use for catalog compilation. (Optionally, a system could be > > established to allow the web UI user to pick and choose which host, > > hostgroup, etc. gets which mutator and what order the mutators should > run, > > but this would take a little bit more effort to implement). Ideally, the > > ENC data would be exposed in the web UI along each part of the chain so > > that operators can inspect and validate its correctness -- at the very > > least, a 'before' and 'after' image could be displayed. > > > > Before I start building something, I'd like to get some thoughts on this > > idea. Would other people find this useful? Are there other approaches > > people have tried and found successful? > > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
