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 <[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. For more options, visit https://groups.google.com/d/optout.
