Open Stack

On Fri, Jan 31, 2014 at 12:27 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 01/30/2014 08:10 AM, Christopher Yeoh wrote:
> > On Thu, Jan 30, 2014 at 2:08 PM, Michael Still <mikal at stillhq.com
> > <mailto:mikal at stillhq.com>> wrote:
> >
> >     On Thu, Jan 30, 2014 at 2:29 PM, Christopher Yeoh <cbkyeoh at gmail.com
> >     <mailto:cbkyeoh at gmail.com>> wrote:
> >
> >     > So if nova-network doesn't go away this has implications for the
> >     V3 API as
> >     > it currently doesn't support
> >     > nova-network. I'm not sure that we have time to add support for it
> in
> >     > icehouse now, but if nova-network is
> >     > not going to go away then we need to add it to the V3 API or we
> >     will be
> >     > unable to ever deprecate the
> >     > V2 API.
> >
> >     Is the problem here getting the code written, or getting it through
> >     reviews? i.e. How can I re-prioritise work to help you here?
> >
> >
> > So I think its a combination of both. There's probably around 10
> > extensions from V2 that would need looking at to port from V2. There's
> > some cases where the API supported both nova network and neutron,
> > proxying in the latter case and others where only nova network was
> > supported. So we'll need to make a decision pretty quickly around
> > whether we present a unified networking interface (eg proxy for neutron)
> > or have some interfaces which you only use when you use nova-network.
> > There's a bit of work either way. Also given how long we'll have V3 for
> > want to take the opportunity to cleanup the APIs we do port. And feature
> > proposal deadline is now less than 3 weeks away so combined with the
> > already existing work we have for i-3 it is going to be a little tight.
> >
> > The other issue is we have probably at least 50 or so V3 API related
> > changesets in the queue at the moment, plus obviously more coming over
> > the next few weeks. So I'm a bit a wary of how much extra review
> > attention we can realistically expect.
> >
> > The two problems together make me think that although its not
> > impossible, there's a reasonable level of risk that we wouldn't get it
> > all done AND merged in i-3. And I think we want to avoid the situation
> > where we have some of the things currently in the queue merged and some
> > of say the nova-network patches done, but not complete with either. More
> > people contributing patches and core review cycles will of course help
> > though so any help is welcome :-)
> >
> > This is all dependent on nova-network never going away. If the intent is
> > that it would eventually be deprecated - say in the same timeframe as
> > the V2 API then I don't think its worth the extra effort/risk putting it
> > in the V3 API in icehouse.
>
> I can't say in any sort of confidence that I think nova-network will go
> away in the foreseeable future.  Yes, this has an unfortunate big impact
> on our original plan for the v3 API.  :-(
>
> However, I'm also not sure about the status of v3 in Icehouse, anyway.
> One of the key things I want to see in before we freeze the API is the
> tasks work.  AFAIK, there hasn't been any design review on this, much
> less code review.  It seems incredibly unlikely that it will be done for
> Icehouse at this point.  Andrew, thoughts?
>
>
I don't think the lack the tasks api being merged should stop us from
releasing the V3 API (it perhaps means there is one less significant reason
for people to move from the V2 API). Releasing the v3 API doesn't stop us
from adding tasks at a later stage to the V3 API as it could be a simple
additional way to interact and in practice I'd imagine there will be
gradual increase in support of doing things in a tasks oriented way rather
than a big bang everything now uses tasks approach.

And the sooner we can release the V3 API, the sooner we can put the V2 API
into maintenance mode and avoid the overhead of having every new feature
having to be written for both.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140131/9f71a1a8/attachment.html>