On Tuesday, May 1, 2012 1:17:53 PM UTC-4, Daniel Pittman wrote: > > 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.)
It seems that we can make the same argument for all of Hiera. The goal with the save API is to provide a simple interface for saving data, just like looking up data. When users write backends they can implement the save method however they see fit. > > > 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? > The save method works for a specific backend + source (level in the hierarchy) combination. Basically the reverse of the lookup operation. > > 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? > Seems we have the same issues we have with the lookup method. > > 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? Great suggestions, this can be added. > > > > 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. > No problem back to the drawing board. > > -- > 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 view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/b066b29TIwYJ. 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.
