Re: [Openstack] [Netstack] About python versions that we are planning to support
* Dan Wendlandt (d...@nicira.com) wrote: I'm concerned about a need to support python 2.4 as well, especially if it would have a ripple effect into openstack-common, which otherwise does not have that requirement. I am too. Is this still open, or did we reach some consensus? The discussion on the list seems to have died out. thanks, -chris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] About python versions that we are planning to support
On Thu, May 24, 2012 at 2:50 PM, Chris Wright chr...@sous-sol.org wrote: * Dan Wendlandt (d...@nicira.com) wrote: I'm concerned about a need to support python 2.4 as well, especially if it would have a ripple effect into openstack-common, which otherwise does not have that requirement. I am too. Is this still open, or did we reach some consensus? The discussion on the list seems to have died out. Hi Chris, We actually talked about this at the quantum team meeting last week. Current status seems to be: - we're OK enforcing 2.4 coding standards for agent code in the quantum repo, so long as it does not become onerous (currently this is mainly a matter of simple things like not using as or with) - the bigger question is around code from other repos that may be pulled in, particularly openstack-common. Its unclear if those projects can be kept 2.4 clean, this may well prove substantially more onerous than just keeping quantum agent code clean (perhaps those requiring 2.4 can help with that). - another option is to avoid running the agents on dom0 all together and instead use the service-vm that is already used in xenserver deployments to run nova-compute. There are a couple options here, including a suggestion from rkukura to potentially utilize the rootwrap functionality so that the agent could run in the service-vm, but dispatch calls to dom0. mnewby has been leading the effort to maintain XenServer support and he has been out this week (and will be out next as well, I think), so I think exploring those options may have to wait a week unless someone else wants to drive. Dan thanks, -chris -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] About python versions that we are planning to support
* Dan Wendlandt (d...@nicira.com) wrote: On Thu, May 24, 2012 at 2:50 PM, Chris Wright chr...@sous-sol.org wrote: * Dan Wendlandt (d...@nicira.com) wrote: I'm concerned about a need to support python 2.4 as well, especially if it would have a ripple effect into openstack-common, which otherwise does not have that requirement. I am too. Is this still open, or did we reach some consensus? The discussion on the list seems to have died out. We actually talked about this at the quantum team meeting last week. Cool, thanks for the update. Current status seems to be: - we're OK enforcing 2.4 coding standards for agent code in the quantum repo, so long as it does not become onerous (currently this is mainly a matter of simple things like not using as or with) - the bigger question is around code from other repos that may be pulled in, particularly openstack-common. Its unclear if those projects can be kept 2.4 clean, this may well prove substantially more onerous than just keeping quantum agent code clean (perhaps those requiring 2.4 can help with that). Right, this is why I brought it up. The common.cfg blueprint, for example. - another option is to avoid running the agents on dom0 all together and instead use the service-vm that is already used in xenserver deployments to run nova-compute. There are a couple options here, including a suggestion from rkukura to potentially utilize the rootwrap functionality so that the agent could run in the service-vm, but dispatch calls to dom0. mnewby has been leading the effort to maintain XenServer support and he has been out this week (and will be out next as well, I think), so I think exploring those options may have to wait a week unless someone else wants to drive. I see. I'm inclined to see it as distro support (read: patch and maintain customizations downstream). But if Maru is up for the work and it's not blocking other efforts... thanks, -chris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] About python versions that we are planning to support
[I'm moving this thread to the openstack list because it potentially impacts openstack-common.] On 05/07/2012 11:53 PM, Maru Newby wrote: Hi, Python 2.4 compatibility is required, but only for agent code. Agent code needs to be deployable on Xen dom0, which uses CentoOS 5.5 and only supports 2.4 out of the box. Maru, I'm very concerned about the potential of this XenServer/XCP requirement to interfere with making the various Quantum agents first-class OpenStack services by utilizing current and future openstack-common facilities for configuration, logging, DB, RPC, etc.. Are there any other possible ways forward here? How is the nova compute service currently handled for XenServer? Could a fully supported version of python be parallel-installed on dom0? Could the actual quantum agent run somewhere else and remotely execute commands on dom0? Or does the python 2.4 compatibility requirement need to be applied to openstack-common? Thanks, -Bob Both quantum and nova have agent code that needs to be deployed to dom0, but up until now both projects have relied on savvy reviewers and bug reports to ensure compatibility. I'm working on it, though. I'll be adding a tox build to quantum that will run agent tests - and agent tests only - under 2.4, and then openstack-ci can add a jenkins job to run that build on CentOS and gate merges. The relevant bug: https://bugs.launchpad.net/quantum/+bug/995278 Thanks, Maru On 2012-05-07, at 6:54 PM, Yong Sheng Gong wrote: Hi, I see some ones are trying to support python2.4. But our tox.ini under quantum is only supporting test py26 and py27. So my question is if we are trying to support py24. In addition I remember that we will support py30. As far as I know, py2.4 does not support many new syntaxes introduced by py2.5+. Other projects such as nova, horizon are also adopting some of these new syntaxes. Moreover some third party components such as Django 1.4 required by horizon are only tested under py2.6 and py2.7. So if py2.4 is out of our scope, we should stop that trying. If we need py2.4, we have to make all of us know it and keep our code 2.4 compatible. Thanks Yong Sheng Gong -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net mailto:netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] About python versions that we are planning to support
I'm concerned about a need to support python 2.4 as well, especially if it would have a ripple effect into openstack-common, which otherwise does not have that requirement. With XenServer, nova-compute actually runs in a service VM (which is running a modern version of python). I believe Salvatore or others may have done some work around forcing network traffic through this service VM to allow iptables rules from nova-compute / nova-network to be enforced, but I'm not familiar enough with that work to say for sure. Can anyone shed light on this? Another option would be to just create a simple Quantum plugin specific to XenServer that doesn't require an agent. This plugin could use XAPI to create networks, but as a result might only support a base feature set (e.g., L2 connectivity using VLANs). Dan On Wed, May 9, 2012 at 9:07 AM, Robert Kukura rkuk...@redhat.com wrote: [I'm moving this thread to the openstack list because it potentially impacts openstack-common.] On 05/07/2012 11:53 PM, Maru Newby wrote: Hi, Python 2.4 compatibility is required, but only for agent code. Agent code needs to be deployable on Xen dom0, which uses CentoOS 5.5 and only supports 2.4 out of the box. Maru, I'm very concerned about the potential of this XenServer/XCP requirement to interfere with making the various Quantum agents first-class OpenStack services by utilizing current and future openstack-common facilities for configuration, logging, DB, RPC, etc.. Are there any other possible ways forward here? How is the nova compute service currently handled for XenServer? Could a fully supported version of python be parallel-installed on dom0? Could the actual quantum agent run somewhere else and remotely execute commands on dom0? Or does the python 2.4 compatibility requirement need to be applied to openstack-common? Thanks, -Bob Both quantum and nova have agent code that needs to be deployed to dom0, but up until now both projects have relied on savvy reviewers and bug reports to ensure compatibility. I'm working on it, though. I'll be adding a tox build to quantum that will run agent tests - and agent tests only - under 2.4, and then openstack-ci can add a jenkins job to run that build on CentOS and gate merges. The relevant bug: https://bugs.launchpad.net/quantum/+bug/995278 Thanks, Maru On 2012-05-07, at 6:54 PM, Yong Sheng Gong wrote: Hi, I see some ones are trying to support python2.4. But our tox.ini under quantum is only supporting test py26 and py27. So my question is if we are trying to support py24. In addition I remember that we will support py30. As far as I know, py2.4 does not support many new syntaxes introduced by py2.5+. Other projects such as nova, horizon are also adopting some of these new syntaxes. Moreover some third party components such as Django 1.4 required by horizon are only tested under py2.6 and py2.7. So if py2.4 is out of our scope, we should stop that trying. If we need py2.4, we have to make all of us know it and keep our code 2.4 compatible. Thanks Yong Sheng Gong -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net mailto:netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] About python versions that we are planning to support
On Wed, May 09, 2012, Robert Kukura rkuk...@redhat.com wrote: I'm very concerned about the potential of this XenServer/XCP requirement to interfere with making the various Quantum agents first-class OpenStack services by utilizing current and future openstack-common facilities for configuration, logging, DB, RPC, etc.. Are there any other possible ways forward here? How is the nova compute service currently handled for XenServer? Could a fully supported version of python be parallel-installed on dom0? Could the actual quantum agent run somewhere else and remotely execute commands on dom0? Or does the python 2.4 compatibility requirement need to be applied to openstack-common? I'm confused what openstack-common has to do with the dom0 plugins? I don't know what these Quantum agents do, but it sounds like they are trying to do too much on the XS dom0. Why would you want to communicate with the DB or RPC from dom0? The nova plugins (which exist in plugins/xenserver/xenapi) are basically the minimal amount of code that is necessary to run on dom0. I'm not a fan of how XenServer userspace is lagging and is only Python 2.4, but Nova has been able to develop plugins with only a couple of workarounds necessary. I'm not sure I understand what Quantum is doing and why it appears to want to do so much on dom0. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
