What I was saying above: yum: name=foo-1.2.3
installs version 1.2.3 from the yum repo. It supports yum version specifiers in the name. We do not need extra states to do this, in other words. If we did, regardless, we'd just do state=version and would not want to specify upgrade/downgrade, as that presumes knowledge of the previous state of the system. On Thu, Jan 2, 2014 at 1:51 AM, CS <[email protected]> wrote: > FWIW, on a related note to managing packages and versions... > > > OTOH, my philosophy is usually to maintain a yum mirror of exactly what > I want on all of my systems, and then have the packages do state=latest all > the time, rather than have mixed minor versions but consistent major > versions throughout my environment. > > In our case our yum repos get updated from CI, so state=latest wouldn't > work for us because we need to be able to install specific builds and pin > environments to them. Additionally we need to be able to roll back builds, > which requires some hackery... > > The problem with rollbacks is that state=installed is technically an > upgrade command, so specifying a previous version of an RPM actually causes > it to do nothing and return success. So we do a string compare on the RPM > name to see if it differs and then remove the old RPM before installing the > desired one, which works around the issue. > > Not sure if it would make more sense to make the yum module smarter, so > you could just say state=install-abs-version (or something) and it would > determine if it's an upgrade or a downgrade. Or just add a > state=downgrade option to the yum module and use the version_compare() > filter suggested to determine whether to call state=downgrade or > state=installed. Any thoughts? > > > On Tuesday, December 31, 2013 4:22 PM, Michael DeHaan < > [email protected]> wrote: > > Ah, so in your case, you want to do things like get the minor version out > and so forth. > > This seems to imply it would be best to add filters for things like major > and minor version in your case: > > when: apache_version|major ... > > etc > > OTOH, my philosophy is usually to maintain a yum mirror of exactly what I > want on all of my systems, and then have the packages do state=latest all > the time, rather than have mixed minor versions but consistent major > versions throughout my environment. > > Thus, if a security update for Apache comes out, promote that package to > your yum/apt mirror, etc... > > IIRC (as I don't use this), the yum module also supports >= math if you > want too though, like: yum: name=foo>1.2 > > The apt module does not. > > > > > > > > > > > On Tue, Dec 31, 2013 at 7:05 PM, Patrick Heeney > <[email protected]>wrote: > > The module interrogation sounds awesome. The question about the 0s and 1s > stems from the fact that only certain configuration should be applied when > specific versions are met. Without regex or breaking the version into > integers I don't know how you would compare specific versions. Heres some > examples: > > - debug: msg="this should run for apache 2.4.1 to 2.4.100" > when: apache_version|version_compare('2.4.*') == 1 > > - debug: msg="this should NOT run for apache 2.4.1 to 2.4.100" > when: apache_version|version_compare('2.4.*') == -1 > > Without the above and I wanted to run for specific versions it seems like > it would end up like this: > > - debug: msg="this should run for apache 2.2.1 to 2.4.100" > when: apache_version|version_compare('2.2.1') == 1 and > apache_version|version_compare('2.4.100') == 1 and .... hundreds of > times > > If we can only compare one number to another and have it return yes, same, > no without a way to do regex or integer comparisons then the conditionals > are going to get crazy to account for all the variations. If instead I can > have another function that returns yes this number matches this group, or > not it doesnt is what I meant with 0 and 1. > > In my specific use case I need to add a configuration file for 5.1.X only. > I need to apply another specific configuration file for 5.5.X only. Without > accounting for the X I either have to add a conditional for every version, > or rely on regex when I know the follow sem ver so it should always be > major.minor.patch. > > Whatever you decide, that is what I am am hoping to solve with my original > post. Right now I am running mysql -v | grep version register: > mysql_version and running string comparison like mysql_version.stdout in > ['5.1'] and mysql_verison.stdout in ['5.5']. It works but its pretty hacky. > > > > On Tue, Dec 31, 2013 at 4:53 PM, Michael DeHaan > <[email protected]>wrote: > > I'm suggesting we'll create a module to interrogate all package versions, > not just ones that you've setup in the role, so I don't think this > precludes the other. > > I'd probably also suggest (if you have cycles) attempting version_compare > as a filter plugin. It seems to fit in most logically and lookup plugins > are a little awkard with multiple parameters, and it's not really querying > another datasource anyway. > > I'm not sure if I understand the question about the 0's and 1's, but I'm > imagining this: > > - debug: msg="packages match" > when: current|version_compare(future) == 0 > > - debug: msg="there's no upgrade coming" > when: current|version_compare(future) != 1 > > I would highly suggest against trying to compare package versions with > regexes, both are tricksey. > > And yes, fact caching is going into 1.5. This doesn't really require > that, we could totally make a package_inventory type module now, but I was > trying to limit myself with the numbers of open design discussions open at > one time and I'm a bit unready to specify what form these should take just > yet for similar reasons. > > That being said, nothing preventing you from executing yum/apt/other as > needed (or having your own module) and nothing preventing a version_compare > being implemented now either. > > > > > > > > On Tue, Dec 31, 2013 at 6:46 PM, Patrick Heeney > <[email protected]>wrote: > > This sounds great. The only issue I have however is the fact that > sometimes my roles need to access versions that other roles may not setup. > For example if I install ubuntu and it comes with apache, will it > automatically lookup the facts of the apache version when running the > playbook even though I didn't install it? If I uninstall apache in a role > and install nginx for example then I assume it would add the nginx facts > and remove the apache ones? > > I just want to make sure that in any use case I can access the exact > version of different services that are installed. Mainly right now due to > the need of different configurations for different major versions. > > I think the plan for version compare sounds good. Hypothetically if > version_compare > compares two depending on the order, we would need another one to return 1 > or 0 based on a condition or can it be handled by the same thing? > > - template: src=apache/5.1/httpd.conf dest=/etc/apache2/httpd.conf > - when: version_compare(package_information["httpd"]["version"], > '>=2.0,<=2.4') or version_compare(version, '2.*') > or > - when: package_information["httpd"]["version"]|float >= 2.0 or > version|match('2.*') > > I get what your saying about versions being completely different, but > perhaps this function could be a regex match or strip alpha chars so you > can test integers when you know what the version "should" be. > > I didn't know about ansible-devel. I will have to make a note to post > there next time. It's great you have a plan for this. 1.5 is the one that > will include fact caching? > > > > > On Tue, Dec 31, 2013 at 4:27 PM, Michael DeHaan > <[email protected]>wrote: > > So we do have a bit of a strategic plan regarding modules to store > inventory type information, in particular with fact caching, so I have > preferences on where this goes. > > Namely, I want things to record the package versions of all installed > services and not have to rely on a register. > > Once this happens, something like this should be easily possible: > > package_information["httpd"]["version"] > > etc > > What you are asking to do regarding splitting things up, however, might > be difficult -- if not everything follows that exact format. > > Something like a lookup plugin that uses Python's "LooseVersion" support > to compare two different versions might be better than trying to split them > out and do comparisons peacemeal. > > > http://epydoc.sourceforge.net/stdlib/distutils.version.LooseVersion-class.html > > Hypothethically assume the following might exist: > > {{ version_compare(alpha, beta) }} > > which should return -1, 0, 1 depending on order. > > Perhaps this should be a Jinja2 filter, more like this: > > {{ alpha | version_compare(beta) }} > > In either case, the idea of sampling the installed versions seems to > require fact caching (this release) to really be thought out correctly > first, and I'd like to keep the numerical comparison filter/function > seperate -- and I think that avoids the need to name each part of the > version string. > > (This type of discussion is probably a better fit for ansible-devel, FWIW) > > > > > On Tue, Dec 31, 2013 at 5:45 PM, Patrick Heeney > <[email protected]>wrote: > > I have been working with ansible for a few weeks now and I thought of a > useful module idea that I really am finding myself needing a lot. I am > posting here to open up a discussion in hopes of getting it implemented. I > don't know python at the moment so I am not in a position to implement > this. > > The goal of the module would be to parse version strings of different > services (maybe files?) and break them into usable chunks for conditionals. > I am finding myself needing this a lot since I need to put different > configuration files in place depending on what version is running. For > example if the playbook is running on ubuntu 10.04 I need mysql 5.1 > configuration entries whereas ubuntu 12.04 I need mysql 5.5. > > Here is some ideas of how it would look: > > - version: name=mysql > register: mysql_version > > - debug: var=mysql_version > > mysql_version: { > version: "5.5.34" > major: 5 > minor: 5 > patch: 34 > } > > Which would be parsed from: mysql -v: "Server version: > 5.5.34-0ubuntu0.12.04.1 (Ubuntu)" > > Another example: > > - version: name=apache2 > register: apache_version > > - debug: var=apache_version > > apache_version: { > version: "2.2.22" > major: 2 > minor: 2 > patch: 22 > } > > Which would be parsed from apache2 -v: "Server version: Apache/2.2.22 > (Ubuntu)" > > If the service is not running or not found it could just return blank. > > Right now I only need it for services. In order to implement it, it can > maybe regex search search > http://stackoverflow.com/questions/82064/a-regex-for-version-number-parsing?. > > It could potentially be expanded to search files such as: version: > path=/etc/lsb-release register: distro_version which would return version: > 12.04, major 12, minor 4, patch ''. Optionally it could have the regex as > an argument and perhaps a grep to narrow it down if the file has a lot of > numbers or different format: > > - version: path=/etc/lsb-release line=RELEASE > regexp='^(\d+\\.)?(\d+\\.)?(\\*|\d+)$' > > Which could parse cat /etc/lsb-release | grep RELEASE > > What do you think? > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > Michael DeHaan <[email protected]> > CTO, AnsibleWorks, Inc. > http://www.ansibleworks.com/ > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/P_Rp4fVJYHk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > Michael DeHaan <[email protected]> > CTO, AnsibleWorks, Inc. > http://www.ansibleworks.com/ > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/P_Rp4fVJYHk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > Michael DeHaan <[email protected]> > CTO, AnsibleWorks, Inc. > http://www.ansibleworks.com/ > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Michael DeHaan <[email protected]> CTO, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
