Open Stack

hi,

On Sat, Sep 24, 2016 at 9:06 AM, Armando M. <armamig at gmail.com> wrote:
>
>
> On 22 September 2016 at 22:36, Takashi Yamamoto <yamamoto at midokura.com>
> wrote:
>>
>> hi,
>>
>> On Fri, Sep 23, 2016 at 4:20 AM, Armando M. <armamig at gmail.com> wrote:
>> >
>> >
>> > On 22 September 2016 at 00:46, reedip banerjee <reedip14 at gmail.com>
>> > wrote:
>> >>
>> >> Dear Neutron Core members,
>> >>
>> >> I have a query regarding the procedure for inclusion in the Neutron
>> >> Stadium.
>> >> I wanted to know if a project can apply for Big Tent and Neutron
>> >> Stadium
>> >> together ( means can a project be accepted in the Neutron Stadium and
>> >> as a
>> >> result into the Big Tent )
>> >>
>> >> I was checking out the checklist in  [1], and IMO , I think that we
>> >> need
>> >> to conform to the checklist to be added to the Neutron Stadium ( along
>> >> with
>> >> the other requirements  like keeping in sync with the core neutron
>> >> concepts)
>> >>
>> >> But IIUC, certain items in the checklist would be completed if a
>> >> project
>> >> is already included in the Big Tent.
>> >
>> >
>> > I would not worry about those, as these are rather trivial to implement
>> > in
>> > conjunction with Stadium inclusion. I'd worry about the fork that the
>> > project relies on, which is a big show stopper for Stadium inclusion.
>> >
>> > [1]
>> > https://github.com/openstack/tap-as-a-service/blob/master/setup.cfg#L50
>>
>> just a clarification; this is not a fork of ovs-agent. it's a separate
>> agent.
>
>
> It may not strictly be a fork, but I am not grasping the technical reason as
> to why one needs yet another agent on the node. Besides, this might end up
> interfering with the OVS agent as it is handling the same resources [1],
> without any level of coordination.

it was done that way just because there was no good ways at that point i guess.
(just a wild guess. i'm not a person who wrote it.)
making it an l2 agent extension is on our todo list.

>
> [1]
> https://github.com/openstack/tap-as-a-service/blob/master/neutron_taas/services/taas/drivers/linux/ovs_taas.py#L43:L44
>
>>
>> >
>> >>
>> >>
>> >> So my doubt is ,should a project apply for the Big Tent first, and
>> >> after
>> >> inclusion, apply for Neutron Stadium ? Or can a project be integrated
>> >> to
>> >> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical
>> >> about
>> >> this though)?
>> >
>> >
>> > You are confusing the two things. A project either belongs to list [1]
>> > or
>> > list [2], and you can't be in both at the same time. To be part of
>> > either
>> > list a project must comply with a set of criteria. As for the latter, a
>> > couple of steps may sound like a catch 22: for instance you can't make
>> > docs
>> > available on docs.o.o unless you are in [2] and you can't be in [2]
>> > unless...and here's the trick, unless you are a point where you can
>> > successfully demonstrate that the project has substantial documentation
>> > (of
>> > any sort, API included). The process of 'demonstrating'/application for
>> > inclusion in list [2] follows the RFE submission process that we have
>> > adopted for a while, and that means submitting a spec. Since the request
>> > does not require a conventional design process, I was going to prepare
>> > an
>> > ad-hoc template and make it available soon. So watch the neutron-specs
>> > repo
>> > for updates.
>> >
>> > In the meantime, I'd urge you to go over the checklist and make sure you
>> > can
>> > address the hard parts.
>> >
>> > If you ask me, if you go with [1], it makes no sense to go and apply to
>> > be
>> > in [2].
>> >
>> > HTH
>> > Armando
>> >
>> > [1] http://governance.openstack.org/reference/projects/
>> > [2] http://governance.openstack.org/reference/projects/neutron.html
>> >
>> >>
>> >>
>> >>
>> >> [1]
>> >>
>> >> http://docs.openstack.org/developer/neutron/stadium/governance.html#checklist
>> >> --
>> >> Thanks and Regards,
>> >> Reedip Banerjee
>> >> IRC: reedip
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> __________________________________________________________________________
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>