I think that dropping isomorphism would be clearer to end users.
It's not all that much more maintenance either really.
On Tue, Oct 14, 2014 at 3: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 *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 puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdBexTyBmvzq30vdwAo884xseU0rauZzpMcOVzNaO65mg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdBexTyBmvzq30vdwAo884xseU0rauZzpMcOVzNaO65mg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
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/CANs%2BFoWTLtRMk1MHsLPHdKSFGBQomhdjbrohJg6%3DsETT_OdiZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
