Starting a new module is not acceptable, but adding state=version semantics (which did not exist before), I'd be fine with.
On Thu, Jan 2, 2014 at 5:43 PM, C. S. <[email protected]> wrote: > Yes. It’s the documented behavior of yum actually, “install” means > “upgrade to”, and the ansible module extends that behavior to the > playbooks. > > The yum module also mentions it being an upgrade command as well. > > e.g. line 103 [1]: > > - name: install the latest version of Apche from the testing repo > yum: name=httpd enablerepo=testing state=installed > > > It would be nice if it worked as you’d expect, but I guess yum > historically an "update manager", so the commands are interpreted with that > understanding, and changing the module at this point it might cause > people’s playbooks to downgrade something unexpectedly… maybe just starting > a new module all together is another option… > > [1] > https://github.com/ansible/ansible/blob/devel/library/packaging/yum#L103 > > On Jan 2, 2014, at 13:57 , Michael DeHaan <[email protected]> > wrote: > > Tested? > > > > > On Thu, Jan 2, 2014 at 4:53 PM, C. S. <[email protected]> wrote: > >> 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. >> > > > > -- > 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.
