Why doesn''t the yum provider support version, I tried added ensure
->
''ver'' and it barfs up (on clients) with:
<snip>
err: //stan.gbuild.org/any-host/java/Package[j2sdk]/ensure:
change from 1.4.2_12-fcs to 1.4.2_13-fcs failed: Package provider yum
does not support specifying versions at /etc/puppet/manifests/classes/
java.pp:13
</snip>
--jason
On Mon, Feb 19, 2007 at 12:42:16AM -0800, Jason Dillon wrote:> Why doesn''t the yum provider support version, I tried added ensure -> > ''ver'' and it barfs up (on clients) with: > [snip]As far as I can tell, yum itself doesn''t allow you to specify a version when you install a package. So, all puppet could do is effectively do a ensure => latest when the install version is older than that which is avaliable, downgrading would be pretty much impossible without completely removing the package first. At least, that''s why I''d guess Luke doesn''t support it. Myself, I''m thinking about switching to apt4rpm to help avoid these problems, which supports this. (It''s in newer releases of CentOS at least). -- Ceri Storey <cez@necrofish.org.uk> ''What I really want is "apt-get smite"'' --Rob Partington http://unix.culti.st/
You can install a specific version (or version + arch) with yum:
yum install package-version
yum install package-version.arch
Its documented in the yum man page in the MISC section:
<snip>
Specifying package names
A package can be referred to for
install,update,list,remove etc with any of the following:
name
name.arch
name-ver
name-ver-rel
name-ver-rel.arch
name-epoch:ver-rel.arch
epoch:name-ver-rel.arch
For example: yum remove kernel-2.4.1-10.i686
</snip>
--jason
On Feb 19, 2007, at 1:35 AM, Ceri Storey wrote:
> On Mon, Feb 19, 2007 at 12:42:16AM -0800, Jason Dillon wrote:
>> Why doesn''t the yum provider support version, I tried added
ensure ->
>> ''ver'' and it barfs up (on clients) with:
>> [snip]
>
> As far as I can tell, yum itself doesn''t allow you to specify a
> version
> when you install a package. So, all puppet could do is effectively
> do a
> ensure => latest when the install version is older than that which is
> avaliable, downgrading would be pretty much impossible without
> completely removing the package first.
>
> At least, that''s why I''d guess Luke doesn''t
support it.
>
> Myself, I''m thinking about switching to apt4rpm to help avoid
these
> problems, which supports this. (It''s in newer releases of CentOS
at
> least).
>
> --
> Ceri Storey <cez@necrofish.org.uk>
> ''What I really want is "apt-get smite"''
> --Rob Partington
> http://unix.culti.st/
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
On Mon, Feb 19, 2007 at 01:43:43AM -0800, Jason Dillon wrote:> You can install a specific version (or version + arch) with yum:> yum install package-version > yum install package-version.arch> Its documented in the yum man page in the MISC section:*facepalm* Cheers for pointing that out. -- Ceri Storey <cez@necrofish.org.uk> ''What I really want is "apt-get smite"'' --Rob Partington http://unix.culti.st/
On Feb 19, 2007, at 3:43 AM, Jason Dillon wrote:> You can install a specific version (or version + arch) with yum: > > yum install package-version > yum install package-version.arch > > Its documented in the yum man page in the MISC section: > > <snip> > Specifying package names > A package can be referred to for > install,update,list,remove etc with any of the following: > > name > name.arch > name-ver > name-ver-rel > name-ver-rel.arch > name-epoch:ver-rel.arch > epoch:name-ver-rel.arch > > For example: yum remove kernel-2.4.1-10.i686 > </snip>I must not have known that when I wrote the provider. I''d gladly accept a patch that enabled this. -- There are three social classes in America: upper middle class, middle class, and lower middle class. --Judith Martin --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
I''d love to... ''cept I know jack about ruby. If I find sometime I will see if I can hack something together, though if someone else knows ruby already would be kind of them to make a patch *hint, hint* --jason On Feb 19, 2007, at 8:55 AM, Luke Kanies wrote:> On Feb 19, 2007, at 3:43 AM, Jason Dillon wrote: > >> You can install a specific version (or version + arch) with yum: >> >> yum install package-version >> yum install package-version.arch >> >> Its documented in the yum man page in the MISC section: >> >> <snip> >> Specifying package names >> A package can be referred to for >> install,update,list,remove etc with any of the following: >> >> name >> name.arch >> name-ver >> name-ver-rel >> name-ver-rel.arch >> name-epoch:ver-rel.arch >> epoch:name-ver-rel.arch >> >> For example: yum remove kernel-2.4.1-10.i686 >> </snip> > > I must not have known that when I wrote the provider. > > I''d gladly accept a patch that enabled this. > > -- > There are three social classes in America: upper middle class, > middle > class, and lower middle class. --Judith Martin > > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users
On Feb 19, 2007, at 5:41 PM, Jason Dillon wrote:> I''d love to... ''cept I know jack about ruby. If I find sometime I > will see if I can hack something together, though if someone else > knows ruby already would be kind of them to make a patch *hint, hint*I was just talking about this idea with Ben today, but would you (or any of other many other non-developers) be willing to spend some non- development time helping to farm the bug/enhancement list? We''ve got a *lot* of enhancement tickets opened, far more than I can conceivably develop, and we don''t have nearly enough developers working them. Until we manage to get more developers interested in the project (I''m working on it, and it sounds like we''ve got a couple in the pipeline), we need to be as efficient as possible in the work we do, and we need to find a way for non-developers to contribute. Peter Abrahamsen has done a ton of really great work porting the documentation over to the wiki and he has remained helpful, without having to learn Ruby. There''s still a ton of documentation and usability work to do on the wiki, but Peter''s initial push got the ball rolling. We need a similar big push to get the enhancement requests in order. The first step is to figure out how to even talk about the feature requests. Do we leave them in the bug database, or do we build a separate set of pages devoted to determining the features to work on? Do we vote on them? How do other user-rich but developer-poor projects handle this? Even just going through the enhancement requests and flagging the ones that aren''t well documented or seem obsolete would be a good idea, and having someone responsible for checking out each incoming request to make sure it makes sense and is well categorized would help. Heck, even just making sure we have good categories would help -- I haven''t spent any time on the categories, or defining what the different priorities mean, or, um, much of this at all. If someone wanted to take charge of this process and put some time in, it would make my time much more effective and it would give other people confidence that their feature requests aren''t just going into a black hole. Heck, it might even be smart to set up some kind of bounty on some of these features. That''s one good way to get developers interested in the project, and a surprisingly-large number of these features aren''t actually that tough. Open source projects traditionally ignore the contributions of non- developers, and I want to dodge that trap. Puppet will always have a lot of code, but the user experience is as important as the code is, and the users can have a hugely positive impact on making others'' (and their own) experience better. If you can think of a way to make any part of the project better, please just do it. Well, ok, if it''s a drastic change, send a note to the list, but I am at the whims of the community, not the other way around. And if you *do* happen to be interested in starting some development but you want to start small and you want some hand-holding, I would be willing to work with you on some of the smaller feature requests. And I''ll be extra-helpful if you''ll blog your progress -- I think that would be hugely informative to other community members. Really, it''s surprisingly easy. -- "They called me mad, and I called them mad, and damn them, they outvoted me." -- Nathaniel Lee, on being consigned to a mental institution, circa 17th c. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 2/19/07, Luke Kanies <luke@madstop.com> wrote:> On Feb 19, 2007, at 5:41 PM, Jason Dillon wrote: > > > I''d love to... ''cept I know jack about ruby. If I find sometime I > > will see if I can hack something together, though if someone else > > knows ruby already would be kind of them to make a patch *hint, hint* > > I was just talking about this idea with Ben today, but would you (or > any of other many other non-developers) be willing to spend some non- > development time helping to farm the bug/enhancement list? > > We''ve got a *lot* of enhancement tickets opened, far more than I can > conceivably develop, and we don''t have nearly enough developers > working them. Until we manage to get more developers interested in > the project (I''m working on it, and it sounds like we''ve got a couple > in the pipeline), we need to be as efficient as possible in the work > we do, and we need to find a way for non-developers to contribute. > Peter Abrahamsen has done a ton of really great work porting the > documentation over to the wiki and he has remained helpful, without > having to learn Ruby. There''s still a ton of documentation and > usability work to do on the wiki, but Peter''s initial push got the > ball rolling.One of the things I"m working on is a step by step Puppet installation tutorial for Ubuntu. I''m about 3/4 done, and hope to finish it this week. I''m going to submit it to howtoforge and post it on the wiki. I''m hoping to also finish one for OpenBSD and RHEL as well.> We need a similar big push to get the enhancement requests in order. > The first step is to figure out how to even talk about the feature > requests. Do we leave them in the bug database, or do we build a > separate set of pages devoted to determining the features to work > on? Do we vote on them? How do other user-rich but developer-poor > projects handle this? > > Even just going through the enhancement requests and flagging the > ones that aren''t well documented or seem obsolete would be a good > idea, and having someone responsible for checking out each incoming > request to make sure it makes sense and is well categorized would > help. Heck, even just making sure we have good categories would help > -- I haven''t spent any time on the categories, or defining what the > different priorities mean, or, um, much of this at all. If someone > wanted to take charge of this process and put some time in, it would > make my time much more effective and it would give other people > confidence that their feature requests aren''t just going into a black > hole. > > Heck, it might even be smart to set up some kind of bounty on some of > these features. That''s one good way to get developers interested in > the project, and a surprisingly-large number of these features aren''t > actually that tough. > > Open source projects traditionally ignore the contributions of non- > developers, and I want to dodge that trap. Puppet will always have a > lot of code, but the user experience is as important as the code is, > and the users can have a hugely positive impact on making > others'' (and their own) experience better. If you can think of a way > to make any part of the project better, please just do it. Well, ok, > if it''s a drastic change, send a note to the list, but I am at the > whims of the community, not the other way around. > > And if you *do* happen to be interested in starting some development > but you want to start small and you want some hand-holding, I would > be willing to work with you on some of the smaller feature requests. > And I''ll be extra-helpful if you''ll blog your progress -- I think > that would be hugely informative to other community members. Really, > it''s surprisingly easy.I think you''ve got some good ideas here for building a community and have given us some things to think about. Personally I''d like to see myself moving from documentation to development and your offer to help is appreciated. Luke has laid out some needs for the project. For a first step would it be prudent to create a list of projects that need to be completed, and allow individuals to assign themselves? As we move forward it would be nice to know who is working on which aspect(s) of the project. Kent -- "It may be true that the law cannot make a man love me, but it can stop him from lynching me, and I think that''s pretty important." - Martin Luther King Jr.
Matthew Palmer
2007-Feb-20 03:47 UTC
Re: Puppet''s yum provider does not support versions?
On Mon, Feb 19, 2007 at 06:22:27PM -0600, Luke Kanies wrote:> We need a similar big push to get the enhancement requests in order. > The first step is to figure out how to even talk about the feature > requests. Do we leave them in the bug database, or do we build a > separate set of pages devoted to determining the features to work > on? Do we vote on them? How do other user-rich but developer-poor > projects handle this?One way I''ve seen (I think I first heard about it was a suggestion on the Rails lists, actually) is feature requests without a sensible patch get summarily closed with a "please implement it if you want it". In your case, you could add a link to a "Luke will hack Puppet for food" page. It sounds brutal, and it is, but when the only other alternative is to drown in begging requests, well, you''ve sometimes got to be cruel to be kind. It might also stimulate a few more development contracts, as a side bonus. What constitutes a feature request as opposed to a bug report can be a little vague, of course, and you''d want to err on the side of caution. - Matt
David Lutterkort
2007-Feb-22 23:08 UTC
Re: Puppet''s yum provider does not support versions?
On Mon, 2007-02-19 at 09:35 +0000, Ceri Storey wrote:> On Mon, Feb 19, 2007 at 12:42:16AM -0800, Jason Dillon wrote: > > Why doesn''t the yum provider support version, I tried added ensure -> > > ''ver'' and it barfs up (on clients) with: > > [snip] > > As far as I can tell, yum itself doesn''t allow you to specify a version > when you install a package. So, all puppet could do is effectively do a > ensure => latest when the install version is older than that which is > avaliable, downgrading would be pretty much impossible without > completely removing the package first.That''s exactly the problem I''d have with implementing this: if the current version is <= than the desired version, and the desired version is available in a repo, then it''s smooth sailing. But what do you do if a newer version is installed ? Downgrading is kinda scary since it''s hardly ever tested. David
In my case, I actually want 2 versions of the same package installed... jdk 1.5 and jdk 6, both can live happily together on the same system... though both have the same base package name. Why not simply add a flag to enable downgrading, else warn and continue? --jason On Feb 22, 2007, at 3:08 PM, David Lutterkort wrote:> On Mon, 2007-02-19 at 09:35 +0000, Ceri Storey wrote: >> On Mon, Feb 19, 2007 at 12:42:16AM -0800, Jason Dillon wrote: >>> Why doesn''t the yum provider support version, I tried added >>> ensure -> >>> ''ver'' and it barfs up (on clients) with: >>> [snip] >> >> As far as I can tell, yum itself doesn''t allow you to specify a >> version >> when you install a package. So, all puppet could do is effectively >> do a >> ensure => latest when the install version is older than that which is >> avaliable, downgrading would be pretty much impossible without >> completely removing the package first. > > That''s exactly the problem I''d have with implementing this: if the > current version is <= than the desired version, and the desired > version > is available in a repo, then it''s smooth sailing. > > But what do you do if a newer version is installed ? Downgrading is > kinda scary since it''s hardly ever tested. > > David > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users
I wish I had time to help out more... but with all of the work I''m doing on Geronimo and pending work on some Mojo''s I don''t really have a lot of time for anything else at the moment. If puppet was written in Java I''d whip up some patches for you though ;-) If I find some free time Its been on my list of things todo to learn ruby... so maybe that will happen on of these days ;-) --jason On Feb 19, 2007, at 4:22 PM, Luke Kanies wrote:> On Feb 19, 2007, at 5:41 PM, Jason Dillon wrote: > >> I''d love to... ''cept I know jack about ruby. If I find sometime I >> will see if I can hack something together, though if someone else >> knows ruby already would be kind of them to make a patch *hint, hint* > > I was just talking about this idea with Ben today, but would you (or > any of other many other non-developers) be willing to spend some non- > development time helping to farm the bug/enhancement list? > > We''ve got a *lot* of enhancement tickets opened, far more than I can > conceivably develop, and we don''t have nearly enough developers > working them. Until we manage to get more developers interested in > the project (I''m working on it, and it sounds like we''ve got a couple > in the pipeline), we need to be as efficient as possible in the work > we do, and we need to find a way for non-developers to contribute. > Peter Abrahamsen has done a ton of really great work porting the > documentation over to the wiki and he has remained helpful, without > having to learn Ruby. There''s still a ton of documentation and > usability work to do on the wiki, but Peter''s initial push got the > ball rolling. > > We need a similar big push to get the enhancement requests in order. > The first step is to figure out how to even talk about the feature > requests. Do we leave them in the bug database, or do we build a > separate set of pages devoted to determining the features to work > on? Do we vote on them? How do other user-rich but developer-poor > projects handle this? > > Even just going through the enhancement requests and flagging the > ones that aren''t well documented or seem obsolete would be a good > idea, and having someone responsible for checking out each incoming > request to make sure it makes sense and is well categorized would > help. Heck, even just making sure we have good categories would help > -- I haven''t spent any time on the categories, or defining what the > different priorities mean, or, um, much of this at all. If someone > wanted to take charge of this process and put some time in, it would > make my time much more effective and it would give other people > confidence that their feature requests aren''t just going into a black > hole. > > Heck, it might even be smart to set up some kind of bounty on some of > these features. That''s one good way to get developers interested in > the project, and a surprisingly-large number of these features aren''t > actually that tough. > > Open source projects traditionally ignore the contributions of non- > developers, and I want to dodge that trap. Puppet will always have a > lot of code, but the user experience is as important as the code is, > and the users can have a hugely positive impact on making > others'' (and their own) experience better. If you can think of a way > to make any part of the project better, please just do it. Well, ok, > if it''s a drastic change, send a note to the list, but I am at the > whims of the community, not the other way around. > > And if you *do* happen to be interested in starting some development > but you want to start small and you want some hand-holding, I would > be willing to work with you on some of the smaller feature requests. > And I''ll be extra-helpful if you''ll blog your progress -- I think > that would be hugely informative to other community members. Really, > it''s surprisingly easy. > > -- > "They called me mad, and I called them mad, and damn them, they > outvoted me." -- Nathaniel Lee, on being consigned to a mental > institution, circa 17th c. > > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users
On Feb 20, 2007, at 3:31 AM, Kenton Brede wrote:> For > a first step would it be prudent to create a list of projects that > need to be completed, and allow individuals to assign themselves? As > we move forward it would be nice to know who is working on which > aspect(s) of the project.This is exactly what I''m thinking of in terms of maintaining project lists. Ben has started working on a way to pick enhancement requests to work on, but I''m afraid that the current enhancement requests need some effort spent to turn them into something that''s actionable. If people are interested in working on any of these tickets, I''m willing to spend some time describing implementation plans for them, but I''ve tried this on previous tickets and no one''s bitten. If there''s a feature you really want and you think you can implement, I''m very willing to help you pick the best way to implement. For the vast majority of the enhancement requests, I know how I would implement them, but I don''t have time to implement them and there''s not much point in writing it all out if I''m the only one implementing them. -- A nation is a society united by delusions about its ancestry and by common hatred of its neighbors. -- William Ralph Inge --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Feb 20, 2007, at 4:47 AM, Matthew Palmer wrote:> > One way I''ve seen (I think I first heard about it was a suggestion > on the > Rails lists, actually) is feature requests without a sensible patch > get > summarily closed with a "please implement it if you want it". In > your case, > you could add a link to a "Luke will hack Puppet for food" page. > It sounds > brutal, and it is, but when the only other alternative is to drown in > begging requests, well, you''ve sometimes got to be cruel to be > kind. It > might also stimulate a few more development contracts, as a side > bonus.I''m kind of unwilling to do this without some other mechanism for keeping track of what people want. I think the best option is to convert enhancement tickets into somewhat actionable projects on the wiki as quickly as possible, but this requires someone be responsible for that page, and it''s not really worth doing unless others are going to spend time implementing.> What constitutes a feature request as opposed to a bug report can be a > little vague, of course, and you''d want to err on the side of caution.Definitely true. -- Between two evils, I always pick the one I never tried before. -- Mae West --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 22 Feb 2007, at 23:08, David Lutterkort wrote:> That''s exactly the problem I''d have with implementing this: if the > current version is <= than the desired version, and the desired > version > is available in a repo, then it''s smooth sailing.> But what do you do if a newer version is installed ? Downgrading is > kinda scary since it''s hardly ever tested.Personally, I''d say that it''s a case of "user beware" . That said, in the environment I''m working in, we can afford to set up our own repository instances, and only ever use those, so we can be confident that we''ll never have that problem. Personally, I''d rather have support for pre-conditions in the language; but somehow, I don''t think that''d happen any time soon. Perhaps if I can convince my employer to let me create a behemoth... I''ve written a short patch which allows you to specify a version which will just be passed through to yum, which is attached to ticket #521. At the minute it''ll become non-idempotent if you want to explicitly specify the epoch, as at the minute, the rpm/yum type doesn''t query for the epoch. I''d say that some degree of fuzzy matching would be required, in this instance. I''m not sure what the best way to handle that would be; considering that the insync? logic is implemented in the type itself. We could delegate that responsibility to the provider, but that might well just be a good way of making spaghetti. -- Ceri Storey <cez@necrofish.org.uk> -- http://unix.culti.st/
Kostas Georgiou
2007-Feb-25 15:49 UTC
Re: Puppet''s yum provider does not support versions?
On Thu, Feb 22, 2007 at 03:16:02PM -0800, Jason Dillon wrote:> In my case, I actually want 2 versions of the same package > installed... jdk 1.5 and jdk 6, both can live happily together on the > same system... though both have the same base package name.At least in the rpm world you should not have 2 versions of an rpm installed (kernel* and multilib is the exception here) for java it is a good idea to use a jpackage based rpm and not the horrible sun ones. Kostas
Kostas Georgiou
2007-Feb-25 16:32 UTC
Re: Puppet''s yum provider does not support versions?
On Thu, Feb 22, 2007 at 03:08:04PM -0800, David Lutterkort wrote:> On Mon, 2007-02-19 at 09:35 +0000, Ceri Storey wrote: > > On Mon, Feb 19, 2007 at 12:42:16AM -0800, Jason Dillon wrote: > > > Why doesn''t the yum provider support version, I tried added ensure -> > > > ''ver'' and it barfs up (on clients) with: > > > [snip] > > > > As far as I can tell, yum itself doesn''t allow you to specify a version > > when you install a package. So, all puppet could do is effectively do a > > ensure => latest when the install version is older than that which is > > avaliable, downgrading would be pretty much impossible without > > completely removing the package first. > > That''s exactly the problem I''d have with implementing this: if the > current version is <= than the desired version, and the desired version > is available in a repo, then it''s smooth sailing. > > But what do you do if a newer version is installed ? Downgrading is > kinda scary since it''s hardly ever tested.Can you even downgrade with yum? I am not even sure that you can do that without removing the package first which can easilly kill your system (imagine ensure => versionfoo for glibc). rpm has the --oldpackage option but not yum. What is puppet supposed to in the following scenario? ina a manifest: package { "package2": ensure => "1.2.2" } $ rpm -q requires package1 package2 >= 1.2.3 fail? uninstall package1? or downgrade package2 and break package1? Kostas
Dennis Jacobfeuerborn
2007-Feb-25 17:10 UTC
Re: Puppet''s yum provider does not support versions?
Kostas Georgiou wrote:> Can you even downgrade with yum? I am not even sure that you can do thatDowngrading with yum will never be possible in a safe and secure way because it would require the complete undo-abilty of all actions yum can perform (including pre-/postinstall scripts). That''s almost impossible to accomplish.> without removing the package first which can easilly kill your system > (imagine ensure => versionfoo for glibc). rpm has the --oldpackage > option but not yum. > > What is puppet supposed to in the following scenario? > ina a manifest: package { "package2": ensure => "1.2.2" } > $ rpm -q requires package1 > package2 >= 1.2.3 > fail? uninstall package1? or downgrade package2 and break package1?I guess that depends on the semantics of ''ensure => "1.2.2"''. If it means that the package version has to be *EXACTLY* "1.2.2" then puppet should give an error. If it only mean the version has to be *AT LEAST* "1.2.2" then everything is fine as "1.2.3" is newer than "1.2.2". Maybe the "ensure" parameter needs to be enhanced to make it possible to express both cases. Regards, Dennis
On 25 Feb 2007, at 16:32, Kostas Georgiou wrote:> Can you even downgrade with yum?It certainly works with vim-minimal, at least :)> What is puppet supposed to in the following scenario? > ina a manifest: package { "package2": ensure => "1.2.2" } > $ rpm -q requires package1 > package2 >= 1.2.3 > fail? uninstall package1? or downgrade package2 and break package1?I think that''d be left down to the package manager itself, really. It may even uninstall package1. -- Ceri Storey <cez@necrofish.org.uk> -- http://unix.culti.st/
Its quite common to have 2 versions of the same package installed... --jason On Feb 25, 2007, at 7:49 AM, Kostas Georgiou wrote:> On Thu, Feb 22, 2007 at 03:16:02PM -0800, Jason Dillon wrote: > >> In my case, I actually want 2 versions of the same package >> installed... jdk 1.5 and jdk 6, both can live happily together on the >> same system... though both have the same base package name. > > At least in the rpm world you should not have 2 versions of an > rpm installed (kernel* and multilib is the exception here) for > java it is a good idea to use a jpackage based rpm and not the > horrible sun ones. > > Kostas > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users
On Feb 25, 2007, at 4:33 PM, Ceri Storey wrote:> > Personally, I''d say that it''s a case of "user beware" . That said, in > the environment I''m working in, we can afford to set up our own > repository instances, and only ever use those, so we can be confident > that we''ll never have that problem. > > Personally, I''d rather have support for pre-conditions in the > language; but somehow, I don''t think that''d happen any time soon. > Perhaps if I can convince my employer to let me create a behemoth...What do you mean by pre-conditions? You mean like exec''s "unless" and its ilk? I''ve been thinking of making those applicable to all resources, not just exec, and it wouldn''t be much of a change.> I''ve written a short patch which allows you to specify a version > which will just be passed through to yum, which is attached to ticket > #521.I''ll apply once I''m back in the states (or one of the many others with commit access might do so beforehand).> At the minute it''ll become non-idempotent if you want to explicitly > specify the epoch, as at the minute, the rpm/yum type doesn''t query > for the epoch. I''d say that some degree of fuzzy matching would be > required, in this instance. > > I''m not sure what the best way to handle that would be; considering > that the insync? logic is implemented in the type itself. We could > delegate that responsibility to the provider, but that might well > just be a good way of making spaghetti.It''s probably best for insync? to check to see if the provider has defined that method, and if so, return its value, but calling it with both the @is and @should values: provider.insync?(self.is, self.should) I''m planning on getting rid of @is and @should in the types, so we definitely should pass the values through explicitly, rather than letting the provider retrieve them. -- I can win an argument on any topic, against any opponent. People know this, and steer clear of me at parties. Often, as a sign of their great respect, they don''t even invite me. -- Dave Barry --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Sun, Feb 25, 2007 at 11:02:58PM +0100, Luke Kanies wrote:> On Feb 25, 2007, at 4:33 PM, Ceri Storey wrote: > > Personally, I''d rather have support for pre-conditions in the > > language; but somehow, I don''t think that''d happen any time soon. > > Perhaps if I can convince my employer to let me create a behemoth... > > What do you mean by pre-conditions? You mean like exec''s "unless" > and its ilk? I''ve been thinking of making those applicable to all > resources, not just exec, and it wouldn''t be much of a change.Sort of. I think it''d be nice to be able to be able to query the properties of existing resources and take action depending on that. Eg: package { fish: ensure => latest, when => (Package[fish].version < ''1.0.0)'' } Although, saying that, it''d probably be possible to do do that at the minuite using a combination of server-side functions and the pelementserver in the puppetd agent. On the other hand, this would give you the ability to specify a non-convergent configuration, which may be a good way to shoot yourself in the foot. -- Ceri Storey <cez@necrofish.org.uk> ''What I really want is "apt-get smite"'' --Rob Partington http://unix.culti.st/
On Feb 26, 2007, at 9:23 AM, Ceri Storey wrote:> > Sort of. I think it''d be nice to be able to be able to query the > properties of existing resources and take action depending on that. > Eg: > > package { fish: > ensure => latest, > when => (Package[fish].version < ''1.0.0)'' > } > > Although, saying that, it''d probably be possible to do do that at the > minuite using a combination of server-side functions and the > pelementserver in the puppetd agent. > > On the other hand, this would give you the ability to specify a > non-convergent configuration, which may be a good way to shoot > yourself > in the foot.Definitely. It''s a bit unlikely that Puppet will ever support this directly (although, as you say, you could hack it yourself; note i''ve s/ pelement/resource/ in svn). I think it''ll always be a better idea to declare on the server exactly what you want all around, rather than trying to declare some bits but react to others. Puppet will never be very good at that, which isn''t really a bad thing, IMO. -- Sabbagh''s Second Law: The biggest problem with communication is the illusion that it has occurred. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com