On Sat, Jan 18, 2014 at 8:17 AM, Felix Frank < felix.fr...@alumni.tu-berlin.de> wrote:
> Hi, > > fascinating discussion. I think I can amend to Jason's point of view. > > On 01/15/2014 04:25 AM, Jason Antman wrote: > > it loses Puppet's native ability to > > log and report on changes to individual resources. The ability to easily > > see when a given package is upgraded, or what version it's at, across an > > entire infrastructure is incredibly powerful. Wrapping all of that up in > > one defined type loses the data that comes along with native types, and > > is so wonderfully easy to extract from PuppetDB. Also, though It's a bit > > Right, strucutring venv support like this would be saying "no, we don't > manage packages in venvs. We manage whole venvs with all aspects". > > This would encourage workflows that spawn lots of venvs, potentially up > to one dedicated one per task. This is wasteful of course, and... > > I've been watching this thread with interest. Sorry that I didn't chime in sooner. I think that what we are hitting here is just a limitation of puppet's ability to describe systems. What I think is missing is any idea of an independent container. Within a given container everything needs to be unique, but between containers you can have duplication. Each container has certain properties that describe the container and would need to be accessible from the managed resource while puppet executes. Containers could be used to model the python virtual environments, different gem install locations, etc. I think they would also be useful for modeling different hosts where each host is a container and then you have a catalog that includes the entire infrastructure. This is just an idea that I'm throwing out there right now. > > of an oddball issue, (c) I currently have use cases where puppet needs > > to install packages in an already-existing, non-puppet-managed > virtualenv. > > ...would be very inconvenient. > > When I read this exchange, I felt reminded of [1] and its predecessor > [2]. Reviewing [2], I stumbled upon [3] and [4], which is apparently > close to what you're trying to do. > > If I were to pick, I'd see [1] solved first. This might make your case > easier to implement. As far as I can see, it still won't address the > issue of the shared namevar across venvs. > > Isn't this similar to installing both a dpkg/rpm package and a gem > called, say, "puppet"? Is that currently possible? Generically, this > would likely be approached by a "name" parameter that allows the > resource title to be different from the package name. > > [1] https://tickets.puppetlabs.com/browse/PUP-1183 > [2] http://projects.puppetlabs.com/issues/4113 > [3] http://projects.puppetlabs.com/issues/18029 > [4] https://tickets.puppetlabs.com/browse/PUP-1071 > > -- > 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 puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/52DAA900.6040200%40Alumni.TU-Berlin.de > . > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXui4cA9JaxS%2BYJeaKC2OPwvYGWW0FjYAzitFK2HoJ51zA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
