On Monday, October 13, 2014 6:13:53 PM UTC-5, Charlie Sharpsteen 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
On Oct 14, 2014, at 9:42 AM, Erik Dalén wrote:
>
> On 14 October 2014 01:13, Charlie Sharpsteen 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 pic
On Tue, Oct 14, 2014 at 5:13 AM, Trevor Vaughan
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 C
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
wrote:
>
> On 14 October 2014 01:13, Charlie Sharpsteen wrote:
>
>>
>> On Thursday, October 9, 2014 3:10:55 PM UTC-7, John Bolling
On 14 October 2014 01:13, Charlie Sharpsteen 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-isomo
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.
>
>
> 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 b
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
> O
>
> 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'
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 > wrote:
>
> That depends heavily on how you characterize the problem. To me, the
>> clash between packages of different types is primarily a facet of the more
>> fundament
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
On Thu, Oct 9, 2014 at 3:10 PM, John Bollinger
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, Octob
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:
> >
> >
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
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
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 }
>>
>> .
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
On Wed, Oct 8, 2014 at 6:33 AM, Felix Frank 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...
>
> That's not what I'm say
On Tuesday, October 7, 2014 9:10:11 PM UTC-5, Daniele Sluijters wrote:
>
> 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
> p
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
ju
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 wrote:
> On 10/08/2014 03:23 PM, Trevor Vaughan wrote:
> >
> > If you go with the descriptive namevar, you
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
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 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 understa
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:
service
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 apache_us
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,
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
wrote:
>
>
> On Monday, October 6, 2014 5:13:43 PM UTC-5, Andy Parker wrote:
>>
>> Sorry to resur
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 > wrote:
>
>>
>>
>> On Thursday, March 13, 2014 8:50:19 AM UTC-5, Trevor Vaughan 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
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 pip and
>> gem on th
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 pip and
> gem on the same system.
>
>
I see I should have devoted more text to my last statement: "The trick here
would be that the provider(s) must not be ba
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 Pack
> On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger
> 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:
> SecondaryPackage
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 Debia
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
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 and
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
yum/rpm
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 combine
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 me
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, elim
On Wed, Mar 12, 2014 at 6:35 PM, John Bollinger
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 makes the package
> versio
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
> >
> 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
>
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 per
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'v
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 hack
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 Tue, Mar 11, 2014 at 5:29 PM, Andy Parker 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
> issue in a better
On Mon, Mar 10, 2014 at 1:36 PM, Trevor Vaughan wrote:
> 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 functionality in to address thi
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 in
Well, I'm certainly a fan.
Now, we just need some upstream traction.
On Mon, Mar 10, 2014 at 4:29 PM, Drew Blessing wrote:
> 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
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 int
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 wrote:
> Unless you can definitively say that making major changes in the RAL to
> addr
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 ha
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
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 s
On Saturday, March 8, 2014 11:24:07 AM UTC-6, Trevor Vaughan wrote:
>
> How does 'exec' do it?
>
>
Exec doesn't do it. What Exec does (or did -- I am having trouble finding
mention of it in the current docs), is to allow the title / command to be
duplicated without restriction, regardless of
I agree, it seems like this solution would be simple and effective. I am
almost positive there are other types that behave this way. It breaks
nothing and fixes everything, as far as I can see.
On Saturday, March 8, 2014 2:48:21 PM UTC-6, Pedro Côrte-Real wrote:
>
> On Fri, Mar 7, 2014 at 10:15
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 e
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 "
Oh, no, this works perfectly. 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 "just work".
Unfortunately, I haven't found the special sauce for this yet.
Trevor
On Sun, Mar 9, 2014
On 09.03.2014 03:39, Trevor Vaughan wrote:
In theory a composite namevar could be used if you just specify the
provider.
For instance, on a Red Hat system:
package { 'foo': ensure => 'latest' } ==> namevar == foo:yum
And
package { 'foo': ensure => 'latest', provider => 'gem' } ==> namevar ==
In theory a composite namevar could be used if you just specify the
provider.
For instance, on a Red Hat system:
package { 'foo': ensure => 'latest' } ==> namevar == foo:yum
And
package { 'foo': ensure => 'latest', provider => 'gem' } ==> namevar ==
foo:gem
That said, I never could get composi
On Fri, Mar 7, 2014 at 10:15 PM, Adrien Thebo wrote:
> Long story short, allowing multiple resources to exist with the same title
> but different providers is problematic.
There's no reason to need to do that though. Package just needs to be
able to override the package name without changing $nam
How does 'exec' do it?
On Fri, Mar 7, 2014 at 5:15 PM, Adrien Thebo 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 which explains why
>
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 wor
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 wrote:
> 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://tick
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 can
67 matches
Mail list logo
