Puppet users - Jun 2011 - Package type: enable/disable repo vs options (#2247 vs #4113)

We currently have to feature requests to add similar (or at least
overlapping) functionality to the Package type.

#2247[1] - enablerepo and disablerepo for yum type

#4113[2] - Provide a generic "options"-style parameter for packages.

It seems like having #4113 would remove the need for having #2247, but I
wanted to get some wider opinions to make sure I wasn''t ignoring some
use-case that would make this not the case.

Personally, I think we should move forward on #4113 instead of #2247,
since #4113 seems like the more general solution, and isn''t tied
directly to the yum provider.

#2247 does currently have some code submitted for it, however it
requires a signed CLA before we can accept it.  While no code has been
written for #4113 yet, it doesn''t look like it would actually be that
much work to do.

Thoughts?  Opinions?  Comments?

[1] http://projects.puppetlabs.com/issues/2247
[2] http://projects.puppetlabs.com/issues/4113

-- 
Jacob Helwig

+1 for #4113

Charles

On Thu, Jun 2, 2011 at 12:16 PM, Jacob Helwig <jacob@puppetlabs.com>
wrote:
> We currently have to feature requests to add similar (or at least
> overlapping) functionality to the Package type.
>
> #2247[1] - enablerepo and disablerepo for yum type
>
> #4113[2] - Provide a generic "options"-style parameter for
packages.
>
> It seems like having #4113 would remove the need for having #2247, but I
> wanted to get some wider opinions to make sure I wasn''t ignoring
some
> use-case that would make this not the case.
>
> Personally, I think we should move forward on #4113 instead of #2247,
> since #4113 seems like the more general solution, and isn''t tied
> directly to the yum provider.
>
> #2247 does currently have some code submitted for it, however it
> requires a signed CLA before we can accept it.  While no code has been
> written for #4113 yet, it doesn''t look like it would actually be
that
> much work to do.
>
> Thoughts?  Opinions?  Comments?
>
> [1] http://projects.puppetlabs.com/issues/2247
> [2] http://projects.puppetlabs.com/issues/4113
>
> --
> Jacob Helwig
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQGcBAEBAgAGBQJN58V4AAoJEHJabXWGiqEBjbEL/2Rm3YS7DL5nMj0O2GmOKwC8
> 78uG3dfpdzrM7FPKruMzUIAEMv+OIYzyp8moUvtRPz/lWgC2Qy0ubI6Ras4CDiaT
> EXxC9GtAx9cJ7ZhzxhzDjhb8ZTeOoejKVUIddxt6NZRyYxtE4soK3Cmuj6/c8rp3
> mwkTgSrXgd4s8lpWi60s9D726e1z7uQwXIMeIUGM5XOa1Me3AcX87lKoillrqq7d
> gkaYbRvdh8k/EFpA6qdyHaRblXWMO7YelpJ5RmDq2sMbAX+x0dF5tW2wdQFuv3t8
> F9M8w9L/itQSfu5bHT/VAylLx+5jkITCty1GsKMGKrujqetzfD94zLTTOVr1XZ+t
> OxLfpFrjL9VRaEvWmtyoPOaRKFouubbIVl/7gNF026FfEU97mGytHgdgy2BDP5wg
> G6lnq7qwVd77ZniaxuHgZvBwlhnqFUJ+ma+4gPog4sa6Z6t+IDKAHC+Sepaba0dN
> R+u+YHkkjGD2ZursvkZdQsASNWGG4CiP4gnqEdZccg=> =AcGW
> -----END PGP SIGNATURE-----
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 02/06/11 18:16, Jacob Helwig wrote:
> We currently have to feature requests to add similar (or at least
> overlapping) functionality to the Package type.
> 
> #2247[1] - enablerepo and disablerepo for yum type
> 
> #4113[2] - Provide a generic "options"-style parameter for
packages.
> 
> It seems like having #4113 would remove the need for having #2247, but I
> wanted to get some wider opinions to make sure I wasn''t ignoring
some
> use-case that would make this not the case.
The only use case I can''t see being solved with #4113, is support for
selecting a repo with the zypper package provider.  It selects a repo by
running "zypper install repo:package" (as I understand it), rather
than
as a separate command line option.
> Personally, I think we should move forward on #4113 instead of #2247,
> since #4113 seems like the more general solution, and isn''t tied
> directly to the yum provider.
I''d prefer to see both.  I don''t think #2247 needs to be tied
to yum as
the same notion of selecting the source repository(s) applies to four
other providers[1], not to mention the others that already have this
ability via the "source" attribute to select a repository by URL.

The difficulty might be how to design it so that it''s generic enough,
rather than using attributes named enablerepo and disablerepo (which I
dislike, because they''re so very yum-specific).  I have a more detailed
suggestion I can outline in another post..

[1] http://projects.puppetlabs.com/issues/2247#note-36

-- 
Dominic Cleal
Red Hat Consulting
m: +44 (0)7818 512168

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, June 2, 2011 at 10:16 AM, Jacob Helwig wrote:
> We currently have to feature requests to add similar (or at least
> overlapping) functionality to the Package type.
> 
> #2247[1] - enablerepo and disablerepo for yum type
> 
> #4113[2] - Provide a generic "options"-style parameter for
packages.
> 
> It seems like having #4113 would remove the need for having #2247, but I
> wanted to get some wider opinions to make sure I wasn''t ignoring
some
> use-case that would make this not the case.
> 
> Personally, I think we should move forward on #4113 instead of #2247,
> since #4113 seems like the more general solution, and isn''t tied
> directly to the yum provider.
> 
> #2247 does currently have some code submitted for it, however it
> requires a signed CLA before we can accept it. While no code has been
> written for #4113 yet, it doesn''t look like it would actually be
that
> much work to do.
> 
> Thoughts? Opinions? Comments?
> 
It looks like the crux of this problem is that many, many providers add their
own, fairly unique, capabilities. We then try to model all of these capabilities
in the type, and end up with a package type that has ~15 parameters, many of
which are ignored on almost all providers, and no properties.

And yet we have no real ability to add provider-specific attributes, aside from
adding them to the type, with an associated feature, and declaring our provider
as the only one that supports that feature. So my generic proposal is that we
add some better way to do that. To keep the definition of a resource consistent
across providers, this should only allow additional parameters (data) to be
specified, and not properties.

I have a few ideas for this:

1) Add an ''options'' or ''data'' or similar
metaparameter which accepts a hash.

This would basically be a place to add arbitrary data accessible to the
provider. Thus, for the enablerepo example, it would just be a key/value in the
options hash. Any provider is free to use or ignore it as desired. A big problem
with this is there''s no real validation for which keys are allowed, or
what they must look like, which leads us to:

2) As 1, but with an ability for a provider to specify the options acceptable.

In this case, a provider would have some method for declaring a legal option,
and its validation and/or munging. But in this case, what''s the
difference between a parameter and an option? Apparently only where/how we
declare and specify them. Although, there may be some benefit to distinguishing
generic type parameters from provider-specific options.

3) As 2, but remove the concept of parameters.

This is one possible way to reconcile the difference between parameters and
options. But is there really an advantage to wrapping all of our data which is
essentially parameters in a hash? Maybe, for distinguishing parameters from
properties, but probably not.

4) As 2, but instead using something like newparam on provider.

This is similar to the previous idea, in that it unifies "options" and
"parameters", but in the other direction. In addition to specifying
generic type parameters, also add the ability to specify provider-specific
parameters. This has the advantage of not requiring any changes to existing
manifests using provider parameters. It has the disadvantage that we
can''t really validate provider parameters on the master (though
we''ve talked about removing validation on the master anyway).

Since I can''t even decide which of my own four suggestions I prefer,
please poke holes in as many of them as you can to ease my mental burden. :)
> [1] http://projects.puppetlabs.com/issues/2247
> [2] http://projects.puppetlabs.com/issues/4113
> 
> -- 
> Jacob Helwig
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.