Open Stack

On Mon, Apr 08, 2019 at 11:01:44PM +0000, William M Edmonds - edmondsw at us.ibm.com wrote:
> 
> Rico Lin wrote:
> > Dear PowerVMStackers and Winstackers members
> > 
> > (This idea is from Thierry, so I'm just helping to trigger discussion here.)
> > 
> > We now have most of Working Groups migrate to SIGs, so it's 
> > governance under both TCs and UCs. And to further look through, there 
> > are some projects are potential SIG meterial.
> > PowerVMStackers and Winstackers are two identical targets. They all 
> > required cross-project works to achieve their mission and kind of 
> > *special interest* (One for PowerVM, and one for Windows support across 
> > OpenStack). 
> 
> That's great, but these aren't working groups, and never were, and
> don't really function like working groups or SIGs, so I don't think
> that really applies here.

I think we're mixing a couple of ideas here.

PowerVMStackers is very much a Special interest group, it has a common
thread that crosses project boundaries.

This has *nothing* to do with code migration or core lists etc.

> > There are two questions I would hope team members from both teams can 
> > help to answer.
> >
> > 1. Is the mission for your project completed?
> 
> No
> 
> > 2. Is the team still active?
> 
> Yes
> 
> > 3. Any concerns or objections on moving from project to SIG?
> 
> Lots...
> 
> I can see why, at a quick glance, one might think that PowerVMStackers is like a special interest group. The name would certainly imply that. But that's out of historical necessity rather than what's proper. It's really not much like a SIG in what it does.
> 
> The three projects that PowerVMStackers contains (nova-powervm,
> networking-powervm, and ceilometer-powervm) are drivers/agents for
> nova, neutron, and ceilometer. They should ideally be under the
> umbrella of those projects, as other drivers/agents are, rather than
> split out as a PowerVMStackers project or SIG. But sadly, that is not
> the case due to historical reasons (primarily, the nova cores would
> not allow the nova powervm driver to be developed within nova like the
> drivers for Hyper-V, VMware, etc. so we had to create nova-powervm
> separately to do that development).

This is slightly misleading, from the conversations I was present for
the nova core team didn't want the powervm driver merged into the nova
repo until it was ready.  At no point, that I recall, was keeping the
nova-powervm code in it's own repo (as today) but under the governance
of the nova PTL.

That isn't the proposal.  Migration to a SIG would basically mean:

a. Moving PowerVMStackers from [1] to [2]
b. PowerVMSTackers SIG chair (*cough* PTL *cough*) would have to write a
   small update for the annual report

There are a couple of things you miss out on (by default):

1. (ATM) contributions to SIG repos aren't part of the electorate for TC
   This wouldn't be hard to fix, and is already being discussed.
2. SIGs don't by default get space at PTGs or 'project update' type
   sessions at the forum.  To the best of my knowledge this hasn't been
   used to date.

And that's where *this* proposal ends anything else is speculation
about things we could *also* do.

> separately to do that development). I assure you that I've never liked
> that false dichotomy, but it was not our choice. The right thing to do
> here is to get them under those umbrellas,

Yes!

>                                          , not to convert
> PowerVMStackers to a SIG. They need to be developed and managed just
> like any other OpenStack project producing code... not a SIG.

Kinda of.  I think the right thing to do is both!


Full disclosure, when PowerVMStackers was created I was strongly, and
still am, in favour of the 3 repos being goverened by the appropriate
team, and the people interested in developing that banding together hold
meetings and set direction you don't need to be a project team to do
that.

> So we've been working on getting nova-powervm merged into nova to get
> it under that umbrella. But to do that we have been asked to port
> functions in piece by piece, which is an arduous process that will
> take a while yet. So like it or not, I think we're stuck with
> PowerVMStackers for a while... unless you can convince the nova cores
> to move nova-powervm under their umbrella (and neutron/ceilometer, but
> I think that would far less of an issue).

Being part of the Nova project wont alter how the code migrates from
openstack/nova-powervm -> openstack/nova but I agree that it should
happen  (/me looks sideways the current nova PTL ;P)

>                                           They could still use have
> separate core groups, with some nova/neutron/ceilometer cores joining
> the *-powervm-cores groups.

Yup!  Clearly not my call but I agree with you.

>                             The ceilometer-powervm project used to be
> under the ceilometer umbrella before PowerVMStackers was created, and
> yet had a separate core list.

Yup and I argued that changing that was a regression at the time.

>                               And I think something similar was done
> with placement separating out of nova. This is a somewhat similar
> situation, but in reverse... merging into nova rather than separating
> from it.

Well that's quite different placement is the most recent 'extraction'
from nova but there have been many others.

 
> Once the driver/agent code is under the nova/neutron/ceilometer
> umbrellas, then yes, I would 100% agree that there should be a PowerVM
> SIG driving changes into code under the nova, neutron, and ceilometer
> umbrellas. But until that happens...

Yup *if* the code was under the team governance at some point
the nova-powervm repo and the code in nova/virt/powervm would be such
that nova-powervm could be retired and all further development would
happen in nova.

Yours Tony.

[1] https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L2901-L2928
[2] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-repos.yaml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190409/1f3b3e1e/attachment.sig>