Keep up the good work !
--
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.
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 ...
--
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.
Wonderful news, looking forward to getting our infrastructure updated with 0.17.0. On that note, any news on the rpms?Greg
--
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.
RPMs should be available in EPEL testing.
Are they not there yet? I was under the impression they were already up.
Thank you. I'll keep trying intermittently. This is going to be great. :o)
--
Working on it. ;-)
Manuel
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'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.
There still aren't packages in the PPA?
What's holding this up? If I provide sdebs can we get this uploaded?
)) Trevor Joynson (trevorj)
(( Network Ninja
)) Localhost Solutions (LocSol)
(( https://www.localhostsolutions.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?
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.
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
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
--
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.
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.
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?