On Oct 14, 2014, at 9:42 AM, Erik Dalén <erik.gustav.da...@gmail.com> wrote:
>
> On 14 October 2014 01:13, Charlie Sharpsteen <ch...@puppetlabs.com> wrote:
>
> On Thursday, October 9, 2014 3:10:55 PM UTC-7, John Bollinger wrote:
>
>
> On Thursday, October 9, 2014 9:12:41 AM UTC-5, Felix Frank wrote:
> So in response to Andy's request for a pick, I feel that making packages
> non-isomorphic and allow namevar != title would be a fair compromise.
>
> package { 'mysql-foo': name => 'mysql', provider => 'gem' }
>
> Yes this might get abused by Forge modules. Nothing we can do about
> that, as far as I can tell.
>
>
>
> I'm not so much worried about abuse as about well-intentioned and seemingly
> reasonable use that mixes badly with other well-intentioned and seemingly
> reasonable use. Hypothetical examples:
>
> (1)
> Module A declares
> package { 'foo-gem': name => 'foo', ensure => '1.0', provider => 'gem' }
> Module B declares
> package { 'gem-foo': name => 'foo', ensure => '2.0', provider => 'gem' }
> Result is that either A or B breaks.
>
> (2)
> Module A declares
> package { 'web-server': name => 'httpd-server', ensure => '2.0.12' }
> Module B declares
> package { 'httpd-server': ensure => '2.4.0' }
> Again, either A or B breaks.
>
> One of Puppet's major features is that it avoids damaging managed systems
> systems by being conservative about what configuration specifications it is
> willing to accept. That trait is far more valuable to me than an ability to
> use specifically the Package type to manage gems etc..
>
>
> John
>
> So, to recap, the issue with making packages non-isomorphic is that the title
> becomes the only method to enforce uniqueness of resources.
>
> We may be able to solve the problem of name clashes and retain stronger
> guarantees by switching the Package type to use a composite namevar instead
> of dropping isomorphism.
>
> I took a crack at this over the weekend and the required changes turned out
> to be very simple. A work in progress patch can be found here:
>
> https://gist.github.com/Sharpie/3b2b12d9b3ef2cea6837
>
> This change resolves example #1 by using the combination of [name, provider]
> to enforce uniqueness, instead of the current [name]. The following clash
> would no longer be possible:
>
> # Composite key: ['foo', 'gem']
> package { 'foo-gem': name => 'foo', ensure => '1.0', provider => 'gem' }
>
> # Same composite key: ['foo', 'gem']
> package { 'gem-foo': name => 'foo', ensure => '2.0', provider => 'gem' }
>
>
> Example #2 is also resolved:
>
> # Composite key: ['httpd-server', nil]
> package { 'httpd-server': ensure => '2.4.0' }
>
> # Same composite key: ['httpd-server', nil]
> package { 'web-server': name => 'httpd-server', ensure => '2.0.12' }
>
>
> The possibility for conflict still exists between providers that happen to
> manage the same pool of packages and between implicit and explicit use of the
> default provider. For example, the following will result in competing
> resources on RedHat:
>
> # Composite key: ['httpd-server', nil]
> package { 'httpd-server': ensure => installed }
>
> # Composite key: ['httpd-server', 'yum']
> package { 'httpd': ensure => absent, name => 'httpd-server', provider =>
> 'yum' }
>
> # Composite key: ['httpd-server', 'rpm']
> package { 'webserver': ensure => '2.4.0', name => 'httpd-server',
> provider => 'rpm' }
>
>
> So, a composite key does not provide an airtight guarantee of uniqueness but
> is better than dropping isomorphism. We may be able to improve this situation
> by turning missing composite key values into smart defaults when the agent
> prepares a catalog for application.
>
> Thoughts on using a composite namevar as an alternative to dropping
> isomorphism?
>
> Seems good to me. But tbh I was okay with just dropping isomorphism on
> packages as well.
I'm very opposed to dropping the isomorphism, especially for such a critical
type. I'd rather do the necessary work to make it a composite namevar. So
many other assumptions about the world start to break down if you let that slip
that it's hard to predict what the consequences will be.
--
http://puppetlabs.com/ | http://about.me/lak | @puppetmasterd
--
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/DE3A644E-0C4E-45FC-A1CC-81D8E05DA105%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
