On Fri, 20 Jul 2018, at 02:46, Josh Cooper wrote:
> On Wed, Jul 18, 2018 at 8:57 PM R.I.Pienaar <r...@devco.net> wrote:
> >
> >
> >
> > On Thu, 19 Jul 2018, at 01:27, Eric Sorenson wrote:
> > >
> > >
> > > > On Jul 16, 2018, at 10:52 PM, R.I.Pienaar <r...@devco.net> 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 puppet-dev+unsubscr...@googlegroups.com.
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.