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 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.
