Open Stack

On 4/9/19, 7:26 AM, "Thierry Carrez" <thierry at openstack.org> wrote:
> SIGs can produce code. The difference with project teams is that our 
> project teams are organized around a specific component (Nova, Swift...) 
> or a horizontal software development function that applies to all those 
> components (QA, Documentation, release management, common libraries...)

Honest question, what SIGs produce code in repos that they own/maintain separate from nova, etc.? Point me to those repos so we can talk examples? My understanding of SIGs is that they're primarily focused on requirements gathering and communication for their area of interest and then trying to drive corresponding changes into code that is actually owned/maintained by other teams like nova. I don't know of any SIG producing anything like what is produced/maintained by PowerVMStackers. Scrolling through the list of current SIGs [1], none of them sound like they're writing a lot of code that they own/maintain. Writing code that goes into nova, etc. sure, but not that they own/maintain independently. Maybe I'm just uninformed?

Note: More PowerVMStackers requirements come from nova than from any PowerVM stakeholder, just keeping up with changes that nova implements.

> Once you frame it like that, you can spot a few outliers in the current 
> project team list: things that are neither centered around a specific 
> component nor a horizontal function: PowerVMStackers and Winstackers.

I definitely understand/agree that PowerVMStackers is an outlier here. And I would never have wanted things this way. PowerVMStackers absolutely _should_ be a SIG (as I said in my previous note) but only if a) the drivers/agents that it currently contains are properly rehomed under nova, neutron, and ceilometer. Then PowerVMStackers could be like other SIGs, collecting requirements from folks interested in Power and implementing those requirements in nova, etc. Or b) I'm wrong about SIGs (or we can modify them to address the issues) per the questions above.

> That said, I understand your objection. Establishing PowerVMStackers as 
> a SIG clearly sends the message that caring about PowerVM is a special 
> interest and not everyone's interest. It makes it less likely that the 
> *-powervm repository/features ever get merged into their respective 
> projects. And if this merging is right around the corner, I agree that 
> setting up a PowerVM SIG is counterproductive.

That's not my objection at all, at least not the special interest part. The "less likely" part is definitely a concern, but honestly I hadn't even thought of that until you pointed it out.

> So I guess the real question is, is PowerVM support a mainline feature 
> that just happens to be temporarily maintained under a specific team for 
> weird organizational reasons ? Or is it considered not to be mainline 
> material (a bit like Windows support), and therefore the people that 
> care about that feature should maintain code to support that 
> indefinitely on the side ?

I don't see why PowerVM support should be any less mainline than the Hyper-V and VMware drivers that currently fall under the nova umbrella. We have far more users than both of those drivers combined, a strong history of community involvement, etc. So yeah, I'd say mainline if those are considered mainline.

> If it's the former, and there is a clear plan to get all that 
> functionality up in their respective teams in a near future, then I 
> agree a SIG won't really help. If the latter though, I really think that 
> a SIG is a much better way to represent what is happening there, and 
> would give the "PowerVM support" SIG extra visibility.
> 
> My impression is that it's been 4 years now that those repositories 
> exist separately from Nova, Neutron and Ceilometer and nobody seems in a 
> hurry to merge that functionality there... which is why I assumed the 
> latter.

The nova cores didn't let us _start_ merging it until last year. :) And as I said, that's an arduous process. We've been asked to port one function at a time and take it through the normal rigorous review process. I understand why, and I'm not saying I disagree, but I want to be clear that that kind of migration is going to take a while.

But I want to be clear... I don't think everything would have to move into the nova git repo to be under the compute project umbrella. We could hasten that along by just moving nova-powervm from PowerVMStackers to Compute, like os-vif and python-novaclient. And then similar with networking-powervm and ceilometer-powerm under Networking and Telemetry, respectively.

[1] https://governance.openstack.org/sigs/