Python package incorrect for CentOS 5

[Drachemann]

The python package specified in the map.jinja file is incorrect for CentOS 5.
I'm not sure if this also affects Redhat

The correct package name is 'python26-mysqldb'
Not sure of the best way to fix this.. Obviously the grain "osmajorrelease" will allow determination of the os version..
Is there a way to add a further condition to the grains.filter_by in the map?

[whiteinge]

Installing Python 2.6 via EPEL on Cent 5 is extremely common but it's not the default so I think the best way to approach this is for people to override this package name via Pillar when the python26- package is preferred.

[Drachemann]

Agreed that it's possible to install python 2.6 via other methods.. however it could be argued that using EPEL is the "default" as it's the recommend way in the SaltStack documentation. (http://docs.saltstack.com/en/latest/topics/troubleshooting/#red-hat-enterprise-linux-5)

Anyway, can just document it in the readme and plilar.example for now I guess, I'd still like to know if there's an easy way to filter this for future reference..

[whiteinge]

You're right, of course, that EPEL is very likely to be enabled since that is how the vast majority of users will install Salt. We still can't make the assumption that also means users will want the Python 2.6 MySQL adapter. This is the reason that map.jinja values can be overridden via Pillar. Out of curiosity, are you looking to avoid using Pillar here?

In answer to your question, you could chain multiple filter_by calls together to match on multiple grains. Or you could match on a more specific grain such as the os_finger grain.

[Drachemann]

Fair call. Not looking to avoid using Pillar.. To be honest it's just the nit-picking perfectionist in me that thinks it's technically incorrect default behaviour to install the mysql-python package in RHEL/CentOS 5, as it's a python 2.4 package and will never meet the requirements for the formula.

Again, not THAT big a deal.. :P

I think it's at least worth mentioning in the documentation. And cheers, I'll try the filter_by chaining to see if I can achieve what I want.

[whiteinge]

will never meet the requirements for the formula.

Ah ha! I see where you're coming from now! I was thinking of this from "managing a MySQL installation" perspective and you're coming at this from a "using the formula" perspective.

You're right there's several states in this formula that call to Salt's MySQL execution module which requires the Python 2.6 db adapters since Salt requires Python 2.6. You're exactly right that dep should definitely be called out in the README. IMO the states that call out the MySQL execution/state modules should be moved into separate .sls files so that using them is an explicit opt-in rather than a hard requirement for the whole formula.

Sorry it took me a couple replies to get on the same page there. :-P

[noelmcloughlin]

#186 introduced osfamilymap and osmap. The Centos package should be fixed now.