Issue #9051 has been updated by Daniel Pittman.
List of things and places that interact with the StoreConfig engine directly in the product, to work to build an API around this: * `:async_storeconfigs`, `:thin_storeconfigs`, in `defaults.rb`, which enable specific features of the tool. No change expected. * `:storeconfigs` in `defaults.rb`, which enables the core feature. Triggered to be true by the previous set. * `lib/puppet/face/node/clean.rb`, which interacts directly with the ActiveRecord code to delete / unexport content. * `lib/puppet/indirector/catalog/compiler.rb`, which configures the backend during compilation if `:storeconfigs` are enabled. * same file, `update_node_check`, which I can't trace an invocation of... * `lib/puppet/parser/collector.rb`, which does collection from various sources; needs to go through the API rather than direct to Rails. * `lib/puppet/parser/ast/collexp.rb`, which does the syntax transformation to "rails" from the input language. * `lib/puppet/application/queue.rb`, which hard-codes the target when using async storeconfigs. Defining the API for StoreConfig backends: * add a configuration option for the storeconfig backend / terminus. * update existing code to select a `storeconfigs` terminus, not `active_record`, when activating storeconfigs. * write the `storeconfigs` terminus for each class so that it references the configuration option, then picks the right terminus to wrap. * ensure that the Rails-specific bits are pushed down into the target, rather than the AST (for collection) * push the query into the API; perhaps "find" from an indirection, to return the data. Then we have an API for the final target: * save and find over `catalog`, `facts`, and `node` indirections that works with the storeconfigs terminus. * find over the collected resources through a separate indirection. Alternatively, we could define a sound API over the interface we want – something that supports set and get over catalog, facts, nodes, and collecting resources. I would reach for a face, but the design we received makes it very difficult to do that cleanly; because they are forcibly instances of a class, rather than a class proper, we would need to define a custom API for the back-end, plus replicate all the work the indirector does around configuration, discovery, and loading of terminus instances. Advice? I don't like splitting this code into a dozen places, but we can't pack it sanely into the indirection API without substantial contortion. (eg: a protocol for doing three or four things through a single method, using some dependent dispatch key.) I lean toward defining a sound API through subclassing, then writing the huge pile of terminus classes to support that, and living with the need to select a backend implementation by hand. (eg: define `Puppet::StoreConfigs` and `Puppet::StoreConfigs::ActiveRecord`, then have the parent manage the API so that you get the concrete child instance when you ask for something implementing the API.) ---------------------------------------- Feature #9051: StoreConfig backend is hard-coded; it should be possible to change to another storage engine. https://projects.puppetlabs.com/issues/9051 Author: Daniel Pittman Status: Accepted Priority: Normal Assignee: Daniel Pittman Category: stored configuration Target version: 2.7.x Affected Puppet version: 0.22.1 Keywords: Branch: At the moment the StoreConfig backend is hard-coded within Puppet to use an ActiveRecord based database store. It would be great to be able to easily substitute in a new storage engine without having to patch the core, ideally in the same way you can pick another terminus for the `node` indirection to integrate with your ENC. This needs to provide feature parity with the current feature. -- 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.
