Re: [Puppet-dev] Tiering platform's and providers in puppet's core

Sorry for falling behind on this thread. I've been working away on items for PUP-536 (PUP-1118 specifically) and am now incredibly behind on email. On Fri, Jan 17, 2014 at 5:48 PM, Jason Antman wrote: > Re: Deepak's message about community maintainers... that sounds > wonderful to me. I'm not su

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

Thanks for the clarifications. On 01/22/2014 11:51 PM, Michael Stahnke wrote: As such, for the benefit of the community, I'd suggest that anything that (a) isn't fully tested and vetted by PL (whatever that means) or (b) is known to be broken (i.e. naginator) be split out into t

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Tue, Jan 14, 2014 at 7:07 AM, Jason Antman wrote: > I thought I'd throw in my 2 cents, as a long-time puppet user, current > PE customer, and community member trying to make more code contributions... > > First off, this thread has been great. I was going to quote a few replies, > but there h

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

W dniu wtorek, 21 stycznia 2014 19:43:00 UTC+1 użytkownik Andy Parker napisał: > > On Wed, Jan 15, 2014 at 5:06 PM, Deepak Giridharagopal < > dee...@puppetlabs.com > wrote: > >> On Wed, Jan 15, 2014 at 2:20 PM, Andy Parker >> >> > wrote: >> >>> Ok, let me try to summarize the discussion so f

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Wed, Jan 15, 2014 at 5:06 PM, Deepak Giridharagopal < dee...@puppetlabs.com> wrote: > On Wed, Jan 15, 2014 at 2:20 PM, Andy Parker wrote: > >> Ok, let me try to summarize the discussion so far: >> >> * Tier1/Tier2 as a basic premise seems to be accepted as a good idea. >> * Tier2 code idea

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Sat, Jan 18, 2014 at 10:06 AM, Pawel Tomulik wrote: > > > W dniu sobota, 18 stycznia 2014 18:20:16 UTC+1 użytkownik Felix Frank > napisał: > >> On 01/16/2014 01:01 AM, James Turnbull wrote: >> > I think this is a broadly good idea but I've got one concern about the >> > on ramp to using Puppet.

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

W dniu sobota, 18 stycznia 2014 18:20:16 UTC+1 użytkownik Felix Frank napisał: > > On 01/16/2014 01:01 AM, James Turnbull wrote: > > I think this is a broadly good idea but I've got one concern about the > > on ramp to using Puppet. Whatever is done, pull out some/pull out all, > > the user e

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On 01/16/2014 01:01 AM, James Turnbull wrote: > I think this is a broadly good idea but I've got one concern about the > on ramp to using Puppet. Whatever is done, pull out some/pull out all, > the user experience of getting started with Puppet should remain > seamless or at least as good as it is

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

> I certainly agree with James' standpoint. However, as the set of people > at $work who commit to our internal puppet modules expands, I'm > constantly battling the vast amount of outdated information/tutorials on > the 'net. Keeping backwards compatibility with tutorials and blog posts > that nev

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

Re: Deepak's message about community maintainers... that sounds wonderful to me. I'm not sure they'd even need commit access, perhaps it would be feasible to operate on a model where all PRs against a given provider are handled by a maintainer, and once they sign off a PL employee does the merge. T

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

W dniu czwartek, 16 stycznia 2014 03:12:09 UTC+1 użytkownik Pawel Tomulik napisał: > > > > It seems like a prerequisite for the above is a decent, feature reach > packaging system for puppet modules. [...] > Sorry for my English, I meant "feature-rich" :) -- You received this message becaus

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

W dniu wtorek, 14 stycznia 2014 16:07:29 UTC+1 użytkownik Jason Antman napisał: > > I thought I'd throw in my 2 cents, as a long-time puppet user, current > PE customer, and community member trying to make more code contributions... > > First off, this thread has been great. I was going to quote

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

W dniu czwartek, 16 stycznia 2014 01:01:38 UTC+1 użytkownik James Turnbull napisał: > > Andy Parker wrote: > > On Wed, Jan 15, 2014 at 1:21 PM, Dustin J. Mitchell > > > > > wrote: > > > > On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker > > > >

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Wed, Jan 15, 2014 at 5:01 PM, James Turnbull wrote: > Andy Parker wrote: > > On Wed, Jan 15, 2014 at 1:21 PM, Dustin J. Mitchell > > wrote: > > > > On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker > > wrote: > > > * Tier2 code id

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Wed, Jan 15, 2014 at 2:20 PM, Andy Parker wrote: > Ok, let me try to summarize the discussion so far: > > * Tier1/Tier2 as a basic premise seems to be accepted as a good idea. > * Tier2 code ideally won't live inside the puppet repo at all > * Tier2 code should be packaged up as modules

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

Andy Parker wrote: > On Wed, Jan 15, 2014 at 1:21 PM, Dustin J. Mitchell > wrote: > > On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker > wrote: > > * Tier2 code ideally won't live inside the puppet repo at all > .. > > 1.

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

Thanks for the clarification. Dustin -- 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 th

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Wed, Jan 15, 2014 at 1:21 PM, Dustin J. Mitchell wrote: > On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker wrote: > > * Tier2 code ideally won't live inside the puppet repo at all > .. > > 1. create a "modules" directory that is a peer of "lib" in the puppet > repo > > These seem contradictory

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker wrote: > * Tier2 code ideally won't live inside the puppet repo at all .. > 1. create a "modules" directory that is a peer of "lib" in the puppet repo These seem contradictory.. Dustin -- You received this message because you are subscribed to t

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

Ok, let me try to summarize the discussion so far: * Tier1/Tier2 as a basic premise seems to be accepted as a good idea. * Tier2 code ideally won't live inside the puppet repo at all * Tier2 code should be packaged up as modules * Make the separation based on what we (PL) actually test *

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Mon, Jan 13, 2014 at 6:56 PM, Nan Liu wrote: > It's great the core type/provider is getting a serious review. > > On Mon, Jan 13, 2014 at 4:20 PM, Andy Parker wrote: > >> On Sun, Jan 12, 2014 at 2:38 PM, Kylo Ginsberg wrote: >> > Even later to the party, but I agree :) The alternative of a c

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Tue, Jan 14, 2014 at 7:07 AM, Jason Antman wrote: > (As an aside, I'd also assumed that what I remember hearing years ago > was true, and there was no internal split between PE and FOSS - that PE was > "just FOSS in a prettier box, with support and some value-adds", presumably > that the only

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Monday, January 13, 2014 7:13:20 PM UTC-6, Dustin J. Mitchell wrote: > > How about something as simple as a top-level "modules" directory in > the puppet source, which is installed separately and dynamically > appended to the modulepath at runtime? That avoids any problems for > users who

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

I thought I'd throw in my 2 cents, as a long-time puppet user, current PE customer, and community member trying to make more code contributions... First off, this thread has been great. I was going to quote a few replies, but there have been so many good ideas, that's sort of pointless. I fully su

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

It's great the core type/provider is getting a serious review. On Mon, Jan 13, 2014 at 4:20 PM, Andy Parker wrote: > On Sun, Jan 12, 2014 at 2:38 PM, Kylo Ginsberg wrote: > Even later to the party, but I agree :) The alternative of a contrib >> directory could muddy the waters so that there wer

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

How about something as simple as a top-level "modules" directory in the puppet source, which is installed separately and dynamically appended to the modulepath at runtime? That avoids any problems for users who set modulepath, allows modules in users' modulepaths to override the built-in modules,

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Sun, Jan 12, 2014 at 2:38 PM, Kylo Ginsberg wrote: > On Fri, Jan 10, 2014 at 10:17 AM, Ashley Penney wrote: > > I'm late to the party but I want to throw my support behind Daniel's plan >> to move all tier2 stuff into modules, right from the start, and ship known >> tested versions with Puppe

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Fri, Jan 10, 2014 at 10:17 AM, Ashley Penney wrote: > I'm late to the party but I want to throw my support behind Daniel's plan > to move all tier2 stuff into modules, right from the start, and ship known > tested versions with Puppet. > Even later to the party, but I agree :) The alternative

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

Erik Dalén wrote: hmm, I think that is fixed. When you use pluginsync it can load it. But the master process can't load them unless there is a agent on the master syncing it to the libdir (which also means all environments on the master use the same code unless you do that hack mentioned in the b

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Fri, Jan 10, 2014 at 12:55 PM, Dustin J. Mitchell wrote: > On Fri, Jan 10, 2014 at 12:45 PM, Andy Parker wrote: > > Tier-1 types: user, service, file, group, package, host, cron, exec, > stage, > > tidy > > Tier-1 providers: dpkg, apt, gem, msi, rpm, windows, yum, useradd, > > windows_adsi, gr

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Fri, Jan 10, 2014 at 12:45 PM, Andy Parker wrote: > Tier-1 types: user, service, file, group, package, host, cron, exec, stage, > tidy > Tier-1 providers: dpkg, apt, gem, msi, rpm, windows, yum, useradd, > windows_adsi, groupadd, crontab > > everything else is tier-2. I'd like to see augeas be

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Fri, Jan 10, 2014 at 6:37 AM, Erik Dalén wrote: > I've found that when putting stuff in modules that use some shared code > like puppetdbquery, you either have to do a pluginsync on the master first, > or do some hacks with the ruby load path to load the code directly out of > the modulepath. T

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Fri, Jan 10, 2014 at 6:17 AM, Dustin J. Mitchell wrote: > For what it's worth, Python at least has struggled with modules being > in and out of the Python distribution. Riding Python's trains means > stringent compatibility constraints, long support durations (many > years), and a long commit-

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

hmm, I think that is fixed. When you use pluginsync it can load it. But the master process can't load them unless there is a agent on the master syncing it to the libdir (which also means all environments on the master use the same code unless you do that hack mentioned in the bug report). On 10

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

> I've found that when putting stuff in modules that use some shared code like > puppetdbquery, you either have to do a pluginsync on the master first, or do > some hacks with the ruby load path to load the code directly out of the > modulepath. That could be a bit annoying for stuff like naginator

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

I've found that when putting stuff in modules that use some shared code like puppetdbquery, you either have to do a pluginsync on the master first, or do some hacks with the ruby load path to load the code directly out of the modulepath. That could be a bit annoying for stuff like naginator or this

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

For what it's worth, Python at least has struggled with modules being in and out of the Python distribution. Riding Python's trains means stringent compatibility constraints, long support durations (many years), and a long commit-to-ship delay. Puppet certainly moves faster than Python, so maybe

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Wed, Jan 8, 2014 at 3:20 PM, Daniel Pittman wrote: > On Wed, Jan 8, 2014 at 1:09 PM, Andy Parker wrote: > > During today's PR triage we spent a long time going over PRs 2227, 2226, > > 2225, 2034, and 2130. These are all related together and are the > combination > > of two different issues. O

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

On Wed, Jan 8, 2014 at 1:09 PM, Andy Parker wrote: > During today's PR triage we spent a long time going over PRs 2227, 2226, > 2225, 2034, and 2130. These are all related together and are the combination > of two different issues. One is that the package provider needs some way of > passing throu

[Puppet-dev] Tiering platform's and providers in puppet's core

During today's PR triage we spent a long time going over PRs 2227, 2226, 2225, 2034, and 2130. These are all related together and are the combination of two different issues. One is that the package provider needs some way of passing through arbitrary, unmodelled parameters to the provider (so that