On 14 October 2014 01:13, Charlie Sharpsteen <[email protected]> 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 *ab*use 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.
--
Erik Dalén
--
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/CAAAzDLdBexTyBmvzq30vdwAo884xseU0rauZzpMcOVzNaO65mg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
