settingsLogin | Registersettings

[openstack-dev] [ironic] When should a project be under Ironic's governance?

0 votes

Hello ironic!

At today's IRC meeting, the questions "what should and should not be a
project be under Ironic's governance" and "what does it mean to be under
Ironic's governance" were raised. Log here:

http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-17.00.log.html#l-176

See http://governance.openstack.org/reference/projects/ironic.html for a
list of projects currently under Ironic's governance.

Is it as simple as "any project that aides in openstack baremetal
deployment should be under Ironic's governance"? This is probably too
general (nova arguably fits here) but it might be a good starting point.

Another angle to look at might be that a project belongs under the
Ironic governance when both Ironic (the main services) and the candidate
subproject would benefit from being under the same governance. A
hypothetical example of this is when Ironic and the candidate project
need to release together.

Just some initial thoughts to get the ball rolling. What does everyone
else think?

Thanks,
Mike Turek


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 17, 2016 in openstack-dev by Michael_Turek (580 points)   1
retagged Jan 26, 2017 by admin

5 Responses

0 votes

On Oct 17, 2016, at 1:27 PM, Michael Turek mjturek@linux.vnet.ibm.com wrote:

Hello ironic!

At today's IRC meeting, the questions "what should and should not be a project be under Ironic's governance" and "what does it mean to be under Ironic's governance" were raised. Log here:

http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-17.00.log.html#l-176

See http://governance.openstack.org/reference/projects/ironic.html for a list of projects currently under Ironic's governance.

Is it as simple as "any project that aides in openstack baremetal deployment should be under Ironic's governance"? This is probably too general (nova arguably fits here) but it might be a good starting point.

Another angle to look at might be that a project belongs under the Ironic governance when both Ironic (the main services) and the candidate subproject would benefit from being under the same governance. A hypothetical example of this is when Ironic and the candidate project need to release together.

Just some initial thoughts to get the ball rolling. What does everyone else think?

I think there were a lot of people in the meeting who were confused by what being under governance means. As I understand it, in the strictest sense, it means:
- Project contributors can vote for TC/PTL
- Project has access to cross-project resources
- Access to summit/PTG time (at PTL’s discretion)

However, I get the impression some folks attach additional connotations to this; such as the Ironic core team gaining an implied responsibility to the code or it being seen as a “seal of approval” from Ironic. This means that the primary question at hand to be answered is what does it matter, specifically /in the Baremetal project/ to be included in our governance. Is it simply the benefits provided at a high level by OpenStack, or does it imply additional things. This is the question we have to answer to make a decision about what projects should be under Ironic’s governance and what exactly it means.

Unless there’s more to it than I understand right now, I’d prefer an open-arms approach to projects being in bare metal governance: as long as they’re willing to follow the 4 opens, and are working toward the goals of the Baremetal project, I’d rather have those projects and their contributors as part of our team than not.

Thanks,
Jay Faulkner

Thanks,
Mike Turek


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 18, 2016 by Jay_Faulkner (3,680 points)   2 5
0 votes

On Mon, Oct 17, 2016 at 7:02 PM, Jay Faulkner jay@jvf.cc wrote:
However, I get the impression some folks attach additional connotations to this; such as the Ironic core team gaining an implied responsibility to the code or it being seen as a “seal of approval” from Ironic. This means that the primary question at hand to be answered is what does it matter, specifically /in the Baremetal project/ to be included in our governance. Is it simply the benefits provided at a high level by OpenStack, or does it imply additional things. This is the question we have to answer to make a decision about what projects should be under Ironic’s governance and what exactly it means.

This sounds a lot like the Neutron Stadium, which has recently been
(mostly?) dismantled, partially because, as I understand, the PTL no
longer felt able to speak for and have sufficient visibility into the
projects within. There is not an implied responsibility for the PTL
to be 'in charge', it is explicit. There are also explicit
expectations regarding team membership overlap among the
'sub-projects' that fall under a big tent project.

Unless there’s more to it than I understand right now, I’d prefer an open-arms approach to projects being in bare metal governance: as long as they’re willing to follow the 4 opens, and are working toward the goals of the Baremetal project, I’d rather have those projects and their contributors as part of our team than not.

Please talk to the Neutron folk about this and their experiences over
the last couple of years. This is recent enough that it should be
very easy to recall the reasons for going in, as well as coming out of
the stadium.

dt

--

Dean Troyer
dtroyer@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 18, 2016 by Dean_Troyer (13,100 points)   1 3 4
0 votes

On Mon, Oct 17, 2016 at 4:27 PM, Michael Turek
mjturek@linux.vnet.ibm.com wrote:
Hello ironic!

At today's IRC meeting, the questions "what should and should not be a
project be under Ironic's governance" and "what does it mean to be under
Ironic's governance" were raised. Log here:

http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-17.00.log.html#l-176

See http://governance.openstack.org/reference/projects/ironic.html for a
list of projects currently under Ironic's governance.

Is it as simple as "any project that aides in openstack baremetal deployment
should be under Ironic's governance"? This is probably too general (nova
arguably fits here) but it might be a good starting point.

Another angle to look at might be that a project belongs under the Ironic
governance when both Ironic (the main services) and the candidate subproject
would benefit from being under the same governance. A hypothetical example
of this is when Ironic and the candidate project need to release together.

Just some initial thoughts to get the ball rolling. What does everyone else
think?

We discussed this during our contributor's meetup at the summit, and came to
consensus in the room, that in order for a repository to be under
ironic's governance:

  • it must roughly fall within the TC's rules for a new project:
    http://governance.openstack.org/reference/new-projects-requirements.html
  • it must not be intended for use with only a single vendor's hardware
    (e.g. a library
    to handle iLO is not okay, a library to handle IPMI is okay).
  • it must align with ironic's mission statement: "To produce an
    OpenStack service
    and associated libraries capable of managing and provisioning
    physical machines,
    and to do this in a security-aware and fault-tolerant manner."
  • lack of contributor diversity is a chicken-egg problem, and as such
    a repository
    where only a single company is contributing is okay.

I've proposed this as a docs patch: https://review.openstack.org/392685

We decided we should get consensus from all cores on that patch - meaning 80%
or more agree, and any that disagree will still agree to live by the
decision. So, cores,
please chime in on gerrit. :)

Once that patch lands, I'll submit a patch to openstack/governance to
shuffle projects
around where they do or don't fit.

// jim


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 2, 2016 by Jim_Rollenhagen (12,800 points)   2 3 3
0 votes

Second try

-----Original Message-----
From: Kanevsky, Arkady
Sent: Thursday, November 10, 2016 10:08 AM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: RE: [openstack-dev] [ironic] When should a project be under Ironic's governance?

Fully agree.
How do we propose to handle dependency of Ironic version on specific version of a driver?
Clearly distros can do it but we will not have a version for user of upstream to use without building it themselves.
I am only referring to ironic drivers that do pass CI voting that user expect availability of.
Thanks,
Arkady

-----Original Message-----
From: Jim Rollenhagen [mailto:jim@jimrollenhagen.com]
Sent: Wednesday, November 02, 2016 9:37 AM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [ironic] When should a project be under Ironic's governance?

On Mon, Oct 17, 2016 at 4:27 PM, Michael Turek mjturek@linux.vnet.ibm.com wrote:
Hello ironic!

At today's IRC meeting, the questions "what should and should not be a
project be under Ironic's governance" and "what does it mean to be
under Ironic's governance" were raised. Log here:

http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-
17.00.log.html#l-176

See http://governance.openstack.org/reference/projects/ironic.html for
a list of projects currently under Ironic's governance.

Is it as simple as "any project that aides in openstack baremetal
deployment should be under Ironic's governance"? This is probably too
general (nova arguably fits here) but it might be a good starting point.

Another angle to look at might be that a project belongs under the
Ironic governance when both Ironic (the main services) and the
candidate subproject would benefit from being under the same
governance. A hypothetical example of this is when Ironic and the candidate project need to release together.

Just some initial thoughts to get the ball rolling. What does everyone
else think?

We discussed this during our contributor's meetup at the summit, and came to consensus in the room, that in order for a repository to be under ironic's governance:

  • it must roughly fall within the TC's rules for a new project:
    http://governance.openstack.org/reference/new-projects-requirements.html
  • it must not be intended for use with only a single vendor's hardware (e.g. a library
    to handle iLO is not okay, a library to handle IPMI is okay).
  • it must align with ironic's mission statement: "To produce an OpenStack service
    and associated libraries capable of managing and provisioning physical machines,
    and to do this in a security-aware and fault-tolerant manner."
  • lack of contributor diversity is a chicken-egg problem, and as such a repository
    where only a single company is contributing is okay.

I've proposed this as a docs patch: https://review.openstack.org/392685

We decided we should get consensus from all cores on that patch - meaning 80% or more agree, and any that disagree will still agree to live by the decision. So, cores, please chime in on gerrit. :)

Once that patch lands, I'll submit a patch to openstack/governance to shuffle projects around where they do or don't fit.

// jim


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 10, 2016 by Arkady.Kanevsky_at_d (1,480 points)   1
0 votes

On Thu, Nov 10, 2016 at 11:21 AM, Arkady.Kanevsky@dell.com wrote:
Second try

-----Original Message-----
From: Kanevsky, Arkady
Sent: Thursday, November 10, 2016 10:08 AM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: RE: [openstack-dev] [ironic] When should a project be under Ironic's governance?

Fully agree.
How do we propose to handle dependency of Ironic version on specific version of a driver?
Clearly distros can do it but we will not have a version for user of upstream to use without building it themselves.
I am only referring to ironic drivers that do pass CI voting that user expect availability of.

I'm not quite sure what you mean here.

For optional libraries (like proliantutils), we use a
driver-requirements.txt file
that is versioned the same as ironic, which both packagers and users can use
to determine what version of a library is required. Libraries may also carry
stable branches like ironic, whether they are inside or outside of
ironic governance.

For in-tree drivers, well, those are versioned the same as ironic.

For out-of-tree drivers, it's the same as optional libraries, except
that we don't
have a requirements.txt-style file. Folks maintaining out-of-tree
drivers will need
to document what version of their driver works with what version of ironic. Of
course, these drivers can also carry stable branches.

Does that help?

// jim

Thanks,
Arkady

-----Original Message-----
From: Jim Rollenhagen [mailto:jim@jimrollenhagen.com]
Sent: Wednesday, November 02, 2016 9:37 AM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [ironic] When should a project be under Ironic's governance?

On Mon, Oct 17, 2016 at 4:27 PM, Michael Turek mjturek@linux.vnet.ibm.com wrote:

Hello ironic!

At today's IRC meeting, the questions "what should and should not be a
project be under Ironic's governance" and "what does it mean to be
under Ironic's governance" were raised. Log here:

http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-10-17-
17.00.log.html#l-176

See http://governance.openstack.org/reference/projects/ironic.html for
a list of projects currently under Ironic's governance.

Is it as simple as "any project that aides in openstack baremetal
deployment should be under Ironic's governance"? This is probably too
general (nova arguably fits here) but it might be a good starting point.

Another angle to look at might be that a project belongs under the
Ironic governance when both Ironic (the main services) and the
candidate subproject would benefit from being under the same
governance. A hypothetical example of this is when Ironic and the candidate project need to release together.

Just some initial thoughts to get the ball rolling. What does everyone
else think?

We discussed this during our contributor's meetup at the summit, and came to consensus in the room, that in order for a repository to be under ironic's governance:

  • it must roughly fall within the TC's rules for a new project:
    http://governance.openstack.org/reference/new-projects-requirements.html
  • it must not be intended for use with only a single vendor's hardware (e.g. a library
    to handle iLO is not okay, a library to handle IPMI is okay).
  • it must align with ironic's mission statement: "To produce an OpenStack service
    and associated libraries capable of managing and provisioning physical machines,
    and to do this in a security-aware and fault-tolerant manner."
  • lack of contributor diversity is a chicken-egg problem, and as such a repository
    where only a single company is contributing is okay.

I've proposed this as a docs patch: https://review.openstack.org/392685

We decided we should get consensus from all cores on that patch - meaning 80% or more agree, and any that disagree will still agree to live by the decision. So, cores, please chime in on gerrit. :)

Once that patch lands, I'll submit a patch to openstack/governance to shuffle projects around where they do or don't fit.

// jim


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2016 by Jim_Rollenhagen (12,800 points)   2 3 3
...