Open Stack

On Wed, Nov 15, 2017 at 4:41 AM, Shivanand Tendulker <stendulker at gmail.com>
wrote:

> Thank you. I too vote for 'Option 1'.
>
> Thanks and Regards
> Shiv
>
>
>
> On Wed, Nov 15, 2017 at 1:03 AM, Villalovos, John L <
> john.l.villalovos at intel.com> wrote:
>
>> Thanks for sending this out.
>>
>>
>>
>> I would vote for Option 1.
>>
>>
>>
>> Thanks,
>>
>> John
>>
>>
>>
>> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovskyy at mirantis.com]
>> *Sent:* Tuesday, November 14, 2017 8:16 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev at lists.openstack.org>
>> *Subject:* [openstack-dev] [ironic] inclusion of
>> openstack/networking-generic-switch project under OpenStack baremetal
>> program
>>
>>
>>
>> Hi all,
>>
>>
>>
>> as this topic it was recently brought up in ironic IRC meeting, I'd like
>> to start a discussion on the subject.
>>
>>
>>
>> A quick recap - networking-generic-switch project (n-g-s) was born out of
>> necessity to do two things:
>>
>>
>>
>> -  test the "network isolation for baremetal nodes" (a.k.a.
>> multi-tenancy) feature of ironic on upstream gates in virtualized
>> environment and
>>
>> - do the same on cheap/simple/dumb hardware switches that are not
>> supported by other various openstack/networking-* projects.
>>
>>
>>
>> Back when it was created AFAIR neutron governance (neutron stadium) was
>> under some changes, so in the end n-g-s ended up not belonging to any
>> official program.
>>
>>
>>
>> Over time n-g-s grew to be an essential part of ironic gate testing
>> (similar to virtualbmc). What's more, we have reports that it is already
>> being used in production.
>>
>>
>>
>> Currently the core reviewers team of n-g-s consists of 4 people (2 of
>> those are currently core reviewers in ironic too), all of them are working
>> for the same company (Mirantis). This poses some risk as companies and
>> people come and go, plus since some voting ironic gate jobs depend on n-g-s
>> stability, a more diverse group of core reviewers from baremetal program
>> might be beneficial to be able to land patches in case of severe gate
>> troubles.
>>
>>
>>
>> Currently I know of 3 proposed ways to change the current situation:
>>
>>
>>
>> 1) include n-g-s under ironic (OpenStack Baremetal program) governance,
>> effectively including ironic-core team to the core team of  n-g-s similar
>> to how ironic-inspector currently governed (keeping an extended sub-core
>> team). Reasoning for addition is the same as with virtualbmc/sushy
>> projects, with the debatable difference that the actual scope of n-g-s is
>> quite bigger and apparently includes production use-cases;
>>
>>
>>
>> 2) keep things as they are now, just add ironic-stable-maint team to the
>> n-g-s core reviewers to decrease low diversity risks;
>>
>>
>>
>> 3) merge the code from n-g-s into networking-baremetal project which is
>> already under ironic governance.
>>
>>
>>
>> As a core in n-g-s myself I'm happy with either 1) or 2), but not really
>> fond of 3) as it kind of stretches the networking-baremetal scope too much
>> IMHO.
>>
>>
>>
>> Eager to hear your comments and proposals.
>>
>>
>>
>> Cheers,
>>
>> --
>>
>> Dr. Pavlo Shchelokovskyy
>>
>> Senior Software Engineer
>>
>> Mirantis Inc
>>
>> www.mirantis.com
>>
>>
 I'm good with 1 or 2. Since we have two 1's and no nays (so far), let's go
with 1 and move on :)

Thanks for bringing this up!

--ruby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171120/b228c2b2/attachment.html>