Open Stack

As Ronak said, this thread is starting to move in a lot of different
directions, ranging from correctness of the blueprint approval process to
nova/neutron integration, which are rather off topic.

In particular it seems things are being skewed towards a discussion around
nova parity, whereas actually some people have just chimed in with their
honest opinion that with all the stuff still needed to finally be able to
make neutron "THE" openstack networking solution, the effort towards adding
a new tenant facing API appears to have a lesser priority.

I just want to reassure everybody that the majority of the core team and a
large part of the community have actually made this their first priority.
For what is worth, some of them have even delayed plugin/driver specific
development to this aim.

So I would invite to go back to the original subject of the discussion,
that is to say decide as a community what would the best way forward for
this effort.
I see so far the following options:
- merge the outstanding patches, assuming there are no further technical
concerns, and include GBP in Juno.
- consider GBP an 'experimental' V3 tenant API (this was mentioned
somewhere in this thread) and treat it accordingly
- delay to the next release
- move the development of the service plugin to stackforge as suggested to
this thread.

More options are obviously welcome!

Regards,
Salvatore


On 6 August 2014 19:40, Ivar Lazzaro <ivarlazzaro at gmail.com> wrote:

> Which kind of uncertainty are you referring to?
>
> Given that the blueprint was approved long ago, and the code has been
> ready and under review following those specs... I think GBP is probably the
> patch with the least effort to be merged right now.
>
> Ivar.
>
>
> On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>>
>> On Aug 6, 2014 10:21 AM, "Ronak Shah" <ronak.malav.shah at gmail.com> wrote:
>> >
>> > We have diverged our attention towards nova-network-> neutron parity on
>> this thread unnecessarily.
>> >
>> > Can we discuss and collectively decide on what is the way forward for
>> GBP in Juno release?
>> >
>> > Efforts have been made by the subteam starting from throwing PoC at
>> last summit to spec approval to code review.
>> >
>> > There are usefulness to this feature and I think everyone is on the
>> same page there.
>> >
>> > Let us not discourage the effort by bringing in existing neutron issue
>> in play.
>>
>> > Yes, we has a neutorn community needs to fix that with highest
>> priority.
>> > But this is orthogonal effort.
>>
>> The efforts may be orthogonal, but the review team and bandwidth of said
>> team is one and the same. Making nova-network the highest priority means
>> pushing other blueprints back as needed.  And since there is still so much
>> uncertainty around GPB this late in the cycle, IMHO it's a good candidate
>> for getting deferred.
>>
>> > If endpoint is not a likeable preferred name than lets propose more
>> meaningful alternative.
>> > Let us try to find a middle ground on how this feature can be made
>> generally available.
>> >
>> > Thanks,
>> > Ronak
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/646eb0e5/attachment.html>