Open Stack

Hi!

Thanks for raising this.

On 11/14/2017 05:16 PM, Pavlo Shchelokovskyy wrote:
> 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;

Some time ago I would go for option (2), now I guess I'm more with option (1). I 
think we have to recognize that certain things we don't target for production 
(yet or at all) end up in production. We cannot hide from this fact.

Furthermore, not all productions are the same. While networking-generic-switch 
certainly has (probably addressable) problems, it may be just enough for many 
cases, especially for people just starting with ironic. This is the key point 
that makes me prefer this option - we always need to work on an easier start.

> 
> 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;

This would work, but I think it hides the problem instead of fixing it - see above.

> 
> 3) merge the code from n-g-s into networking-baremetal project which is already 
> under ironic governance.

Well.. projects are cheap, let's have more of them :) Seriously though, I 
sometimes feel that networking-baremetal *already* does too many unrelated 
things. Let's not add to it.

> 
> 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.

TL;DR I vote for (1) with properly documenting the scope and limitations.

Dmitry

> 
> Eager to hear your comments and proposals.
> 
> Cheers,
> -- 
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com <http://www.mirantis.com>
> 
> 
> __________________________________________________________________________
> 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
>