Salt 0.17.0 is FINALLY here!

1,319 views
Skip to first unread message

Thomas S Hatch

unread,
Oct 2, 2013, 8:05:38 PM10/2/13
to salt-...@googlegroups.com
I cut the release last Friday and we have been packaging and prepping since then. This is the largest Salt release yet with the major addition of salt-ssh allowing salt to manage systems "minionless" by just using the ssh agent.

Quite a few other fantastic features are in 0.17.0 and the release notes are here:


Make sure to read the release notes, salt-ssh is just a small part of this release, with Halite, state auto order, salt thin, and many more, this is a VERY exciting release!

On another note, this feature release will be the last release of Salt using the 0.X.X version. The version logic is staying the same, where the first numbers denote the feature branch and the last number denotes the buxfix release. But starting with the next release we will be switching to a date based version. The date based approach is YY.MM.Bugfix, so if the next release is made in November of 2013, it will be 13.11.0. This is to emphasize the fact that release numbers are arbitrary and dates better represents where the project is. We will also start using codenames to reference future releases, and the codenames will follow the periodic table.

Finally, we are already well into the next feature release "Hydrogen" and we plan on having a 0.17.1 out shortly as well!

Thomas S. Hatch  |  Founder, CTO


5272 South College Drive, Suite 301 | Murray, UT 84123

Shawn Milochik

unread,
Oct 2, 2013, 10:27:52 PM10/2/13
to salt-...@googlegroups.com
Excellent. I have been waiting for salt-ssh for a while. The execution of state files in order is also great. A couple of my co-workers were grumbling about the arbitrary order.

I think this clearly puts Salt at the head of the class in its space. I already thought it was there, but now it's even harder to argue against. :o)

Dmitry Golubenko

unread,
Oct 3, 2013, 2:45:09 AM10/3/13
to salt-...@googlegroups.com
В Срд, 02/10/2013 в 18:05 -0600, Thomas S Hatch пишет:
> I cut the release last Friday and we have been packaging and prepping
> since then. This is the largest Salt release yet with the major
> addition of salt-ssh allowing salt to manage systems "minionless" by
> just using the ssh agent.
>
>
> Quite a few other fantastic features are in 0.17.0 and the release
> notes are here:
>
>
> http://docs.saltstack.com/topics/releases/0.17.0.html

Awesome!



Ran Leibman

unread,
Oct 3, 2013, 4:05:20 AM10/3/13
to salt-...@googlegroups.com
I was waiting to test salt-ssh and the state.sls runner for quite some time !
Are there any documentation on these new features ?

Keep up the good work !

Thomas S Hatch

unread,
Oct 3, 2013, 10:10:04 AM10/3/13
to salt-...@googlegroups.com
Ran, the docs are here:

They are still a little slim, we could use a tutorial on using salt-ssh, granted, there is not a whole lot to using it...

Thomas S. Hatch  |  Founder, CTO


5272 South College Drive, Suite 301 | Murray, UT 84123



--
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.

Les Mikesell

unread,
Oct 3, 2013, 11:25:08 AM10/3/13
to salt-users
On Thu, Oct 3, 2013 at 9:10 AM, Thomas S Hatch <that...@gmail.com> wrote:
>
> Ran, the docs are here:
> http://docs.saltstack.com/topics/ssh/index.html
>
> They are still a little slim, we could use a tutorial on using salt-ssh, granted, there is not a whole lot to using it...
>

Is there a tutorial on using git for pillar and file data that starts
with the premise that you want to have different sets of similar nodes
using different branches or tags? That is, push to a test set first,
then half of production one day, the other half the next?

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

Shawn Milochik

unread,
Oct 3, 2013, 12:10:40 PM10/3/13
to salt-...@googlegroups.com
Les,

Please ask your question in a new thread, since it's not relevant to this topic. I can probably help answer it there.

Shawn

Ran Leibman

unread,
Oct 3, 2013, 12:50:57 PM10/3/13
to salt-...@googlegroups.com
Thanks Thomas, salt-ssh indeed looks pretty straight forward

Is there any docs about the state.sls runner ?
The state.over doesn't fit my needs at the moment and I'm thinking about writing a runner of my own but it sounds like the state.sls might do the job ...

Rachid Belaid

unread,
Oct 3, 2013, 7:26:27 PM10/3/13
to salt-...@googlegroups.com
Amazing release !!!
This made my day :)


--
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.



--
Rach Belaid
Flat 9 240B Amhurst Road, London N16 7UL
Phone : +44 75 008 660 84

Greg Miell

unread,
Oct 4, 2013, 4:46:22 AM10/4/13
to salt-...@googlegroups.com
Wonderful news, looking forward to getting our infrastructure updated with 0.17.0. On that note, any news on the rpms?

Greg

Thomas S Hatch

unread,
Oct 4, 2013, 7:23:36 AM10/4/13
to salt-...@googlegroups.com
RPMs should be available in EPEL testing.

Thomas S. Hatch  |  Founder, CTO


5272 South College Drive, Suite 301 | Murray, UT 84123


On Fri, Oct 4, 2013 at 2:46 AM, Greg Miell <gr...@greg-net.co.uk> wrote:
Wonderful news, looking forward to getting our infrastructure updated with 0.17.0. On that note, any news on the rpms?

Greg

Colton Myers

unread,
Oct 4, 2013, 12:00:41 PM10/4/13
to salt-...@googlegroups.com
The exception is Halite.  We're still in the review phase for salt-halite, as it's a new package.

--
Colton Myers

Greg Miell

unread,
Oct 4, 2013, 12:18:35 PM10/4/13
to salt-...@googlegroups.com
Awesome, thanks for the info, I will test on a small number of machines for now...

I'll also build an rpm for Halite for our internal testing repo so that I can have a play :D Do you know if the rpm spec is up to date in git?



---
Greg Miell
Web Consultant and Developer

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/E19zjqJlym4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

Erik Johnson

unread,
Oct 4, 2013, 1:25:30 PM10/4/13
to salt-...@googlegroups.com
I haven't put a spec in the halite git repo yet. Here are the files for the pending-review halite RPM for Fedora/EPEL:

SRPM: https://dl.dropboxusercontent.com/s/4shqedab21j894f/python-halite-0.1.01-1.el6.src.rpm
Spec: https://dl.dropboxusercontent.com/s/dyrl1jkyiwhhzxj/python-halite.spec
Erik Johnson | Engineer

5272 South College Drive, Suite 301 | Murray, UT 84123

Sean Plaice

unread,
Oct 4, 2013, 2:37:52 PM10/4/13
to salt-...@googlegroups.com
Will deb's be released to the saltstack ppa? If so, when?

On Friday, October 4, 2013 4:23:36 AM UTC-7, Thomas Hatch wrote:
RPMs should be available in EPEL testing.

Colton Myers

unread,
Oct 4, 2013, 4:47:41 PM10/4/13
to salt-...@googlegroups.com
Are they not there yet?  I was under the impression they were already up.

--
Colton Myers


Shawn Milochik

unread,
Oct 4, 2013, 4:50:02 PM10/4/13
to salt-...@googlegroups.com
On Fri, Oct 4, 2013 at 4:47 PM, Colton Myers <colton...@gmail.com> wrote:
Are they not there yet?  I was under the impression they were already up.



I've been trying since the release announcement. No, they're not there. I just tried again 30 seconds ago.

I've done "apt-get update" about 50 times, re-added the PPA, and even tried manually adding the repositories to sources.list, all to no avail.



Colton Myers

unread,
Oct 4, 2013, 4:51:47 PM10/4/13
to salt-...@googlegroups.com
OK, I'll contact the packager for Ubuntu and we'll get them up.

--
Colton Myers


Corey Quinn

unread,
Oct 4, 2013, 5:38:32 PM10/4/13
to salt-...@googlegroups.com, salt-...@googlegroups.com
Working on it. ;-)

Shawn Milochik

unread,
Oct 4, 2013, 5:40:42 PM10/4/13
to salt-...@googlegroups.com
Thank you. I'll keep trying intermittently. This is going to be great. :o)

Colton Myers

unread,
Oct 4, 2013, 6:05:56 PM10/4/13
to salt-...@googlegroups.com
Thanks, Corey!

--
Colton Myers


On Fri, Oct 4, 2013 at 3:40 PM, Shawn Milochik <shawn...@gmail.com> wrote:
Thank you. I'll keep trying intermittently. This is going to be great. :o)

--

Sean Plaice

unread,
Oct 4, 2013, 6:53:52 PM10/4/13
to salt-...@googlegroups.com
Thank you Corey.

On Friday, October 4, 2013 2:38:32 PM UTC-7, Corey Quinn wrote:
Working on it. ;-)

Joseph Lisee

unread,
Oct 4, 2013, 8:16:00 PM10/4/13
to salt-...@googlegroups.com
Are there any instructions on how to install just salt-thin?  It would be great it if was up on PyPi, it's one of the feature I like about Ansible, no need to muck about with PPA's just "pip install ansible".

-Joe L.

Manuel Suarez

unread,
Oct 5, 2013, 1:26:41 PM10/5/13
to salt-...@googlegroups.com
Great news thanks you for the Hard working of the community.

Manuel

Colton Myers

unread,
Oct 6, 2013, 12:58:55 PM10/6/13
to salt-...@googlegroups.com
Are there any instructions on how to install just salt-thin?  It would be great it if was up on PyPi, it's one of the feature I like about Ansible, no need to muck about with PPA's just "pip install ansible".

I don't think salt-thin is packaged on its own anywhere.  I may be wrong, but I think salt-ssh generates salt-thin on the fly.

You're right, though, it would be good to package it separately.  Or you can use salt-ssh to bootstrap it onto the target systems.

Shawn Milochik

unread,
Oct 7, 2013, 10:30:02 AM10/7/13
to salt-...@googlegroups.com
I've tried through the weekend and this morning. Still no update -- I'm still "up to date" with 0.16.4. I don't know how the repos work, so maybe there's a caching issue, but I've been running apt-get update each time.


Thomas S Hatch

unread,
Oct 7, 2013, 4:58:17 PM10/7/13
to salt-...@googlegroups.com
As for Salt Thin, after installing salt you can execute a runner that generates the salt-thin tarball:
salt-run thin.generate

Thomas S. Hatch  |  Founder, CTO


5272 South College Drive, Suite 301 | Murray, UT 84123


On Mon, Oct 7, 2013 at 8:30 AM, Shawn Milochik <shawn...@gmail.com> wrote:
I've tried through the weekend and this morning. Still no update -- I'm still "up to date" with 0.16.4. I don't know how the repos work, so maybe there's a caching issue, but I've been running apt-get update each time.


Cory Wright

unread,
Oct 7, 2013, 5:16:55 PM10/7/13
to salt-...@googlegroups.com, Sh...@milochik.com
You can simply check the repo via the web to see if new packages are there yet:


I'm also anxiously awaiting these new packages.

Trevor Joynson

unread,
Oct 8, 2013, 7:27:42 AM10/8/13
to salt-...@googlegroups.com

There still aren't packages in the PPA?
What's holding this up? If I provide sdebs can we get this uploaded?

Joe Healy

unread,
Oct 8, 2013, 8:15:30 AM10/8/13
to salt-...@googlegroups.com
On Tue, Oct 08, 2013 at 07:27:42AM -0400, Trevor Joynson wrote:
> There still aren't packages in the PPA?
> What's holding this up? If I provide sdebs can we get this uploaded?

Due to maintainer day to day life, packaging changes (salt-ssh) and
some bugs that need to be patched around, this release is taking a
little longer than normal to reach the PPA.

Corey was working on these today. He ran into an issue on building one
of the packages on Raring and I expect it will be high on his
priorities when he gets up in the morning.

For some reason, the docs build with python-sphinx from sid
(1.1.3+dfsg-8), but not from raring (1.1.3+dfsg-7ubuntu2).
We haven't yet tracked down the difference.

If you already have a source package that builds 0.17.0 on raring, I'm
sure Corey would be interested to see it. Otherwise I think he will
solve it shortly.

Thanks very much for your offer of assistance. Although there is
probably little you can do now, it is good to know people are willing
to help within the community.

Joe

Les Mikesell

unread,
Oct 8, 2013, 11:37:19 AM10/8/13
to salt-users
On Tue, Oct 8, 2013 at 7:15 AM, Joe Healy <joeh...@gmail.com> wrote:
>
> Due to maintainer day to day life, packaging changes (salt-ssh) and
> some bugs that need to be patched around, this release is taking a
> little longer than normal to reach the PPA.

I don't think most projects would announce a 'release' until all of
the packages build and are available. Until then it's just a daily
build or something. It is very confusing when you try to upgrade a
mixed set of machines.

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

Trevor Joynson

unread,
Oct 8, 2013, 12:29:16 PM10/8/13
to salt-...@googlegroups.com
Ah, I see this same problem too now that I've delved a bit deeper ;)

Docs build fine on raring using sphinx installed via pip (1.2b3) as well.
I see it's failing on all of the YAML code includes, which as we all know, are plentiful in Salt's documentation ;)

It appears to only hit manpage generation as far as I can see so far as well.

Since it works on Sid, I wonder if Ubuntu's sauce for Sphinx in the current release broke the manpage writer?

And it's no problem, I've been eagerly awaiting a chance to help Salt out ;)


 
)) Trevor Joynson (trevorj)
(( Network Ninja
)) Localhost Solutions (LocSol)
(( https://www.localhostsolutions.com



Colton Myers

unread,
Oct 8, 2013, 2:47:10 PM10/8/13
to salt-...@googlegroups.com
We used to announce the release the moment that the new release hit PyPI, but then there would never be any packages available.  So we've taken to waiting a few days and then announcing it.  Because we don't do the packaging in-house (thank you, community!), it's hard to keep track of which packages have hit their respective mirrors at any given time.  Some, like EPEL, take a day or two, and even then they're only in epel-testing until the 2 week grace period is up.

Sorry for the confusion, because of the addition of the new packages, this release has been harder on the packagers.  0.17.1 should be much smoother.

--
Colton Myers

Les Mikesell

unread,
Oct 8, 2013, 3:05:02 PM10/8/13
to salt-users
On Tue, Oct 8, 2013 at 1:47 PM, Colton Myers <colton...@gmail.com> wrote:
> We used to announce the release the moment that the new release hit PyPI,
> but then there would never be any packages available. So we've taken to
> waiting a few days and then announcing it. Because we don't do the
> packaging in-house (thank you, community!), it's hard to keep track of which
> packages have hit their respective mirrors at any given time. Some, like
> EPEL, take a day or two, and even then they're only in epel-testing until
> the 2 week grace period is up.
>
> Sorry for the confusion, because of the addition of the new packages, this
> release has been harder on the packagers. 0.17.1 should be much smoother.

If a release makes changes that affect packaging, how do you even know
that version of the code can be released until after the packages are
built? And if it doesn't affect the package building, can't Jenkins
generate ready-to-run packages for you for some reasonable number of
variations?

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

Colton Myers

unread,
Oct 8, 2013, 3:24:01 PM10/8/13
to salt-...@googlegroups.com
If a release makes changes that affect packaging, how do you even know
that version of the code can be released until after the packages are
built?  And if it doesn't affect the package building, can't Jenkins
generate ready-to-run packages for you for some reasonable number of
variations?

Well, we know the code is working, as we (and others) have been testing it.  But we want people to be able to install just the pieces of salt they need (like halite, or salt-ssh).  So the code is fine, but splitting it up into its parts has complicated the packaging step.

Technically, a "release" of salt is just a tag in the git repo that points to a certain point in the code. 

Rob McBroom

unread,
Oct 8, 2013, 4:03:45 PM10/8/13
to salt-...@googlegroups.com
On Tue Oct 08 2013 at 14:47:10, Colton Myers wrote:

Because we don't do the packaging in-house (thank you, community!), it's hard to keep track of which packages have hit their respective mirrors at any given time.

What about http://docs.saltstack.com/? It still claims “Current Salt release: 0.16.4”.

Thanks.

-- 
Rob McBroom
<http://www.skurfer.com/>

Les Mikesell

unread,
Oct 8, 2013, 4:07:16 PM10/8/13
to salt-users
On Tue, Oct 8, 2013 at 2:24 PM, Colton Myers <colton...@gmail.com> wrote:
>
> Well, we know the code is working, as we (and others) have been testing it.
> But we want people to be able to install just the pieces of salt they need
> (like halite, or salt-ssh). So the code is fine, but splitting it up into
> its parts has complicated the packaging step.
>
> Technically, a "release" of salt is just a tag in the git repo that points
> to a certain point in the code.

Well, yeah, that's what it means to a developer. But when a user
hears the 'release' word he sort of expects to it to install and work
- and it is particularly problematic in a multi-platform environment
when you don't know what to expect from mixed versions and some
versions aren't ready.

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

Clint Dilks

unread,
Oct 8, 2013, 4:44:04 PM10/8/13
to salt-...@googlegroups.com





Well, yeah, that's what it means to a developer.   But when a user
hears the 'release' word he sort of expects to it to install and work
- and it is particularly problematic in a multi-platform environment
when you don't know what to expect from mixed versions and some
versions aren't ready.

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


It's easy to complain about stuff like this, but if it really matters to you volunteer to become part of the process making things better.
The SaltStack Team can only be responsible for their product, not how every different distribution packages it. 
Also remember that for a lot of distributions the people doing packaging are doing so on a volunteer basis.

If you are managing multiple distributions then managing the differences between them is just part of the process. And if a distributions packaging doesn't work for you, you are free to package the software yourself or pay someone to do it for you.


Les Mikesell

unread,
Oct 8, 2013, 5:12:34 PM10/8/13
to salt-users
On Tue, Oct 8, 2013 at 3:44 PM, Clint Dilks <cli...@waikato.ac.nz> wrote:
>
> It's easy to complain about stuff like this, but if it really matters to you
> volunteer to become part of the process making things better.
> The SaltStack Team can only be responsible for their product, not how every
> different distribution packages it.
> Also remember that for a lot of distributions the people doing packaging are
> doing so on a volunteer basis.

I'm not complaining about the speed that things get done. I
understand that sort of thing. What I'm complaining about is
announcing something on a -users list when it doesn't really exist as
far as users go. And maybe it's just me, but I think it makes it
hard to take a project seriously when things are announced but when
you try to grab a copy it isn't there.

> If you are managing multiple distributions then managing the differences
> between them is just part of the process.

Agreed - and one of my strategies for that is to not rely on things
that make this difficult.

> And if a distributions packaging
> doesn't work for you, you are free to package the software yourself or pay
> someone to do it for you.

Again, that's not the issue. I'm only commenting because I think it
makes a project look bad to announce things that aren't available - or
at least it takes away a lot of the excitement when you have to spend
several days trying to get a copy installed and by then you've
forgotten what the new features were and why you wanted it.

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

Shawn Milochik

unread,
Oct 8, 2013, 5:27:04 PM10/8/13
to salt-...@googlegroups.com
On Tue, Oct 8, 2013 at 5:12 PM, Les Mikesell <lesmi...@gmail.com> wrote:
On Tue, Oct 8, 2013 at 3:44 PM, Clint Dilks <cli...@waikato.ac.nz> wrote:
>
> It's easy to complain about stuff like this, but if it really matters to you
> volunteer to become part of the process making things better.
> The SaltStack Team can only be responsible for their product, not how every
> different distribution packages it.
> Also remember that for a lot of distributions the people doing packaging are
> doing so on a volunteer basis.

I'm not complaining about the speed that things get done.  I
understand that sort of thing.  What I'm complaining about is
announcing something on a -users list when it doesn't really exist as
far as users go.   And maybe it's just me, but I think it makes it
hard to take a project seriously when things are announced but when
you try to grab a copy it isn't there.

Saying things like "makes it hard to take a project seriously" is unhelpful. You are unlikely to win friends and influence people. 


> If you are managing multiple distributions then managing the differences
> between them is just part of the process.

Agreed - and one of my strategies for that is to not rely on things
that make this difficult.


Implying that the project maintainers' work isn't up to your standards without offering to help is not going to get you anywhere.

 
> And if a distributions packaging
> doesn't work for you, you are free to package the software yourself or pay
> someone to do it for you.

Again, that's not the issue.  I'm only commenting because I think it
makes a project look bad to announce things that aren't available - or
at least it takes away a lot of the excitement when you have to spend
several days trying to get a copy installed and by then you've
forgotten what the new features were and why you wanted it.

Claiming someone is likely to forget what the new features are or why they wanted them is really a ridiculous claim. All this comes across as whining and pouting. The fact is that the PPA packages are delayed. In the meantime, you have other means of acquiring and installing the latest version. If you're not part of the solution but continue to complain, you become part of the problem. People remember "bad" community members and are less willing to help them in the future. Consider your role in this community.

 

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

--

Shawn 

Clint Dilks

unread,
Oct 8, 2013, 5:41:09 PM10/8/13
to salt-...@googlegroups.com



Again, that's not the issue.  I'm only commenting because I think it
makes a project look bad to announce things that aren't available - or
at least it takes away a lot of the excitement when you have to spend
several days trying to get a copy installed and by then you've
forgotten what the new features were and why you wanted it.

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



Honestly I think what you are commenting on is a matter of process.
For myself monitoring release information here means for installs using a process based on git,
but if using a package then I would monitor the release information provided by the distribution repository used.

Les Mikesell

unread,
Oct 8, 2013, 5:46:17 PM10/8/13
to salt-users
On Tue, Oct 8, 2013 at 4:27 PM, Shawn Milochik <shawn...@gmail.com> wrote:
>
>> I'm not complaining about the speed that things get done. I
>> understand that sort of thing. What I'm complaining about is
>> announcing something on a -users list when it doesn't really exist as
>> far as users go. And maybe it's just me, but I think it makes it
>> hard to take a project seriously when things are announced but when
>> you try to grab a copy it isn't there.
>
>
> Saying things like "makes it hard to take a project seriously" is unhelpful.
> You are unlikely to win friends and influence people.

OK, if the project doesn't care how they are perceived, just ignore me.

>> > If you are managing multiple distributions then managing the differences
>> > between them is just part of the process.
>>
>> Agreed - and one of my strategies for that is to not rely on things
>> that make this difficult.
>>
>
> Implying that the project maintainers' work isn't up to your standards
> without offering to help is not going to get you anywhere.

How can I help at stopping 'vaporware' announcements with anything but
saying how I react to them? I don't really expect a way-below 1.0
release to be production-ready and there's nothing I can do to fix
that part.

> Claiming someone is likely to forget what the new features are or why they
> wanted them is really a ridiculous claim. All this comes across as whining
> and pouting.

Fine, I'm whiny and pouty. But I doubt that I'm the only one wishing
I could trust salt salt in production with a reasonable upgrade
strategy.

>The fact is that the PPA packages are delayed. In the meantime,
> you have other means of acquiring and installing the latest version.

Once again, I'm not complaining about the timing of the actual release.

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

Les Mikesell

unread,
Oct 8, 2013, 5:51:00 PM10/8/13
to salt-users
On Tue, Oct 8, 2013 at 4:41 PM, Clint Dilks <cli...@waikato.ac.nz> wrote:
>
> Honestly I think what you are commenting on is a matter of process.
> For myself monitoring release information here means for installs using a
> process based on git,
> but if using a package then I would monitor the release information provided
> by the distribution repository used.

So how does that play out in a mixed environment?

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

Clint Dilks

unread,
Oct 8, 2013, 7:25:50 PM10/8/13
to salt-...@googlegroups.com
I'm not quite sure what you are meaning here, but I think the answer to this really depends on your operational needs.  It will also depend on what you believe about automatic updates.  Personally I always want to have to initiate an update process in some way.

We don't just have a single Salt Master / Minion version combination at one time, we will normally have at least 3.  In all cases we try and have the Master and Minion version match

So for Example

A Salt Master that older than what is being released by most distributions - minions connected to this generally only change at set times with a lot of process for exceptions

A Salt Master that runs the latest salt packages provided by the distributions we use.  The update should be available for all before a change here

A Salt Master running the latest salt that we want to be using

Other Masters may be created for testing and etc as needed.

We then have the flexibility to determine which Master a Minion connects to, depending on its needs

Colton Myers

unread,
Oct 8, 2013, 7:26:22 PM10/8/13
to salt-...@googlegroups.com
First, with regards to the next release of Salt, you should revisit Tom's original announcement.  There he talked about our versioning scheme going forward, and the reason for code-names on releases.  The next release is codenamed Hydrogen, and the version will depend on the month it is released.  We expect a November release, in which case it will be 13.11.0.

Here's my take on packaging:

90% of the time, everything but EPEL is live at our release announcement.  EPEL users are used to this, and tend to be patient as a result.  (We are getting faster here, thanks to kaptk2 and terminalmage!)

The fact is, this is a one-off instance where the PPA is not ready, and we apologize for the delay.  We are very excited about 0.17, and so maybe announced it before we should have.

However, there are limits to what we can guarantee on the community side of things.  We love our community and want to support you as best we can, but because we don't have dedicated resources for packaging (it's mostly community-driven) it limits the coordination with which we can release.

Think of it this way.  If we wanted every OS's packages to hit the mirrors at exactly the same time, it would take an enormous amount of coordination.  EPEL tends to be the slowest, so I'll use them as an example.  We have to get everything building and passing all the tests and approved, which usually takes a day or two, then we push the packages to epel-testing, which can take up to 24-48 hours depending on when the packages actually go live and when the mirrors refresh.  On the other hand, debian.saltstack.com can go live very quickly as we host those packages ourselves.

So in this case, we pushed EPEL, expecting the ppa would probably hit first anyway, but it didn't.  So now epel-testing has the latest release -- anyone who runs a yum update will get 0.17.0.  So do we hold off the release announcement at this point?

Or maybe we hold off the release announcement until it hits EPEL stable, 2+ weeks later.

We'll try to coordinate better in the future, but you have to be patient with us.

Sorry if I sound frustrated -- I think my 2 hours at Les Schwab tire this afternoon used up most of my patience.  ;)

--
Colton Myers



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

--

Les Mikesell

unread,
Oct 9, 2013, 12:26:12 AM10/9/13
to salt-users
On Tue, Oct 8, 2013 at 6:26 PM, Colton Myers <colton...@gmail.com> wrote:
>
> Think of it this way. If we wanted every OS's packages to hit the mirrors
> at exactly the same time, it would take an enormous amount of coordination.

Hitting at the same time would be nice, but not quite my point. What
I'm suggesting is that they all be there when you say they are
released - at least in a user's forum.

> So in this case, we pushed EPEL, expecting the ppa would probably hit first
> anyway, but it didn't. So now epel-testing has the latest release -- anyone
> who runs a yum update will get 0.17.0. So do we hold off the release
> announcement at this point?

I think it makes sense to run your master on something as stable as
RHEL or CentOS - but I'm sure others will disagree. And if minions
shouldn't update before the master, I think that means holding them
all off.

> Or maybe we hold off the release announcement until it hits EPEL stable, 2+
> weeks later.

I can handle typing --enablerepo=epel-testing. I'd just like to know
when it will work...

> We'll try to coordinate better in the future, but you have to be patient
> with us.

I understand the difficulty and only mention it because I think there
would be even more interest in salt if seemed like you could deploy it
in large mixed environments without creating a headache with future
updates. Maybe I'm just missing something about how that is supposed
to happen.

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

Mitch Anderson

unread,
Oct 9, 2013, 12:47:29 AM10/9/13
to salt-...@googlegroups.com
On Tue, Oct 8, 2013 at 10:26 PM, Les Mikesell <lesmi...@gmail.com> wrote:
I understand the difficulty and only mention it because I think there
would be even more interest in salt if seemed like you could deploy it
in large mixed environments without creating a headache with future
updates.  Maybe I'm just missing something about how that is supposed
to happen.

If I'm concerned about concurrency and making sure package versions are absolutely identical across the board, I would typically copy/sync remote repo packages to a local repo and have my systems pull from that... essentially the same process is applied for windows updates and WSUS...  

Les Mikesell

unread,
Oct 9, 2013, 1:55:55 AM10/9/13
to salt-users
Sure, but I don't see how that helps with the underlying problem of
knowing when the packages for all the platforms in your enterprise are
available. It just makes it more high-maintenance.

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

Corey Quinn

unread,
Oct 9, 2013, 2:00:53 AM10/9/13
to salt-...@googlegroups.com
While Les tends to make his point with the subtlety and tact of a well-thrown rock, he's absolutely right; this isn't a sustainable approach as Salt increasingly becomes a serious contender in the enterprise space.

I'll be starting conversations with the various packagers / stakeholders in the coming weeks to try to further address this; thanks for the feedback!

-- Corey

Les Mikesell

unread,
Oct 9, 2013, 2:39:19 AM10/9/13
to salt-users
On Wed, Oct 9, 2013 at 1:00 AM, Corey Quinn <co...@sequestered.net> wrote:
>
> While Les tends to make his point with the subtlety and tact of a well-thrown rock, he's absolutely right; this isn't a sustainable approach as Salt increasingly becomes a serious contender in the enterprise space.
>
> I'll be starting conversations with the various packagers / stakeholders in the coming weeks to try to further address this; thanks for the feedback!
>

I've just been spoiled by projects like Jenkins and OpenNMS where
perhaps the java base makes the cross-platform part easier, but they
not only host their own packages for several platforms but also have
separate release tracks for stable and less stable versions making it
easier to follow and test new features without breaking your
production systems.

However, part of my problem may be that I just don't understand how
it is supposed to be done. Are there any best-practices guidelines on
how you should plan to deploy and manage a large multi-platform
system?

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

Kent Tenney

unread,
Oct 9, 2013, 10:54:35 AM10/9/13
to salt-...@googlegroups.com
I'm another keeping a close eye on the ppa, too timid to ask about ETA.
This thread has explained limitations of the Salt folks and the
concerns of the users.

I'd recommend a bit of boilerplate included in each release announcement
which offered this explanation, delineating the options, their pros and cons.

Assume that the post is the first one a new list subscriber has seen.

Thanks,
Kent


On Wed, Oct 9, 2013 at 1:00 AM, Corey Quinn <co...@sequestered.net> wrote:
>

Corey Quinn

unread,
Oct 9, 2013, 11:57:12 AM10/9/13
to salt-...@googlegroups.com


> On Oct 8, 2013, at 11:39 PM, Les Mikesell <lesmi...@gmail.com> wrote:
>
>> On Wed, Oct 9, 2013 at 1:00 AM, Corey Quinn <co...@sequestered.net> wrote:
>>
>> While Les tends to make his point with the subtlety and tact of a well-thrown rock, he's absolutely right; this isn't a sustainable approach as Salt increasingly becomes a serious contender in the enterprise space.
>>
>> I'll be starting conversations with the various packagers / stakeholders in the coming weeks to try to further address this; thanks for the feedback!
>>
>

Before I dive into this, it's worth pointing out that I don't work or speak for Saltstack; I'm a just a community member with strong opinions.

> I've just been spoiled by projects like Jenkins and OpenNMS where
> perhaps the java base makes the cross-platform part easier, but they
> not only host their own packages for several platforms but also have
> separate release tracks for stable and less stable versions making it
> easier to follow and test new features without breaking your
> production systems.

Right-- and I want to emulate that here.

> However, part of my problem may be that I just don't understand how
> it is supposed to be done. Are there any best-practices guidelines on
> how you should plan to deploy and manage a large multi-platform
> system?

Glad you asked-- yes!

In any environment that's larger than a couple of dozen systems, a best practice is to have your own local package repository. At that point, you can approve what gets added to that repository (from upstream; usually you're not rolling your own packages) on a granular basis. You can also have staging/test environments that get newer versions of things added to their repositories, test accordingly (for bonus points, in an automated fashion), and then approve things for release during a maintenance window ("At 5PM-8PM today we'll be upgrading our Salt infrastructure to Salt release 10.11: Slippery Dingus...") that fits your needs.

Blindly trusting upstream for packages that you throw unvetted into production will blow up in your face sooner or later.

I'd also suggest that above a certain size of environment, there's merit to pursuing Salt Enterprise; this lets you put a lot of that responsibility onto a longer term supported release, and blame Dave (I always blame Dave) if things aren't working perfectly. I get that that's not where everyone may choose to go, but I appreciate that the option is out there.

Other best practices off the top of my head:
* If you're dropping binary files, libraries, etc. into place with configuration management, STOP IT. Put it in a system package; there are a number of ways to do this, and it keeps you from shooting yourself in the metaphorical face.
* If your Salt state and Pillar trees aren't in separate git repositories (or worse, aren't in version control at all) fix that today. It will save your bacon, and it nicely separates code from data along very clean lines. Note that this may require a refactor to use Pillar properly in your states.
* Have a test suite you can run against your state tree. "Oh, I can just revert to a previous version" is great in theory, but if your bad version blows away data on the servers it's invoked upon, rolling back won't save you.
* Set your minions to run highstate upon connect. This neatly solves the problem of "how do I stop my servers from coming up with old code" without sacrificing the push based model.
* If you're using cron or similar to schedule your highstate runs, do it on the master, not the minions. One touchpoint to turn that off (and there are a few reasons you might want to do that temporarily) is far superior to having a touchpoint on every minion.

Anyone have anything to add?

-- Corey

Les Mikesell

unread,
Oct 9, 2013, 3:07:44 PM10/9/13
to salt-users
On Wed, Oct 9, 2013 at 10:57 AM, Corey Quinn <co...@sequestered.net> wrote:
>
>> However, part of my problem may be that I just don't understand how
>> it is supposed to be done. Are there any best-practices guidelines on
>> how you should plan to deploy and manage a large multi-platform
>> system?
>
> Glad you asked-- yes!
>
> In any environment that's larger than a couple of dozen systems, a best practice is to have your own local package repository. At that point, you can approve what gets added to that repository (from upstream; usually you're not rolling your own packages) on a granular basis. You can also have staging/test environments that get newer versions of things added to their repositories, test accordingly (for bonus points, in an automated fashion), and then approve things for release during a maintenance window ("At 5PM-8PM today we'll be upgrading our Salt infrastructure to Salt release 10.11: Slippery Dingus...") that fits your needs.

How does that part scale when you have several linux and windows
distros, each with a certain number of servers running at different
versions and update levels, and where you intentionally do not change
all of anything at once? Do people really maintain 50 snapshots of
assorted package update repositories for this so they have one for
each distro/version in every state they might need?

> Blindly trusting upstream for packages that you throw unvetted into production will blow up in your face sooner or later.

I really don't think I can vet packages any better than RHEL/CentOS or
SUSE. And I'd rather just avoid introducing packages that aren't
already vetted to those levels. The 'blowing up in your face' part
is always possible from other causes (like admin/operator error. from
overcomplicating things..) anyway and has to be covered by redundancy,
not changing everything at once, and a plan to back out changes,

> I'd also suggest that above a certain size of environment, there's merit to pursuing Salt Enterprise; this lets you put a lot of that responsibility onto a longer term supported release, and blame Dave (I always blame Dave) if things aren't working perfectly. I get that that's not where everyone may choose to go, but I appreciate that the option is out there.

That's fair enough. But is Dave going to recommend making a change on
every system at once? That's not going to happen here. Or do you
break things up into several different master/minion sets for
resilience?

> Other best practices off the top of my head:
> * If you're dropping binary files, libraries, etc. into place with configuration management, STOP IT. Put it in a system package; there are a number of ways to do this, and it keeps you from shooting yourself in the metaphorical face.

We do have lots of windows servers running lots of hand-installed
local applications and libraries. They are carefully versioned and
managed, but the process isn't automated well. Is there a good way
to automate that?

> * If your Salt state and Pillar trees aren't in separate git repositories (or worse, aren't in version control at all) fix that today. It will save your bacon, and it nicely separates code from data along very clean lines. Note that this may require a refactor to use Pillar properly in your states.

I was sort of hoping subversion would be supported in pillar
someday... Aside from managing the salt minions themselves across a
bunch of platforms which I realize is a special case, the piece that
I'm missing that is vital in our scenario is how you would migrate a
set of changes (say an application update that might require some
different configuration settings), from development/testing to a
subset of production at a time with a tightly controlled schedule and
a backout plan.

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

Ollie Walsh

unread,
Dec 17, 2013, 9:12:00 AM12/17/13
to salt-...@googlegroups.com
How is deprecation supposed to work with the new versioning scheme? The docs assume we can predict the next 2 major versions -  http://docs.saltstack.com/topics/development/deprecations.html

Thanks,
Ollie



Colton Myers

unread,
Dec 17, 2013, 1:05:38 PM12/17/13
to salt-...@googlegroups.com
Current deprecation warnings will cite a specific codename.  Since we know the order of the periodic table of elements, it's not a problem.  The next two releases after Hydrogen (which will likely be version 14.1.0) will be codenamed Helium and Lithium.

--
Colton Myers

Colton Myers

unread,
Dec 17, 2013, 1:07:57 PM12/17/13
to salt-...@googlegroups.com
Ah, we do need to change the deprecation documentation, though.

--
Colton Myers

Ollie Walsh

unread,
Dec 17, 2013, 8:01:10 PM12/17/13
to salt-...@googlegroups.com
Hi Colton,

>> Since we know the order of the periodic table of elements, it's not a problem
google knows the order of the periodic table. I would struggle after the first few :-)

The more I think about the new versioning scheme the more worried I am. It walks, talks and quacks like semantic versioning. This will cause a lot of confusion and make integration into larger systems more difficult.

With the new versioning scheme:
Will 3rd party code written for 14.01.0 work with 14.02.0? The version suggests it should.
Will 3rd party code written for 14.01.0 work with 15.01.0? The version suggests if should not.

Right now (assuming http://semver.org/):
0.x.y tells me the API is currently unstable.
1.x.y would tell me that any 3rd party code written for this version *should* be compatible with version a.b.c where a == 1 && (b >= x || (b == x && c >= y)) . This dependency is easy to specify in setuptools, dpkg etc... etc...

If the versioning scheme is to change to a date based scheme I think at the very least is shouldn't look anything like semantic versioning. E.g the pytz versions (2013.8 etc..) are clearly date based.

Cheers,
Ollie




Colton Myers

unread,
Dec 18, 2013, 1:42:31 PM12/18/13
to salt-...@googlegroups.com
Thanks for your well-stated opinion, Ollie.  You make very good points, I'll make sure Tom gets eyes on this.

--
Colton Myers

Colton Myers

unread,
Dec 23, 2013, 6:16:35 PM12/23/13
to salt-...@googlegroups.com
I brought these points up to Tom, and he totally agrees.  We now plan to add the 20 on the front.  (2014.01.0 will likely be our first release on this new scheme)

--
Colton Myers

Tom Hallam

unread,
Dec 27, 2013, 9:54:30 AM12/27/13
to salt-...@googlegroups.com
Surprised that you say release numbers are arbitrary. The dotted notation is not meant to be: it's meant to tell you about levels of change and compatibility.

When using the version notation A.B.C

A - is a major version with changes that may not be backwards compatible.
B - is a minor version with changes that are backwards compatible.
C - is a bug fix with no external changes other than reversion to documented behaviour

Maybe this is "old school" that has been forgotten.
If you're going to use dates then how about using the ANSI date format 2013-12-25 so it's clear you are not using a dotted version as above?

Luminous Salt

unread,
Dec 27, 2013, 10:12:16 AM12/27/13
to salt-...@googlegroups.com
On 2013-12-27 09:54, Tom Hallam wrote:
> Surprised that you say release numbers are arbitrary. The dotted
> notation is not meant to be: it's meant to tell you about levels of
> change and compatibility.
>
> When using the version notation A.B.C
>
> A - is a major version with changes that may not be backwards
> compatible.
> B - is a minor version with changes that are backwards compatible.
> C - is a bug fix with no external changes other than reversion to
> documented behaviour
>
> Maybe this is "old school" that has been forgotten.

Certainly not, lest I sure hope not: this is clear and consistent.

What is the reasoning for date-based in place of something sensible?

Is salt not building towards a 1.0, stabilized, release?

If SaltStack is a _framework_ of tools and components we're supposed to
use to build cool stuff with, we need to rely on the internals to some
degree. How does the date-based versioning scheme work to communicate
breakage of these expectations?
Reply all
Reply to author
Forward
0 new messages