The name specifier only works on upgrades though, not downgrades… e.g. This would succeed, but you’d still have 1.2.3 installed instead of 1.2.2. yum: name=foo-1.2.3 yum: name=foo-1.2.2
On Jan 2, 2014, at 13:48 , Michael DeHaan <[email protected]> wrote: > 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. -- 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.
