Upgrading Salt

[Travis Beauvais]

Can salt upgrade itself? By package (I currently install from epel-testing on CentOS)? From git master (REALLY need 0.14.1)?

If so, simply by running cmd.run? Write a module? Maybe a module already exists? Logging into 200+ machines isn't really feasible.

[Jeffrey Ollie]

I've done it a number of times. It's not always 100% successful but
it's gotten much better recently. What I do is build a custom package
and put it in a private repo that all my hosts pull from. Upgrade the
master first:

master# yum clean all && yum update salt\*
master# systemctl restart salt-master.service salt-minion.service

Then tell all the minions to upgrade:

master# salt -v '*' cmd.run 'yum clean all && yum update salt*'
master# salt -v '*' service.restart salt-minion

You can check to see how things went by querying the version number of
the minions:

master# salt -v '*' test.version

There may be a few minions that don't take, but hopefully there are
few enough left over that it can be done manually.

--
Jeff Ollie

[David Ward]

This thread might be of interest to you.

https://groups.google.com/forum/?fromgroups=#!topic/salt-users/z4vjPJbnKhk

[tonthon]

Hi,

To handle salt-minion upgrade, the best way we've found was to install
it in a virtualenv and manually setup an init script.

This way we can have one version running, install the latest version,
update the init script and launch echo "/etc/init.d/salt-minion restart"
|at now + 1min.

Regards
Gaston
http://www.majerti.fr

Le 12/04/2013 04:11, Travis Beauvais a �crit :

> --
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to salt-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ben Hosmer]

Yeah, checkout the docs on saltutil.update:

http://docs.saltstack.com/ref/modules/all/salt.modules.saltutil.html#module-salt.modules.saltutil

On Thu, Apr 11, 2013 at 10:11 PM, Travis Beauvais <tbea...@gmail.com> wrote:

Can salt upgrade itself? By package (I currently install from epel-testing on CentOS)? From git master (REALLY need 0.14.1)?

If so, simply by running cmd.run? Write a module? Maybe a module already exists? Logging into 200+ machines isn't really feasible.

--

You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Ben Hosmer

Brevard Tech - Brevard County Florida's Tech User Group

http://www.brevardtech.org

Drupal Developer

http://www.radarearth.com

321.252.9581

[tonthon]

Thanks for pointing that one.

Le 12/04/2013 11:22, Ben Hosmer a �crit :

> Yeah, checkout the docs on saltutil.update:
>
> http://docs.saltstack.com/ref/modules/all/salt.modules.saltutil.html#module-salt.modules.saltutil
>
>
> On Thu, Apr 11, 2013 at 10:11 PM, Travis Beauvais <tbea...@gmail.com
> <mailto:tbea...@gmail.com>> wrote:
>
> Can salt upgrade itself? By package (I currently install from
> epel-testing on CentOS)? From git master (REALLY need 0.14.1)?
>
> If so, simply by running cmd.run? Write a module? Maybe a module
> already exists? Logging into 200+ machines isn't really feasible.
> --
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to salt-users+...@googlegroups.com

> <mailto:salt-users%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> --
> Ben Hosmer
>
> Brevard Tech - Brevard County Florida's Tech User Group
> http://www.brevardtech.org
>
> Drupal Developer

> http://www.radarearth.com <http://www.radarearth.com/>
>
> 321.252.9581

[Paul Traylor]

2013/4/11 Jeffrey Ollie <je...@ocjtech.us>:

>
> master# salt -v '*' cmd.run 'yum clean all && yum update salt*'
> master# salt -v '*' service.restart salt-minion
>

Could you not run

salt -v '*' pkg.install salt refresh=True

instead ?



--
Paul Traylor
https://github.com/kfdm

[Jeffrey Ollie]

On Fri, Apr 12, 2013 at 11:18 AM, Paul Traylor
<kungfudi...@gmail.com> wrote:
> 2013/4/11 Jeffrey Ollie <je...@ocjtech.us>:
>>
>> master# salt -v '*' cmd.run 'yum clean all && yum update salt*'
>> master# salt -v '*' service.restart salt-minion
>
> Could you not run
>
> salt -v '*' pkg.install salt refresh=True
>
> instead ?

Well, you'd have to do:

salt -v '*' pkg.install pkgs='["salt", "salt-minion"]' refresh=True

I guess I didn't think that "install" would upgrade packages, plus I
started using my original formula before the multiple package install
option was available.

--
Jeff Ollie

[Mike Chesnut]

On Apr 12, 2013 10:04 AM, "Jeffrey Ollie" <je...@ocjtech.us> wrote:
>
> On Fri, Apr 12, 2013 at 11:18 AM, Paul Traylor
> <kungfudi...@gmail.com> wrote:
> > 2013/4/11 Jeffrey Ollie <je...@ocjtech.us>:
> >>
> >> master# salt -v '*' cmd.run 'yum clean all && yum update salt*'
> >> master# salt -v '*' service.restart salt-minion
> >
> > Could you not run
> >
> > salt -v '*' pkg.install salt refresh=True
> >
> > instead ?
>
> Well, you'd have to do:
>
> salt -v '*' pkg.install pkgs='["salt", "salt-minion"]' refresh=True

Nah, yum handles the dependencies for you just fine. I just ask it to install salt-minion and that takes care of it.

> I guess I didn't think that "install" would upgrade packages, plus I
> started using my original formula before the multiple package install
> option was available.

I agree it's not totally intuitive. I've often wished that we had an "update" or "upgrade" that didn't do the full yum update... That'd probably be easy to add.

[Les Mikesell]

On Fri, Apr 12, 2013 at 12:22 PM, Mike Chesnut <mche...@gmail.com> wrote:
>
> I agree it's not totally intuitive. I've often wished that we had an
> "update" or "upgrade" that didn't do the full yum update... That'd probably
> be easy to add.

What I've always wanted - and been too lazy to tackle myself - is a
tool that would look up all of the rpm revisions in place on a tested
machine, then tell the matching production instances for that service
to update themselves to exactly those revisions (even if newer ones
are available), and in some orderly manner (some percentage at once,
certain data centers at a time, etc.).

--
Les Mikesell
lesmi...@gmail.com

[David Boucha]

Les,

You can tell your state which version of a package to install and it's location.

You can then batch the updates using  --batch 10%  (10 percent of minions at a time) or --batch 2 (2 minions at a time) from the cli or an overstate

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Dave Boucha  |  Sr. Engineer

5272 South College Drive, Suite 301 | Murray, UT 84123
office 801-305-3563
da...@saltstack.com | www.saltstack.com

[Les Mikesell]

Yes, the real missing piece is the reverse-engineering of the
example/test system to gather the package versions and write the
appropriate syntax for the update commands. 99.99% of the time, I
just want to 'yum update', run some tests, then repeat on the
production boxes without really knowing or caring about the package
version numbers myself. _But_, I want to know that new/untested
versions that appear in the update repository between the start and
end of the exercise aren't included until the next round. And I
don't want to have to freeze a mirror copy of the update repository
for every distribution and system state I might want to reproduce.

-Les

> 5272 South College Drive, Suite 301 | Murray, UT 84123
> office 801-305-3563
> da...@saltstack.com | www.saltstack.com
>