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. > > 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. > 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. > This is a problem no matter what. Building a CLI tool for any data tool will have these problems. I can't see how this is specific to Hiera having a save function. We do not have to expose this via the CLI until we have a good solution. In the meanwhile people can use it through the ruby API. > > > > 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 vote to keep the save API as simple as the lookup one. We have the same issues about speed and errors with lookup, but people still find value with it. > > > > > 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 > 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. Thanks for the feedback on this by the way! -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/E7pEuLCyD7sJ. 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.
