hi, On Sat, Sep 24, 2016 at 9:06 AM, Armando M. <arma...@gmail.com> wrote: > > > On 22 September 2016 at 22:36, Takashi Yamamoto <yamam...@midokura.com> > wrote: >> >> hi, >> >> On Fri, Sep 23, 2016 at 4:20 AM, Armando M. <arma...@gmail.com> wrote: >> > >> > >> > On 22 September 2016 at 00:46, reedip banerjee <reedi...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev