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" <[email protected]> wrote: > >+3 > > >On Oct 11, 2011, at 1:59 PM, Brian Waldon <[email protected]> >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 : [email protected] >> 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 : [email protected] >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 : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
