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
On Tue, Oct 14, 2014 at 5:13 AM, Trevor Vaughan tvaug...@onyxpoint.com
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
On Oct 14, 2014, at 9: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
On Friday, October 10, 2014 8:31:30 AM UTC-5, Drew Blessing wrote:
I greatly favor anything else over making Package non-isomorphic.
I completely appreciate what you're saying. However, I don't think this
was the intent of the provider abstraction. It was intended to make the
Whether such an alternative type is called Secondary_package or
Module or Software, or whether there are several (Gem, Pip, Cpan,
...) is very much a secondary concern to me.
John
Perfect. I understand what you're saying and I agree.
--
You received this message because you are
On Thursday, October 9, 2014 6:36:49 PM UTC-5, Andy Parker wrote:
On Thu, Oct 9, 2014 at 3:10 PM, John Bollinger john.bo...@stjude.org
javascript: wrote:
That depends heavily on how you characterize the problem. To me, the
clash between packages of different types is primarily a
I greatly favor anything else over making Package non-isomorphic.
I completely appreciate what you're saying. However, I don't think this was
the intent of the provider abstraction. It was intended to make the
OS-specific provider transparent, right? The different types of packages
we're
On 10/08/2014 10:34 PM, Charlie Sharpsteen wrote:
On Wednesday, October 8, 2014 11:51:32 AM UTC-7, John Bollinger wrote:
On Wednesday, October 8, 2014 6:55:19 AM UTC-5, Felix Frank wrote:
package { 'mysql-gem': package_name = mysql, provider = gem }
...which is awful I
On Thursday, October 9, 2014 9:12:41 AM UTC-5, Felix Frank wrote:
On 10/08/2014 10:34 PM, Charlie Sharpsteen wrote:
On Wednesday, October 8, 2014 11:51:32 AM UTC-7, John Bollinger wrote:
On Wednesday, October 8, 2014 6:55:19 AM UTC-5, Felix Frank wrote:
package {
On Thu, Oct 9, 2014 at 3:10 PM, John Bollinger john.bollin...@stjude.org
wrote:
On Thursday, October 9, 2014 9:12:41 AM UTC-5, Felix Frank wrote:
On 10/08/2014 10:34 PM, Charlie Sharpsteen wrote:
On Wednesday, October 8, 2014 11:51:32 AM UTC-7, John Bollinger wrote:
On Wednesday,
I'm still a big fan of this for clarity and ease of use:
That would conflict for the secondary_package resources. We could try not
unifying the different providers under a single name:
package { 'mysql': ensure = installed }
gem { 'mysql': ensure = installed }
pip { 'mysql': ensure =
That's the fundamental issue though.
Package isn't a package. Package is one of many distinct things.
This is like the following:
user { 'foo': provider = 'passwd' }
user { 'foo': provider = 'apache' }
They're simply two different things so they would be user (i.e. native
user) and
Sorry for the double post but I just thought of this.
1) The ldap provider probably needs to be removed from 'user'. Yes, they
are users but they're not native, they could be one of many things.
2) If we do want to keep gem as a package provider, you'll need something
like the following:
On 10/08/2014 01:23 PM, Trevor Vaughan wrote:
service { 'my_service': require = Package['mysql']{ :provider = 'gem' } }
How about require = Package| title == 'mysql' and provider == 'gem' |
Not that it matters - having two Package[mysql] resources will *never*
be a thing.
If I understand
So, I would *love* to see proper inheritance for Types.
Currently, I can inherit Providers and do classic OO stuff but I can't do
that with Types and it drives me a bit nuts.
If you go with the descriptive namevar, you'll need to make the separator
something that won't show up in a package name.
On 10/08/2014 03:23 PM, Trevor Vaughan wrote:
If you go with the descriptive namevar, you'll need to make the
separator something that won't show up in a package name. So probably
one of '+/,|' etc...
That's not what I'm saying. I'm saying let the namevar no longer be the
package name at
It may be but, if we're already going to munge about with the namevar to
make it unique, why not just use it without having to type more?
Trevor
On Wed, Oct 8, 2014 at 9:33 AM, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
On 10/08/2014 03:23 PM, Trevor Vaughan wrote:
If you go with
This is the best idea I've heard. Certain puppet types intend to provide an
abstraction. This abstraction only works for native package providers in
this case because anything else requires the user to make an informed
decision. I think having all other package providers be separate types is
On Wed, Oct 8, 2014 at 6:33 AM, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
On 10/08/2014 03:23 PM, Trevor Vaughan wrote:
If you go with the descriptive namevar, you'll need to make the
separator something that won't show up in a package name. So probably
one of '+/,|' etc...
On Wednesday, October 8, 2014 6:55:19 AM UTC-5, Felix Frank wrote:
On 10/08/2014 01:23 PM, Trevor Vaughan wrote:
service { 'my_service': require = Package['mysql']{ :provider = 'gem'
} }
How about require = Package| title == 'mysql' and provider == 'gem' |
I filed a feature
On Wednesday, October 8, 2014 11:51:32 AM UTC-7, John Bollinger wrote:
On Wednesday, October 8, 2014 6:55:19 AM UTC-5, Felix Frank wrote:
If I understand Andy correctly, we might have something like
package { 'mysql-gem': package_name = mysql, provider = gem }
...which is awful I
On Wednesday, October 8, 2014 1:43:09 PM UTC-5, Andy Parker wrote:
My proposal allows
package { 'mysql-gem': name = mysql, provider = gem, ensure =
installed }
package { 'mysql': ensure = installed }
Such statements would have previously collided because both would have
created a
On Monday, October 6, 2014 5:13:43 PM UTC-5, Andy Parker wrote:
Sorry to resurrect an old thread, but this came to my attention again
today.
On Fri, Mar 14, 2014 at 6:20 AM, John Bollinger john.bo...@stjude.org
javascript: wrote:
On Thursday, March 13, 2014 8:50:19 AM UTC-5, Trevor
I'm still a fan of separate types.
Just put a nail in the coffin once and for all since this is really the
only type which tries to get fancy.
Trevor
On Tue, Oct 7, 2014 at 3:27 PM, John Bollinger john.bollin...@stjude.org
wrote:
On Monday, October 6, 2014 5:13:43 PM UTC-5, Andy Parker
Separate types undoes basically what package now tries to make as
transparent as possible. I guess a case could be made to have package
only deal with the OS native package provider and have separate types and
providers for secondary packages like gem, wheel/egg/whatever etc.
On Tuesday, 7
Sorry to resurrect an old thread, but this came to my attention again today.
On Fri, Mar 14, 2014 at 6:20 AM, John Bollinger john.bollin...@stjude.org
wrote:
On Thursday, March 13, 2014 8:50:19 AM UTC-5, Trevor Vaughan wrote:
SecondaryPackage wouldn't fix it if you wanted to install using
On 03/12/2014 11:23 PM, Trevor Vaughan wrote:
package_yum
package_gem
etc
This would probably be pretty quick work overall and, of course,
eliminates all of the conflict issues.
Butit doesn't feel like a good solution.
I agree that the implementation you sketched is messy, but
I think I just realized what I actually want to be able to do when creating
types in a generic sense.
newparam(:name) do
isnamevar
...
end
newparam(:provider) do
isnamevar
...
end
Now, in the catalog, what would happen is that *all* parameters that were
named as namevars would be
I am kind of interested in what you describe. I think for our environment,
keeping the package type as is and creating a new ³gem² type that inherits
from package would be just fine. If we only consider RHEL-based systems
for a moment, is there really a possible conflict scenario other than
Looking at the list of providers for file, on RHEL systems you'll probably
only run into conflicts with *native* (yum, rpm, up2date), pip, and gem.
I also am not opposed to this. As far as I can tell, 'package' is the only
type that doesn't follow the rules of the other types (manage one thing
On Thursday, March 13, 2014 8:02:22 AM UTC-5, Trevor Vaughan wrote:
Looking at the list of providers for file, on RHEL systems you'll probably
only run into conflicts with *native* (yum, rpm, up2date), pip, and gem.
I also am not opposed to this. As far as I can tell, 'package' is the only
SecondaryPackage wouldn't fix it if you wanted to install using pip and gem
on the same system.
I do think that native packages are what Package should manage and
everything else should be its own type/provider combo because they are,
indeed, *something else*.
This gets hairy with RPM since
On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger
john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:
That would work for me. Alternatively, there could be just one new
type, say SecondaryPackage, that rolled up gem, pip, fink, etc.
On 03/13/2014 02:50 PM, Trevor Vaughan wrote:
Yeah, after all this I think break out all of the subtypes, make the
suitable but default the native *package* statement to whatever it does now.
Then...admins be careful!
We can do some fanciness by mining the catalog when building the subtypes
and making sure there is no conflicting native
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 agree with Adrien. I think the solution will be something with a benefit for
the entire RAL.
The thought I have is of a solution that preserves the original behavior of
having a resource type auto-discover it’s preferred provider on a system. So in
this case, we could allow one resource
On Tuesday, March 11, 2014 4:23:33 PM UTC-5, Pedro Côrte-Real wrote:
On Tue, Mar 11, 2014 at 5:29 PM, Andy Parker
an...@puppetlabs.comjavascript:
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
On Wed, Mar 12, 2014 at 6:35 PM, John Bollinger
john.bollin...@stjude.org wrote:
No, that's not really a difference at all. 'command' is the namevar of the
Exec type (it has no 'name' property), and 'name' is the namevar of Package.
It is the fact that 'name' is the namevar of Package that
I just realized that there's another way around this. It's not so glamorous
as fixing the type, but it would work.
Just create new types that inherit the package type and hard code the
provider.
package_yum
package_gem
etc
This would probably be pretty quick work overall and, of course,
Talk about coincidence. Today I implemented this fragment of a custom
type:
def self.title_patterns
[
[ /^([-_\w\/]+)\.(\d+)$/ , [ [:parent_interface ],
[:subinterface_number] ] ],
[ /.*/, [ ] ]
]
end
newparam(:parent_interface) do
desc The name of the parent
On Mon, Mar 10, 2014 at 1:36 PM, Trevor Vaughan tvaug...@onyxpoint.comwrote:
Well, I'm certainly a fan.
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 don't know a
clear timeline for getting new
On Tue, Mar 11, 2014 at 5:29 PM, Andy Parker a...@puppetlabs.com 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 don't know a
clear timeline for getting new functionality in to address this specific
I am pretty sure a composite namevar won't be necessary. It will just be a new
param such as pkgname that, if not specified, would default to the resource
title/name for backward compatibility.
Since we have the go ahead from Puppet, does anyone have the know-how to do
this? I could try to
If possible, I would love to see this done without a composite namevar.
The issue is that you're going to start ending up with variables
*everywhere* to figure out what you're actually installing.
If possible, I would like the same 'title' but that should be smoothly
combined with the provider.
On 2014-03-09 21:10, Trevor Vaughan wrote:
Oh, no, this works perfectly.
Seems like I have some reading to do, or, see below.
I just *hate* having to stuff all of
that into the name. It makes the hash of options completely
pointless.
I want the name/title to be arbitrary and the rest to
The first version would work if packages were implemented with composite
namevars (which they're not). However, it's ugly and shouldn't be necessary
in this case.
The second version should work no matter what but causes confusion when
trying to do any type of resource dependency chaining.
You'd
That would technically also solve the problem. There would just have to be
an additional validation step to make sure that the keys in the resource
are unique.
I wonder if all resources could be changed to more of a DB-style key model
where you could denote specific attributes as your unique key
My concern with this solution is that it's a one time shim for a single
type. Granted, it may work and could solve this particular problem. However
I think this is a flaw in the RAL that has a number of touch points that
also need to be fixed. This might be me being too idealistic but I think
that
Unless you can definitively say that making major changes in the RAL to
address this issue is slated for the near future (say, late 3.x release or
first 4.x release), I'd say the individual fix for package type is
warranted in the meantime. Are there any other types that you think people
are
It's just this one, as far as I know.
I would like to see the RAL updated, but I'd like this fix in Puppet 3 and
the RAL update in Puppet 4/5/whatever.
Trevor
On Mon, Mar 10, 2014 at 11:15 AM, Drew Blessing drew.bless...@buckle.comwrote:
Unless you can definitively say that making major
I think that sounds like a great way to approach the issue, Trevor. Adrien,
what do you think?
FWIW, I just encountered this issue for the second time in a week. I
suspect this trend will continue. We are finally getting comfortable with
custom types/providers and want to build providers to
Well, I'm certainly a fan.
Now, we just need some upstream traction.
On Mon, Mar 10, 2014 at 4:29 PM, Drew Blessing drew.bless...@buckle.comwrote:
I think that sounds like a great way to approach the issue, Trevor.
Adrien, what do you think?
FWIW, I just encountered this issue for the
How does 'exec' do it?
On Fri, Mar 7, 2014 at 5:15 PM, Adrien Thebo adr...@puppetlabs.com wrote:
Long story short, allowing multiple resources to exist with the same title
but different providers is problematic. I've commented on this at
https://projects.puppetlabs.com/issues/1398#note-13
I want to start a conversation about the package resource type and a bug
that goes back about 6 years. The current ticket
is https://tickets.puppetlabs.com/browse/PUP-1073 and relates to really old
tickets such as https://projects.puppetlabs.com/issues/973.
If I have gem 'x' and RPM 'x', I
If you could, please go +1 it in Jira for visibility.
I too would love to see this fixed.
Trevor
On Fri, Mar 7, 2014 at 1:55 PM, Drew Blessing drew.bless...@buckle.comwrote:
I want to start a conversation about the package resource type and a bug
that goes back about 6 years. The current
Long story short, allowing multiple resources to exist with the same title
but different providers is problematic. I've commented on this at
https://projects.puppetlabs.com/issues/1398#note-13 which explains why this
isn't trivial to solve. This is a limitation that is pretty core to how
Puppet
56 matches
Mail list logo
