On Fri, 20 Jul 2018, at 02:46, Josh Cooper wrote:
> On Wed, Jul 18, 2018 at 8:57 PM R.I.Pienaar <[email protected]> wrote:
> >
> >
> >
> > On Thu, 19 Jul 2018, at 01:27, Eric Sorenson wrote:
> > >
> > >
> > > > On Jul 16, 2018, at 10:52 PM, R.I.Pienaar <[email protected]> wrote:
> > > >
> > > >
> > > >
> > > > On Tue, 17 Jul 2018, at 02:40, Eric Sorenson wrote:
> > > >> Another effort that's underway but not yet complete is the extraction
> > > >> of
> > > >> non-core types/providers into modules. This addresses some
> > > >> long-standing
> > > >> requests to, for example, be able to change the nagios types and OS-
> > > >> specific resources without needing to get a full agent release out. The
> > > >> extracted types will be available in a modulepath structure in the
> > > >> puppet agent package, so (with a few targeted exceptions) there won't
> > > >> be
> > > >> any user-visible changes to what's available when you get the package,
> > > >> but an implication that hasn't really come up is around using Puppet in
> > > >> rubygem format. The extracted types are available on github and on the
> > > >> forge as separate modules, so if you currently use some of these
> > > >> extracted types, you'd need a way to get them installed locally.
> > > >>
> > > >> So my question is -
> > > >> - do you current use/rely on 'gem install puppet' for your workflows?
> > > >> If
> > > >> so, what do you do with it? (does anybody use a 'gem install puppet' as
> > > >> their production "puppet agent" daemon?)
> > > >
> > > > we use it to get apply on machines - actually we package the gem into a
> > > > rpm
> > > > with FPM but its the same outcome really. We need things in custom
> > > > paths
> > > > and puppet-agent isn't relocatable so thats the path of least
> > > > resistance.
> > > > Regardless we probably could not use puppet-agent even if relocatable as
> > > > different teams do different things
> > >
> > > i see, given the above - since you do 'puppet apply' on the systems
> > > would you ship the puppetlabs-*_core modules that contain the extracted
> > > types along with the rest of the modules you use? or would you bundle
> > > them along with the gem as a fpm build step?
> >
> > The least surprising thing to e would probably be to add them to my
> > Puppetfile like any other module.
> >
> > But it would also probably be quite a surprise when `gem install` doesn't
> > yield a working setup for the average person who does not go and read
> > install docs or something, we had exactly this situation with the
> > mcollective gem. You can install it but its kind of pointless since you
> > have no connectivity plugins or security plugins - or anything that makes
> > it work and this really caused a lot of unhappy users. I still don't know
> > what would have been a better path and it seems to me this is more or less
> > the same story
>
> What about a gem post-install message pointing to a docs page,
> versioned based on the major puppet version, e.g.
> https://puppet.com/puppet6/modules.html?
>
> Another option could be to provide instructions for installing a
> metamodule? Could be generic puppetlabs-core module, or one based on
> platform? We basically have that already for
> https://forge.puppet.com/puppetlabs/windows.
>
> $ puppet module install puppetlabs-linux
> $ puppet module install puppetlabs-windows
> $ puppet module install puppetlabs-osx
yeah that sounds like it would help. Anyway its not like apply wont work at all
its just a bunch of types won't, we could perhaps also add some messaging to
the error about a type not found along these lines?
--
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/1532066550.102047.1446954128.1AE04BD8%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.
