Salvatore,
We are currently using python2.6 for more than one year inside of XS and also XCP on more than 200 hosts with ~5k vms ( part of our configuration management tools and hardware and software audit are written in python ).
How python2.6 works is this case?
You have the python from your distro which is installed on /usr/lib/python2.4 and the python binary is python. When you install the python2.6 it will be at /usr/lib/python2.6 and the python binary is python2.6, the python tree is completely separated from original shipped with the system.
The EPEL is maintained by fedora to provide new tools which aren't shipped with RedHat ( someone from RH can help me on that :D ).
To use python2.6 from EPEL you have to install the mx package from Centos and nothing more, and leaving the EPEL repo disabled it wont break or give the possibility to install/upgrade any package.
I agree with you about about see XS and XCP as an appliance, I've added into the ovs makefile a package generation ( those boxes should never have any file which aren't tracked by packages ), since XS and XCP don't have any official package maintainer to assign this task we can provide a simple way to package the ovs plugin.
[]'s
Juliano
On Jun 14, 2012, at 8:32 PM, Salvatore Orlando wrote:
Installing a new python subsystem is never an operation which should be taken lightly, especially when is performed on dom0, which is more an appliance rather than a standard linux box.
I wonder how can we guarantee that such a change won't affect XS/XCP functionality, at least for nova purposes.
Would running devstack exercises or tempest on it be sufficient in your opinion?
Out of curiosity, when you installed python26 from Epel, did it also install/upgrade other packages?
Salvatore
PS: This might be almost irrelevant, but I believe that this kind of change would not be feasible for people running commercially supported versions of XenServer.
On 14 June 2012 23:47, Willian Molinari <willian.molinari@locaweb.com.br<mailto:willian.molinari@locaweb.com.br>> wrote:
Æ!!
Just for the record:
https://review.openstack.org/#/c/8556/1 Juliano already made the patch for it! :)
--
Willian Molinari
(a.k.a PotHix)
________________________________
From: netstack-bounces+willian.molinari=locaweb.com.br@lists.launchpad.net<mailto:locaweb.com.br@lists.launchpad.net> [netstack-bounces+willian.molinari=locaweb.com.br@lists.launchpad.net<mailto:locaweb.com.br@lists.launchpad.net>] on behalf of Gary Kotton [gkotton@redhat.com<mailto:gkotton@redhat.com>]
Sent: Thursday, June 14, 2012 1:22 PM
To: Juliano Martinez
Cc: <netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>>
Subject: Re: [Netstack] ovs agent Python 2.4 support
On 06/14/2012 07:19 PM, Juliano Martinez wrote:
Roman and Gary,
I found the python2.6 on EPEL and also tested it on XS and XCP, using python2.6 from EPEL will solve this issue and we don't have to change lots lines of code to keep the compatibility.
What do we need to use it?
yum --enablerepo=base -y install mx
yum --enablerepo=epel -y install python26 python26-sqlalchemy python26-mysqldb
IMHO it will be the cleanest way to have quantum on XS and XCP ( and we already are using EPEL on we will not have any problems with it )
This changed wont affect anything on the system, and python2.6 will be use only by quantum, the system will keep using python2.4.
What do you guys think about use it?
Great idea! I suggest to try and get some more feedback from guys who are more familiar than me regarding XS and XCP
[]'s
Juliano
On Jun 14, 2012, at 2:14 AM, Gary Kotton wrote:
On 06/13/2012 11:53 AM, Roman Sokolkov wrote:
Gary, thanks for the answer!
Do I understand right about quote below?
2. I have yet to understand how Quantum runs on XCP with nova compute. Have the Quantum agent run in the same context as nova compute and send the "networking" commands in a similar way that they are done by the nova vif driver for Xen.
To be on the safe side, i will explain our schema. We use XCP as compute nodes with separate VM inside XCP for nova-compute service. What's about quantum server, it works on external node with nova-network service. Quantum agent(OVS) has started on XCP node and polls db. As I understand nova-compute takes info about instances vifs from xenapi and this info falled into db, so agent simply pulled db and made some stuff like port plugging, VLAN tagging and flow management. As for nova vif driver for XEN as I know it uses xenapi for all stuff. Do you mean implement it to agent and start it inside nova-compute VM?
Thanks for the clarification. The issue of 2.4 was discussed a bit after the meeting on Monday.
Recently I saw commits that make new agent dependencies from quantum libs. eg,
https://github.com/openstack/quantum/commit/b3366921472f1cb61bc96598d511594e1d478989 It made more and more difficult to patch it.
At the moment there is no automatic enforcement of 2.4. At the moment we are starting to use more modules from openstack-common (for example common configuration, rpc etc.) This may also prove challenging for the 2.4 compatibility.
Thanks, Roman Sokolkov
2012/6/7 Gary Kotton <gkotton@redhat.com<mailto:gkotton@redhat.com>>
On 06/06/2012 11:25 PM, Roman Sokolkov wrote:
Hello!
XCP uses only Python 2.4. But upstream version of quantum ovs agent is unsupported by Python 2.4. What do you think about? Could we keep it in supported? And what about refactoring code in favor using RPC calls? Will it be possible to use RPC with Python 2.4 ?
I am currently implementing a blueprint (
https://blueprints.launchpad.net/quantum/+spec/scalable-agent-comms) that improves quantum agents (by using RPC calls). There are a number of issues that we need to address here:
1. The python 2.4 support:
i. There is a bug open that requires enforcing that the agents run in 2.4
ii. Is this something that should be enforced by Quantum or is there another way of addressing this? Below are a few ideas:
1. Using patched versions for 2.4 support.
2. I have yet to understand how Quantum runs on XCP with nova compute. Have the Quantum agent run in the same context as nova compute and send the "networking" commands in a similar way that they are done by the nova vif driver for Xen.
3. Continue the enforcement (which has yet to be implemented)
I am in favor of item #2. This would require some development, but I think that it is doable and gives the most fleixibility to all.
2. RPC code:
i. There is a raging debate in OpenStack if this code should be part of openstack-common (I am certainly in favor of it as it will help us achive our goals and they have done some great work)
ii. This is currently pending a review (pending the above)
iii. This makes use of the cfg>CONF global structure (I am in the process of addressiing this in Quantum -
https://blueprints.launchpad.net/quantum/+spec/use-common-cfg (NOTE that we also need to validate the 2.4 here :)
Thanks
Aluta Continua
Gary
We are using XCP and have patched version of upstream agent worked with Python 2.4.
--
Regards, Roman Sokolkov
--
Mailing list:
https://launchpad.net/~netstack<
https://launchpad.net/%7Enetstack>
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe :
https://launchpad.net/~netstack<
https://launchpad.net/%7Enetstack>
More help :
https://help.launchpad.net/ListHelp --
Regards, Roman Sokolkov
--
Mailing list:
https://launchpad.net/~netstack<
https://launchpad.net/%7Enetstack>
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe :
https://launchpad.net/~netstack<
https://launchpad.net/%7Enetstack>
More help :
https://help.launchpad.net/ListHelp --
Mailing list:
https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe :
https://launchpad.net/~netstack More help :
https://help.launchpad.net/ListHelp