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 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? 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. -- 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.
