----- Original Message ----- > From: "Daniel Pittman" <dan...@puppetlabs.com> > To: puppet-dev@googlegroups.com > 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 > <kel...@puppetlabs.com> 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. 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. Having to know the hierarchy on the CLI isn't that great an experience and neither is typing complex data like hashes, arrays and such. In mcollective I can type complex data on the CLI because the DDL describes the data - I know when you typed "1" that it should be a number or a boolean and I convert that for you. Hiera has no data description, its free form so even with a face or whatever it just would be limited use - soon you'll be editing JSON or YAML again to represent arrays of hashes, thats wrong. > > It doesn't document anything of substance about the API: will save be > fast or slow? Can save deadlock? How does it differentiate > different operations on the same key? How do I determine the hierarchy - or > do > I need to implicitly know that to use this? This is impossible to answer - the save API has no idea about the backends. We *could* in theory extend backends to provide all these answers through some kind of flag about the backend but I do not think we should. Backends are easy to write and understand and so people do actually write them vs some other plugins we might have like providers or types. It's a pretty thin line. Its a case of could but imo should not. > > I have no idea how it works across machines. Can I use this from the > dashboard when that is installed on a different machine to the > master? > How do changes propagate after `save` is called when I have multiple > masters? > > It also makes it impossible to use this in any meaningful UI: there > is > absolutely no mechanism to determine what the failure was. Did we > fail because we got the hierarchy wrong, or the backend wrong, or > something else failed? Should I just retry, or give up? > > > Do people think this is a good idea? I see this as a foundational > > bit for > > building UI's on top of Hiera. > > 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 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
