|Salt 0.17.0 is FINALLY here!||Thomas Hatch||10/2/13 5:05 PM|
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.
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Shawn Milochik||10/2/13 7:27 PM|
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)
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Dmitry Golubenko||10/2/13 11:45 PM|
В Срд, 02/10/2013 в 18:05 -0600, Thomas S Hatch пишет:
> I cut the release last Friday and we have been packaging and preppingAwesome!
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Ran Leibman||10/3/13 1:05 AM|
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 !
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Thomas Hatch||10/3/13 7:10 AM|
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...
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||LesMikesell||10/3/13 8:25 AM|
On Thu, Oct 3, 2013 at 9:10 AM, Thomas S Hatch <that...@gmail.com> wrote: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?
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Shawn Milochik||10/3/13 9:10 AM|
Please ask your question in a new thread, since it's not relevant to this topic. I can probably help answer it there.
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Ran Leibman||10/3/13 9:50 AM|
Thanks Thomas, salt-ssh indeed looks pretty straight forward
Is there any docs about the state.sls runner ?
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Rach Belaid||10/3/13 4:26 PM|
Amazing release !!!
This made my day :)
Flat 9 240B Amhurst Road, London N16 7UL
Phone : +44 75 008 660 84
|Re: Salt 0.17.0 is FINALLY here!||Greg Miell||10/4/13 1:46 AM|
Wonderful news, looking forward to getting our infrastructure updated with 0.17.0. On that note, any news on the rpms?
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Thomas Hatch||10/4/13 4:23 AM|
RPMs should be available in EPEL testing.
On Fri, Oct 4, 2013 at 2:46 AM, Greg Miell <gr...@greg-net.co.uk> wrote:
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/4/13 9:00 AM|
The exception is Halite. We're still in the review phase for salt-halite, as it's a new package.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Greg Miell||10/4/13 9:18 AM|
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?
Web Consultant and Developer
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Erik Johnson||10/4/13 10:25 AM|
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
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Sean Plaice||10/4/13 11:37 AM|
Will deb's be released to the saltstack ppa? If so, when?
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/4/13 1:47 PM|
Are they not there yet? I was under the impression they were already up.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Shawn Milochik||10/4/13 1:50 PM|
On Fri, Oct 4, 2013 at 4:47 PM, Colton Myers <colton...@gmail.com> wrote:
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/4/13 1:51 PM|
OK, I'll contact the packager for Ubuntu and we'll get them up.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Corey Quinn||10/4/13 2:38 PM|
Working on it. ;-)
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Shawn Milochik||10/4/13 2:40 PM|
Thank you. I'll keep trying intermittently. This is going to be great. :o)
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/4/13 3:05 PM|
On Fri, Oct 4, 2013 at 3:40 PM, Shawn Milochik <shawn...@gmail.com> wrote:
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Sean Plaice||10/4/13 3:53 PM|
Thank you Corey.
On Friday, October 4, 2013 2:38:32 PM UTC-7, Corey Quinn wrote:
|Re: Salt 0.17.0 is FINALLY here!||Joseph Lisee||10/4/13 5:16 PM|
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".
|Salt 0.17.0 is FINALLY here!||Manuel Suarez||10/5/13 10:26 AM|
Great news thanks you for the Hard working of the community.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/6/13 9:58 AM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Shawn Milochik||10/7/13 7:30 AM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Thomas Hatch||10/7/13 1:58 PM|
As for Salt Thin, after installing salt you can execute a runner that generates the salt-thin tarball:
On Mon, Oct 7, 2013 at 8:30 AM, Shawn Milochik <shawn...@gmail.com> wrote:
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Cory Wright||10/7/13 2:16 PM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Trevor Joynson||10/8/13 4:27 AM|
There still aren't packages in the PPA?
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Joe Healy||10/8/13 5:15 AM|
On Tue, Oct 08, 2013 at 07:27:42AM -0400, Trevor Joynson 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.
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 8:37 AM|
On Tue, Oct 8, 2013 at 7:15 AM, Joe Healy <joeh...@gmail.com> wrote: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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Trevor Joynson||10/8/13 9:29 AM|
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)
On Tue, Oct 8, 2013 at 8:15 AM, Joe Healy <joeh...@gmail.com> wrote:
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/8/13 11:47 AM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 12:05 PM|
On Tue, Oct 8, 2013 at 1:47 PM, Colton Myers <colton...@gmail.com> wrote: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
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/8/13 12:24 PM|
If a release makes changes that affect packaging, how do you even know
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.
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Rob McBroom||10/8/13 1:03 PM|
What about http://docs.saltstack.com/? It still claims “Current Salt release: 0.16.4”.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 1:07 PM|
On Tue, Oct 8, 2013 at 2:24 PM, Colton Myers <colton...@gmail.com> wrote: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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Clint Dilks||10/8/13 1:44 PM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 2:12 PM|
On Tue, Oct 8, 2013 at 3:44 PM, Clint Dilks <cli...@waikato.ac.nz> 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.
Agreed - and one of my strategies for that is to not rely on things
that make this difficult.
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Shawn Milochik||10/8/13 2:27 PM|
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:
Saying things like "makes it hard to take a project seriously" is unhelpful. You are unlikely to win friends and influence people.
Implying that the project maintainers' work isn't up to your standards without offering to help is not going to get you anywhere.
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Clint Dilks||10/8/13 2:41 PM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 2:46 PM|
On Tue, Oct 8, 2013 at 4:27 PM, Shawn Milochik <shawn...@gmail.com> wrote:OK, if the project doesn't care how they are perceived, just ignore me.
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
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
Once again, I'm not complaining about the timing of the actual release.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 2:51 PM|
On Tue, Oct 8, 2013 at 4:41 PM, Clint Dilks <cli...@waikato.ac.nz> wrote:So how does that play out in a mixed environment?
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Clint Dilks||10/8/13 4:25 PM|
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
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||10/8/13 4:26 PM|
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. ;)
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 9:26 PM|
On Tue, Oct 8, 2013 at 6:26 PM, Colton Myers <colton...@gmail.com> wrote: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.
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
I can handle typing --enablerepo=epel-testing. I'd just like to know
when it will work...
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
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Mitch Anderson||10/8/13 9:47 PM|
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
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...
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 10:55 PM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Corey Quinn||10/8/13 11:00 PM|
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!
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/8/13 11:39 PM|
On Wed, Oct 9, 2013 at 1:00 AM, Corey Quinn <co...@sequestered.net> wrote: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
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
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||ktenney||10/9/13 7:54 AM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Corey Quinn||10/9/13 8:57 AM|
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.
Right-- and I want to emulate that here.
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?
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||LesMikesell||10/9/13 12:07 PM|
On Wed, Oct 9, 2013 at 10:57 AM, Corey Quinn <co...@sequestered.net> wrote: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?
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,
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
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?
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Ollie Walsh||12/17/13 6:12 AM|
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
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||12/17/13 10:05 AM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||12/17/13 10:07 AM|
Ah, we do need to change the deprecation documentation, though.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||Ollie Walsh||12/17/13 5:01 PM|
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.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||12/18/13 10:42 AM|
Thanks for your well-stated opinion, Ollie. You make very good points, I'll make sure Tom gets eyes on this.
|Re: [salt-users] Re: Salt 0.17.0 is FINALLY here!||basepi||12/23/13 3:16 PM|
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)
|Salt 0.17.0 is FINALLY here!||Tom Hallam||12/27/13 6:54 AM|
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.
Maybe this is "old school" that has been forgotten.
|Re: [salt-users] Salt 0.17.0 is FINALLY here!||Luminous Salt||12/27/13 7:12 AM|
On 2013-12-27 09:54, Tom Hallam wrote: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?