Open Stack

I definitely get why developers working on the code base are in favor of
this, especially for reasons 3 and 4 below.  However, there are a couple
of reasons that it might make sense to keep it, and I'd really like to
hear from a different demographic, if at all possible.

First, I'd like to hear from anyone that has nova deployed, whether its
public or private.  Are you using the 1.0 API?  I know its not complete,
but you can definitely use it to do all the basics.  I can say Rackspace
is not, but we may not be the typical case.

The second thing to consider is something that Monty pointed out at the
summit - the jenkins job that has thus far been the most successful at
detecting functional issues in trunk is the VPC job, which exercises the
code using ec2 and OS API 1.0.  I think the fix here is pretty straight
forward - update ruby bindings to support 1.1, and move tests to using
1.1.  Note this won't be perfect as 1.1 still has a couple of changes to
make - but we can keep that up to date.  I think my team can handle that,
I'd just rather this not go in until that is handled (hopefully this
week).  I also get that we have a large suite of tests where all these
things should be combined and run, and I fully support that. However, as
we all know there is an element of trust that must be built up in any
functional test suite and I don't think we are there on
openstack-integration-tests just yet, although I look forward to helping
to make sure that happens.


I definitely get the pain that it is causing in development, just want to
make sure we aren't driving away users of nova with this.

Gabe

On 10/11/11 7:49 PM, "Chris Behrens" <chris.behrens at RACKSPACE.COM> wrote:

>
>+3
>
>
>On Oct 11, 2011, at 1:59 PM, Brian Waldon <brian.waldon at rackspace.com>
>wrote:
>
>> I would like to propose we remove our implementation of OSAPI v1.0 from
>>Nova for the following reasons:
>> 
>> 1) Our implementation is incomplete, and there are no (visible) plans
>>to complete it. Shared IP Groups and Backup Schedules have been
>>unimplemented since I started on the project.
>> 
>> 2) The v1.1 spec is not backwards-compatible with v1.0. I would like
>>minor versions to be backwards compatible as we move forward, so I see
>>v1.0 as something we need to just get rid of.
>> 
>> 3) As we are trying to complete the v1.1 implementation, we are running
>>into problems created by having to support v1.0 (specifically image and
>>server uuids).
>> 
>> 4) Our implementation of v1.0 and v1.1 within the same modules have
>>caused us to compromise code quality. Working on the controllers
>>(specifically servers) is a royal pain.
>> 
>> I've already done the work of removing v1.0 from the code, and here's
>>the review of my branch: https://review.openstack.org/840. I think it
>>makes a lot of sense for the community to focus on making our v1.1
>>implementation solid, rather than constantly worrying about how we are
>>affecting v1.0. If this is something we don't want to do, I would love
>>to hear why :)
>> 
>> Waldon
>> 
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>This email may include confidential information. If you received it in
>error, please delete it.
>
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, please delete it.