Open Stack

On Thu, Nov 10, 2016 at 11:21 AM,  <Arkady.Kanevsky at 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 at 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 at jimrollenhagen.com]
> Sent: Wednesday, November 02, 2016 9:37 AM
> To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at 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 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev