openstack team mailing list archive

[Andy Smith <andyster@xxxxxxxxx>]

On Thu, Feb 24, 2011 at 6:25 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:

> On Thu, Feb 24, 2011 at 9:05 PM, Andy Smith <andyster@xxxxxxxxx> wrote:
> > On Thu, Feb 24, 2011 at 5:49 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
> >> On Thu, Feb 24, 2011 at 2:44 PM, Andy Smith <andyster@xxxxxxxxx> wrote:
> >> > Well, my previous reply somehow isn't going through to the list...
> so...
> >> > here it is again:
> >> > I've got some objections so far:
> >> > 1. relying on python-cloudservers is a good metric by which to judge
> >> > your
> >> > compatibility with the rackspace cloud, once jacob has accepted the
> >> > changes
> >> > to support changing the auth endpoint. My opinion is that this project
> >> > should be a fork of python-cloudservers with the same name and whose
> >> > intention is not to add additional features at this time.
> >>
> >> Why? As much as I like JKM, I don't think relying on someone who has
> >> no interaction with the OpenStack community to accept patches from the
> >> OpenStack community is a good idea.
> >
> > That's not at all what I said. You have two tasks here, the one described
> in
> > (1) is make minimal changes to python-cloudservers such that you can
> point
> > it at a nova deployment and test compat with existing cloudservers
> > implementations. The second task is described in (1a) make extensions to
> > that to support your immediate needs that are beyond the cloudservers
> > compatibility.
>
> OK, we're clearly not communicating properly here. This is the
> original quote from Sandy that I was trying to address why your (1)
> above isn't working:
>
> "The reality is we need a place where we can push changes quickly and
> not be hogtied waiting for merge. Without this, we end up pointing the
> community to our local branch anyway. If jacobian wants to regain
> control of this branch, we need assurances of timely responses."
>
> Sandy *has* tried to make minimal changes to python-cloudservers and
> have those changes merged. No response from JKM yet, according to
> Sandy.
>
> >>
> >> > 1a. To support your additional features for the very short term you
> >> > should
> >> > be writing extensions to python-cloudservers (possibly with your minor
> >> > compat modifications) via actual python extension mechanisms (import,
> >> > inherit and extend).
> >>
> >> Again, why? With python-novatools we have complete control over the
> >> code and don't need to push it back to python-cloudservers, which is
> >> not OpenStack-based, it's specific to Rackspace Cloud Servers.
> >
> > One of your needs is to provide something that is compatible with
> > cloudservers so that you can migrate without breaking existing customers.
>
> *If* Sandy's minimal changes were merged, then python-cloudservers
> would be that "something" that is compatible with cloudservers" (and
> nova) that you talk about above. But JKM has not been responsive.
> Again, Sandy needs to do something... not wait for JKM to get back in
> touch.


My original suggestion is that renaming it to novatools is not required for
that, renaming makes it that much less likely that jkm will be interested in
merging the changes, and pulling the code directly into nova as the other
novatools thread suggests makes that process even harder.

My suggestion is to simply fork the project on github and make the minimal
changes there (and clone to launchpad and make PPAs if that helps for
testing in the meantime).

Also per JKM responsiveness, I poked him:

02:16 < jacobkm> termie: going back a bit, but patches welcome. I'm working
on a light refactoring to support multiple
                 providers (so it'll work with openstack, etc.) and a few
other cleanups, but send me stuff and I'll
                 integrate it.

So we have perhaps a decent chance of getting things rolling there?

I think it is worth pursuing.

--andy





> -jay
>