On Oct 14, 2014, at 9: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 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 [email protected]. 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.
