FAQ
I have a class that looks like this:

class java {
package { "java-1.6.0-sun.x86_64":
ensure => '1.6.0.39-1jpp.4.el5_9',
}
}

...but it gives me this error:

err: /Stage[main]/Java/Package[java-1.6.0-sun.x86_64]/ensure: change from
1.6.0.33-1jpp.1.el5_8 to 1.6.0.39-1jpp.4.el5_9 failed: Could not update:
Failed to update to version 1.6.0.39-1jpp.4.el5_9, got version
1.6.0.33-1jpp.1.el5_8 instead at
/etc/puppet/modules/java/manifests/init.pp:5


However, if I change the class to just use ensure => 'latest', it will do
this:

notice: /Stage[main]/Java/Package[java-1.6.0-sun.x86_64]/ensure: ensure
changed '1.6.0.33-1jpp.1.el5_8' to '1:1.6.0.39-1jpp.4.el5_9'

So I know it's possible for the upgrade to work, but I don't want puppet
arbitrarily installing whatever the latest is, I want to ensure it's that
version.

Any ideas?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Felix Frank at Feb 14, 2013 at 11:52 am
    Hi,

    please take note that
    On 02/14/2013 02:32 AM, Sean LeBlanc wrote:
    ensure => '1.6.0.39-1jpp.4.el5_9',notice:
    ...this version is unlike...
    /Stage[main]/Java/Package[java-1.6.0-sun.x86_64]/ensure: ensure changed
    '1.6.0.33-1jpp.1.el5_8' to '1:1.6.0.39-1jpp.4.el5_9'
    ...this version. Notice the leading 1:

    HTH,
    Felix

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sean LeBlanc at Feb 15, 2013 at 4:39 pm
    I should have added to my post that I've tried adding that "1:" as well to
    the ensure line with the same results.

    Any other ideas?

    I've tried this workaround:

    exec { "upgrade java":
    command => "yum -d 1 -e 1 upgrade
    java-1.6.0-sun-1:1.6.0.39-1jpp.4.el5_9.x86_64
    java-1.6.0-sun-devel-1:1.6.0.39-1jpp.4.el5_9.x86_64 -y",
    path => "/usr/bin/"
    }

    ...but it then runs every single time the puppet agent runs:

    notice: /Stage[main]/Java/Exec[upgrade java]/returns: executed successfully


    On Thursday, February 14, 2013 4:52:17 AM UTC-7, Felix.Frank wrote:

    Hi,

    please take note that
    On 02/14/2013 02:32 AM, Sean LeBlanc wrote:
    ensure => '1.6.0.39-1jpp.4.el5_9',notice:
    ...this version is unlike...
    /Stage[main]/Java/Package[java-1.6.0-sun.x86_64]/ensure: ensure changed
    '1.6.0.33-1jpp.1.el5_8' to '1:1.6.0.39-1jpp.4.el5_9'
    ...this version. Notice the leading 1:

    HTH,
    Felix
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Felix Frank at Feb 15, 2013 at 5:12 pm

    On 02/15/2013 05:39 PM, Sean LeBlanc wrote:
    I should have added to my post that I've tried adding that "1:" as well
    to the ensure line with the same results.

    Any other ideas?
    Have you run that catalog with the --debug flag? It would be interesting
    to see just what the provider is trying to do and how it fails.
    I've tried this workaround:

    exec { "upgrade java":
    command => "yum -d 1 -e 1 upgrade
    java-1.6.0-sun-1:1.6.0.39-1jpp.4.el5_9.x86_64
    java-1.6.0-sun-devel-1:1.6.0.39-1jpp.4.el5_9.x86_64 -y",
    path => "/usr/bin/"
    }

    ...but it then runs every single time the puppet agent runs:
    This can work, but you should then define a condition such as

    unless => "rpm -q java-sun-1.6.0-sun | grep -q 39-1jpp"

    It's a pretty gross workaround though ;-) I'd be interested to learn why
    the provider won't manage to do what you want.

    Cheers,
    Felix

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 15, 2013 at 6:53 pm

    On Friday, February 15, 2013 10:39:10 AM UTC-6, Sean LeBlanc wrote:
    I should have added to my post that I've tried adding that "1:" as well to
    the ensure line with the same results.

    Curiouser and curiouser. The "1:" is an epoch number, as you probably
    recognize. I was a bit surprised that Puppet would require you to include
    it, but very surprised to find out that it fails even if you do. I do
    think it likely that the epoch number is what's tripping up Puppet, but
    that doesn't make it any less a bug. I recommend you file a ticket.

    Until that's fixed, your best available solution is probably to use
    'latest', and to control the package version by controlling the contents of
    the repositories that your clients rely upon. To the extent that that
    implies keeping local (pseudo-)mirrors of the repositories you use, that's
    worth your while anyway.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brian Lalor at Feb 15, 2013 at 11:41 pm

    On Feb 15, 2013, at 1:45 PM, jcbollinger wrote:

    Curiouser and curiouser. The "1:" is an epoch number, as you probably recognize. I was a bit surprised that Puppet would require you to include it, but very surprised to find out that it fails even if you do. I do think it likely that the epoch number is what's tripping up Puppet, but that doesn't make it any less a bug. I recommend you file a ticket.
    Check the epoch of the two packages. The epoch overrides all other version comparison logic. If they have the same epoch, RPM considers them to be the same version. I had that problem with the Oracle JDK RPMs. They all have the epoch set to 2000, so it's impossible to either upgrade or install both versions concurrently. I think "rpm -qip <package>" will show it, but if not you can do "rpm -qp --queryformat='%{EPOCH}\n' <package>".

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Feb 18, 2013 at 2:09 pm

    On Friday, February 15, 2013 5:41:55 PM UTC-6, blalor wrote:
    On Feb 15, 2013, at 1:45 PM, jcbollinger wrote:

    Curiouser and curiouser. The "1:" is an epoch number, as you probably
    recognize. I was a bit surprised that Puppet would require you to include
    it, but very surprised to find out that it fails even if you do. I do
    think it likely that the epoch number is what's tripping up Puppet, but
    that doesn't make it any less a bug. I recommend you file a ticket.


    Check the epoch of the two packages. The epoch overrides all other
    version comparison logic. If they have the same epoch, RPM considers them
    to be the same version. I had that problem with the Oracle JDK RPMs. They
    all have the epoch set to 2000, so it's impossible to either upgrade or
    install both versions concurrently. I think "rpm -qip <package>" will show
    it, but if not you can do "rpm -qp --queryformat='%{EPOCH}\n' <package>".

    That's a good tip, but it does not relate to the OP's problem. Epoch 1 is
    what he gets if he updates to the latest version currently available from
    is repositories.


    John


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedFeb 14, '13 at 1:58a
activeFeb 18, '13 at 2:09p
posts7
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase