On 2014-03-12 02:13, Trevor Vaughan wrote:
If possible, I would love to see this done without a composite
namevar.
The issue is that youre going to start ending up with variables
*everywhere* to figure out what youre actually installing.
I'm not fully convinced that this is actually true.
I've now finished the composite type I was talking about earlier, and
the missing corner stone was defining
def name
"#{parent_interface}.#{subinterface_number}"
end
on the type, so that the prefetched resources are matched up to the
resources from the catalog.
If possible, I would like the same title but that should be smoothly
combined with the provider.
That said, if it ends up being a composite namevar, thats not the end
of the world. We just need to use a delimiter that isnt used in
package names. An @ maybe? Something wide makes it easy to read. The
cases where I used a composite namevar I used a plus. So, mysql+rpm,
which is quite easy to scan.
package { "mysql@rpm": ... }
Without having it tested, it should be possible to specify multiple
patterns to match on titles without '@' to set only the package name.
So the following should still work:
package {
"mysql":;
"apache":
package_name => 'apache2-mpm-itk';
"nokogiri":
provider => gem;
"memcache":;
"memcache@gem":;
}
With the following correct references:
* using the title:
Package['mysql']
Package['apache']
Package['nokogiri']
Package['memcache']
Package['memcache@gem']
* using the actual name, which probably be very brittle as the
provider is often defaulted based on facts
Package['mysql@rpm']
Package['apache2-mpm-itk@deb']
Package['nokogiri@gem']
Package['memcache@rpm']
Package['memcache@gem']
* using queries; this is very explicit about the user's requirement,
may return multiple resources
Package<| title == 'mysql' |>
Package<| package_name == 'mysql' |>
Package<| package_name == 'mysql' and provider != 'gem' |>
Package<| package_name == 'memcache' |>
I think there is no (trivial) way around the fundamental problem that
"Package['memcache']" cannot refer to a single resource when the package
name is not unique.
I'm currently working through these issues (with a different type) in
the project I'm working on, so I'd be very thankful about any
enlightenment about problems you see with this approach.
Regards, David
Trevor
On Tue, Mar 11, 2014 at 5:23 PM, Pedro Côrte-Real <pe...@pedrocr.net
[5]> wrote:
On Tue, Mar 11, 2014 at 5:29 PM, Andy Parker <a...@puppetlabs.com
[1]> wrote:
> Personally, I would be ok with yet another hack in puppet 3 to
handle this
> issue since it has been coming up so often and since I also dont
know a
> clear timeline for getting new functionality in to address this
specific
> issue in a better way. And yes, my idealism is cracking :/
Its great to finally see traction on this. I still dont understand
why this is a hack though. This is what is broken:
package {"foo_deb":
name => foo,
provider => apt,
}
package {"foo_gem":
name => foo,
provider => gem,
}
But the only reason this doesnt work is that we used $name to
override the deb/gem name. This on the other hand would work fine:
exec {"foo_as_root":
command => "/bin/foo",
user => root,
}
exec {"foo_as_someuser":
command => "/bin/foo",
user => someuser,
}
Yet the only difference between the two cases is that we used
$command
and not $name to override the default given by $title.
Package was designed assuming the meaningless tokens we pass to apt
to
select debs have some relation to the meaningless tokens we pass to
gem to select gems. Most of the time this doesnt bite us because
names are reasonably unique. But then someone goes and uses
"memcache"
for the server deb and the client gem. These are totally different
software packages that just happen to use the same token in two
different package systems. Using $title as the default meaningless
token is economical in terms of keystrokes but then just like with
Exec there needs to be a not unique $meaningless_token variable.
This is just a bug in Package, fixing it isnt a hack.
Pedro
--
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 [2].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CALprHx_tTEKX%3D-%2B3iZiDDiWOS0fp20fT91TV%3DpWpd92eRNtVSA%40mail.gmail.com
[3].
For more options, visit https://groups.google.com/d/optout [4].
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com [6]
-- 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 [7].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVJxr7FwwqZPhKuZ4RuHihkt1pTD6c-hsXjys7N-7LTag%40mail.gmail.com
[8].
For more options, visit https://groups.google.com/d/optout [9].
Links:
------
[1] mailto:a...@puppetlabs.com
[2] mailto:puppet-dev%2bunsubscr...@googlegroups.com
[3]
https://groups.google.com/d/msgid/puppet-dev/CALprHx_tTEKX%3D-%2B3iZiDDiWOS0fp20fT91TV%3DpWpd92eRNtVSA%40mail.gmail.com
[4] https://groups.google.com/d/optout
[5] mailto:pe...@pedrocr.net
[6] mailto:tvaug...@onyxpoint.com
[7] mailto:puppet-dev+unsubscr...@googlegroups.com
[8]
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVJxr7FwwqZPhKuZ4RuHihkt1pTD6c-hsXjys7N-7LTag%40mail.gmail.com?utm_medium=email&utm_source=footer
[9] https://groups.google.com/d/optout
--
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/81e069e35b3db4878da59b59137693fa%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.
