On Tue, Oct 14, 2014 at 5:13 AM, Trevor Vaughan <[email protected]> wrote:
> I think that dropping isomorphism would be clearer to end users. > > Maybe, maybe not. I don't think that they'll often see a difference between the two. Since dropping constraints is easier than adding constraints, I think we'll go with Charlie's suggestion. If it turns out that it still doesn't work in enough cases, then we can either make the package type non-isomorphic or start heading down the path of individual types. Yay! A thread that has reached a conclusion! :D > It's not all that much more maintenance either really. > > On Tue, Oct 14, 2014 at 3:42 AM, Erik Dalén <[email protected]> > wrote: > >> >> 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 >> <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 > [email protected] > > -- 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWTLtRMk1MHsLPHdKSFGBQomhdjbrohJg6%3DsETT_OdiZA%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWTLtRMk1MHsLPHdKSFGBQomhdjbrohJg6%3DsETT_OdiZA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at **PuppetConf 2014, **September 20-24 in San Francisco - * www.puppetconf.com -- 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/CANhgQXugb2ym%2BTBt6XRYO9YqEPf4p%3DV%3DY2ZCpB4yW6c449-W2g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
