On Fri, Feb 21, 2014 at 8:55 AM, James Sweeny <[email protected]>wrote:
> On Fri, Feb 21, 2014 at 2:41 AM, Joshua Partlow < > [email protected]> wrote: > >> Hi folks, >> >> (TL;DR: in 3.5.0+ environments will change to be named directories with a >> specific structure and configurable defaults, all to be found in a >> configured 'environmentpath') >> >> snip > >> You can also enumerate the new directory environments via the v2.0 API >> endpoint (/v2.0/environments) that Andy and Dan worked on. (see >> https://github.com/puppetlabs/puppet/blob/master/api/docs/http_environments.md) >> Command line enumeration of environments is targeted for 4.0. >> >> The epic for the environment work is: >> https://jira.puppetlabs.com/browse/PUP-536 >> >> Please let me know if I made any mistakes about existing functionality, >> or you have any questions or suggestions for us with regards to the >> directory environments. >> > > snip some more > Hi Josh/Andy/Henrik, > > Could you please provide some background on why this change is being made, > and what the benefits to the user will be? If this is just to make it > easier to support future APIs, I'm curious to know why we need to change > the UI. > I'm not sure which parts of the description you are referring to, but I'll take a stab at giving some background on parts of it. The original request came from the Puppet Labs PE team, where they want to be able to make the PE UIs aware of the environments. In order to do that there needs to be a list of environments for them to present to the user. The current way that puppet handles environments make this very difficult, or impossible, since there is no single list of environments that it can just pull up. There has been talk in the past about separating environments out into something separate from the puppet.conf file. Those ideas about separating out environments lead to a system where we can enumerate all of the environments that are available and so provide the functionality that was requested. Now you might wonder why not just do something like doing some querying of the filesystem for module directories and manifests with a $environment set to *? The reason is that even that wouldn't get us a correct list of environments. There are too many variations and corner cases. Also there is another problem in which *any* name, no matter if there is something that shows up on the filesystem, can end up being a valid environment. So that would have just led down a path of corner cases, unclear definitions of what constitutes an environment, and misery. The reason for the layout of directories is because it closely matches what was already a common practice for dynamic environments. So really what we are doing is more closely modeling what was already done. The reason for the /v2.0/environments REST endpoint is because we've wanted, for a long time, to separate the internals of how puppet is implemented, from the external facing API. The current endpoints that feed into the indirector all have to follow a specific pattern, don't provide any layers between the network and the internals, and have caused us a lot of pain (security issues, usability issues, code maintenance issues). Since this work was to provide a way of querying the master for all of the environments, it seemed like a natural time to get a new system in place. I felt it was a little absurd that in order to query for the list of environments from the current API, you'd have to construct a path that includes an environment and a key that isn't needed (since all indirector paths are of the form environment/indirection/key). So the new API is a way of breaking free and letting us follow well trodden API design principles. Note: v2.0, as opposed to v2, was decided upon because it isn't a valid environment name, which means we can unambiguously distinguish it from an environment and therefore a request for the old system. As for benefits to users. I think there will be many, but I'll just stick to how the new environments are laid out on disk. By laying out environments like this it creates nicely self-contained segments of puppet code. Each environment can be understood on its own by simply looking at what is in that directory. It puts environments on a similar level of modules. It adheres to a common structure, is found and loaded in a common way, and contains information to describe itself. I foresee a future in which we can even manipulate environments (or rather the code and configuration that installed into environments) as artifacts that are versioned, promoted, etc. just like we can with modules. I hope that gave some background to where these changes came from. If not, let me know :) > > Thanks, > > - James > > -- > > James Sweeny > Professional Services > http://puppetlabs.com/ > > > *Join us at PuppetConf 2014, September 23-24 in San Francisco - * > http://bit.ly/pupconf14 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAKDACKtqykjQnJEJzFMO%2B8du%3D-AOwRiU9V-jKJrFceb0m1Hb%3DA%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco - * http://bit.ly/pupconf14 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXsekg4pM5r87MCFb5_i73ou%2BAYxOdtwazVmU4r9KTYctg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
