On Tue, May 1, 2012 at 5:52 PM, Kelsey Hightower <[email protected]> wrote: > On Tuesday, May 1, 2012 1:32:05 PM UTC-4, R.I. Pienaar wrote: >> ----- Original Message ----- >> > From: "Daniel Pittman" <[email protected]> >> > To: [email protected] >> > Sent: Tuesday, May 1, 2012 6:17:53 PM >> > Subject: Re: [Puppet-dev] Hiera should have an save API >> > >> > On Tue, May 1, 2012 at 09:31, Kelsey Hightower >> > <[email protected]> wrote: >> > >> > > I'm thinking of adding a new save API to Hiera. The idea is that Hiera >> > > should provide an iterface for saving data, which should make it easy for >> > > front-end tools to interact with backends that support saving data. >> > >> > Why does it make it any easier than having tools with already know >> > about their back-end semantics directly managing that data? It has >> > substantial limitations (eg: no user concept, no credentials, and no >> > way to determine the appropriate set based on the back-end.) >> >> This has been my main concern too and why I never implemented anything >> like this in the first place - I think the data being queried is best >> modelled >> elsewhere. The data is best created at the time when you classify a node in >> that same >> UI - hiera should query that data but not know too much about the visual >> aspects of it. > > If this is the true goal of Hiera then we should call this out. I agree with > all these points if the goal of Hiera is to be a read-only tool.
...or, perhaps, we should say that *this query API* is a read-only abstraction, inappropriate for writes, even if the Hiera project includes mechanisms to update data that are different to the query mechanism. >> This would be usable for small installs who just use the json/yaml >> backends and have no node classification system (other than maybe hand >> editing these >> files and using hiera_include or something). People who are already happy to >> just hand hack JSON/YAML anyway. > > This would be nice for other backends like the redis one as well. But I > guess it would be simple enough to delegate the responablity to the end-user > to build a full > solution, kinda like the ENC model :) > > I think it would be helpful to give users the ability to use Hiera as an > abstraction layer for reads as well as writes. Hiera provides a really simple > way of doing > things based on key/value pairs, backends, and sources (namespaces) in the > hierarchy. I > consider this a big win for "small" or simple use cases. I think users > with larger or > complex installs would perfer writing an ENC vs using Hiera at all. Longer term that is, I think, a false dichotomy: small and large sites want to classify nodes, and to bind data to manifests. They don't want different tools to do that, they just want it to work. We can absolutely satisfy both, and should seek to do so in a way that scales when someone moves from being "small" to being "large". >> > The principal is reasonable, but this isn't even close to a proposal >> > for a save API that works in the real world. >> >> I would love to see a solution for this but its deceptively hard to do >> and I think ultimately better solved by exposing a REST API into your >> dasbhoard/foreman/etc where you have RBAC and the other points you >> raised > > The idea is that this simple save function would be behind a REST API like > the one you mention. Do the hard work of modeling and capturing data then > make a call to Hiera#save. If a REST API for Hiera is needed we can build > one. ...but the save function proposed is too abstract from the reality of data storage to be able to do that. Each backend needs additional context - or someone to write a custom back-end for their site, ever time - to be effective. This is a good idea, but at the wrong level of abstraction. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
