Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

Re: [Netstack] About python versions that we are planning to support

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


chrisw at sous-sol

May 24, 2012, 2:50 PM

Post #1 of 3 (167 views)
Permalink
Re: [Netstack] About python versions that we are planning to support

* Dan Wendlandt (dan [at] nicira) 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 [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


dan at nicira

May 24, 2012, 3:08 PM

Post #2 of 3 (166 views)
Permalink
Re: [Netstack] About python versions that we are planning to support [In reply to]

On Thu, May 24, 2012 at 2:50 PM, Chris Wright <chrisw [at] sous-sol> wrote:

> * Dan Wendlandt (dan [at] nicira) 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~


chrisw at sous-sol

May 24, 2012, 3:18 PM

Post #3 of 3 (164 views)
Permalink
Re: [Netstack] About python versions that we are planning to support [In reply to]

* Dan Wendlandt (dan [at] nicira) wrote:
> On Thu, May 24, 2012 at 2:50 PM, Chris Wright <chrisw [at] sous-sol> wrote:
>
> > * Dan Wendlandt (dan [at] nicira) 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 [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.