Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Pavlo Shchelokovskyy]

Hi all,

thank you all for your replies.

AFAIU the consensus is leaning towards option 1, so I've proposed a patch
to governance that adds networking-generic-switch under ironic:

https://review.openstack.org/#/c/521894/

(not actually sure how that works / being decided on from TC side, but will
see :) )

Cheers,

On Mon, Nov 20, 2017 at 6:14 PM, Ruby Loo <opensr...@gmail.com> wrote:

>
>
> On Wed, Nov 15, 2017 at 4:41 AM, Shivanand Tendulker <stendul...@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.villalo...@intel.com> wrote:
>>
>>> Thanks for sending this out.
>>>
>>>
>>>
>>> I would vote for Option 1.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>
>>>
>>> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
>>> *Sent:* Tuesday, November 14, 2017 8:16 AM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@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
>
> __
> 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
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
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

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Ruby Loo]

On Wed, Nov 15, 2017 at 4:41 AM, Shivanand Tendulker <stendul...@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.villalo...@intel.com> wrote:
>
>> Thanks for sending this out.
>>
>>
>>
>> I would vote for Option 1.
>>
>>
>>
>> Thanks,
>>
>> John
>>
>>
>>
>> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
>> *Sent:* Tuesday, November 14, 2017 8:16 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@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
__
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

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Shivanand Tendulker]

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.villalo...@intel.com> wrote:

> Thanks for sending this out.
>
>
>
> I would vote for Option 1.
>
>
>
> Thanks,
>
> John
>
>
>
> *From:* Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
> *Sent:* Tuesday, November 14, 2017 8:16 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@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
>
> __
> 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

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Villalovos, John L]

Thanks for sending this out.

I would vote for Option 1.

Thanks,
John

From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
Sent: Tuesday, November 14, 2017 8:16 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@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<http://www.mirantis.com>
__
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

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Dmitry Tantsur]

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 


__
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

Re: [openstack-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Julia Kreger]

On Tue, Nov 14, 2017 at 9:16 AM, Pavlo Shchelokovskyy
 wrote:
> 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.

Personally, I'm happy with 1 or 2. I personally think we might as well
lean towards 1 from a standpoint that we've had operators bring up
using n-g-s, and while we as a community predicate that it is not
intended for production use, and they are aware of that, they need
something that works for their baremetal deployment scenario. Given
the common usage, it just seems logical to me that we go for option 1.
Especially since we already have a fairly good practice in Ironic of
not approving things in sub-project that we do not understand.

-Julia

__
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-dev] [ironic] inclusion of openstack/networking-generic-switch project under OpenStack baremetal program

[Pavlo Shchelokovskyy]

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