[PowerVMStackers][Winstackers][uc][tc] Encourage to transform from project to SIG
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). There are two questions I would hope team members from both teams can help to answer. 1. Is the mission for your project completed? 2. Is the team still active? 3. Any concerns or objections on moving from project to SIG? If we agree to change from project to SIG, I expect most of the tools will stay the way it is. The only thing for the first step should just change your project definition from project to SIG (like from PowerVMStackers to PowerVM SIG). So it will not cause the team any effort for sure. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin
Rico Lin wrote:
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).
Yes, I think it would make a lot of sense... What defines those groups is not the software bits that they produce, but their overall goals (getting OpenStack to run on Windows, supporting PowerVM technology in OpenStack). The repositories that they maintain is just a means toward this larger end, and a lot of their work is actually done within existing repositories from other project teams. The SIG model seems therefore a better fit than the "Project team" model which is more centered around a specific component and/or a set of repositories. -- Thierry Carrez (ttx)
On 2019-04-08 18:04:39 +0200 (+0200), Thierry Carrez wrote: [...]
What defines those groups is not the software bits that they produce, but their overall goals (getting OpenStack to run on Windows, supporting PowerVM technology in OpenStack). The repositories that they maintain is just a means toward this larger end, and a lot of their work is actually done within existing repositories from other project teams. [...]
This brings up an interesting question, though. The contributors to those Winstackers and PowerVMstackers repositories today are able to vote in technical committee elections. Should we consider an amendment to the charter to include contributors to SIG-owned repositories in the TC electorate? -- Jeremy Stanley
On 08/04/2019 17:11, Jeremy Stanley wrote:
On 2019-04-08 18:04:39 +0200 (+0200), Thierry Carrez wrote: [...]
What defines those groups is not the software bits that they produce, but their overall goals (getting OpenStack to run on Windows, supporting PowerVM technology in OpenStack). The repositories that they maintain is just a means toward this larger end, and a lot of their work is actually done within existing repositories from other project teams. [...]
This brings up an interesting question, though. The contributors to those Winstackers and PowerVMstackers repositories today are able to vote in technical committee elections. Should we consider an amendment to the charter to include contributors to SIG-owned repositories in the TC electorate?
100% yes. E.G. - Someone who contributes to the api-sig repos is as deserving of a vote for the TC as someone who commits to designate / glance / nova neutron. (I used api-sig as an example, as I think pretty much anyone who has committed there already had a vote due to other openstack commits, but if we are going to move into a situation where we would remove peoples ability to vote we should adjust our processes to avoid it). - Graham
On Mon, Apr 8, 2019 at 11:46 AM Graham Hayes <gr@ham.ie> wrote:
On 08/04/2019 17:11, Jeremy Stanley wrote:
On 2019-04-08 18:04:39 +0200 (+0200), Thierry Carrez wrote: [...]
What defines those groups is not the software bits that they produce, but their overall goals (getting OpenStack to run on Windows, supporting PowerVM technology in OpenStack). The repositories that they maintain is just a means toward this larger end, and a lot of their work is actually done within existing repositories from other project teams. [...]
This brings up an interesting question, though. The contributors to those Winstackers and PowerVMstackers repositories today are able to vote in technical committee elections. Should we consider an amendment to the charter to include contributors to SIG-owned repositories in the TC electorate?
100% yes.
E.G. - Someone who contributes to the api-sig repos is as deserving of a vote for the TC as someone who commits to designate / glance / nova neutron.
(I used api-sig as an example, as I think pretty much anyone who has committed there already had a vote due to other openstack commits, but if we are going to move into a situation where we would remove peoples ability to vote we should adjust our processes to avoid it).
- Graham
FWIW - we have also tried to include SIG activity as criteria for AUC status and voting in the UC election. VW -- Matt Van Winkle Senior Manager, Software Engineering | Salesforce
On 2019-04-08 12:02:22 -0500 (-0500), Matt Van Winkle wrote: [...]
FWIW - we have also tried to include SIG activity as criteria for AUC status and voting in the UC election.
Yes, I thought about mentioning that as well. I see the two as a great potential combination: allowing contributors to SIG repositories could give the right to vote in both TC and UC elections due to the broader scope of the work in which they are involved. -- Jeremy Stanley
Jeremy Stanley wrote:
On 2019-04-08 12:02:22 -0500 (-0500), Matt Van Winkle wrote: [...]
FWIW - we have also tried to include SIG activity as criteria for AUC status and voting in the UC election.
Yes, I thought about mentioning that as well. I see the two as a great potential combination: allowing contributors to SIG repositories could give the right to vote in both TC and UC elections due to the broader scope of the work in which they are involved.
I thought that was already the case :) When we set up SIGs originally with Melvin the intent definitely was that contributing to a SIG would give you both ATC and AUC voting rights. We may have skipped a step when we implemented them... So if it's not the case already we should definitely make it so. -- Thierry Carrez (ttx)
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.
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). 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, 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. 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). They could still use have separate core groups, with some nova/neutron/ceilometer cores joining the *-powervm-cores groups. The ceilometer-powervm project used to be under the ceilometer umbrella before PowerVMStackers was created, and yet had a separate core list. 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. 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...
On Mon, Apr 08, 2019 at 11:01:44PM +0000, William M Edmonds - edmondsw@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/project... [2] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-re...
Tony Breeds wrote:
[...] 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.
Actually SIGs get proposed space at PTGs, exactly like project teams do. -- Thierry Carrez (ttx)
Okay, I'll bite.
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)
I would be supportive of the continuation of the effort to move nova-powervm into nova proper. Now, I happen to know from firsthand experience that the code is excellent - certainly way prettier than a lot of the legacy gorp in the libvirt driver. Nevertheless, whether by switching governance or porting the code into the nova project, it would be irresponsible of the nova team to assume ownership without thorough review. I don't think anyone is arguing with that, including Matthew:
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
That said, the effort needs to be driven by PowerVM. The nova team is not so abundantly staffed as to be able to go out volunteering for stuff like this just because it would be nice. PowerVM did not propose any ports in the stein cycle, and I haven't seen anything for train yet either. I understand the team is being "restructured"; I assume the cadence will resume once the dust settles. In the meantime, while there is still a significant gap between the in-tree and out-of-tree versions, it definitely makes sense for the *-powervm projects to have their own core team(s) and PTL. Beyond that (I may get in trouble for saying this) I care not a whit whether it's called a project or a SIG or a club or a cabal. efried .
On Tue, Apr 09, 2019 at 05:01:31PM -0500, Eric Fried wrote:
Okay, I'll bite.
Not bite ... add your sought after opinio ;P <SNIP>
I would be supportive of the continuation of the effort to move nova-powervm into nova proper. Now, I happen to know from firsthand experience that the code is excellent - certainly way prettier than a lot of the legacy gorp in the libvirt driver. Nevertheless, whether by switching governance or porting the code into the nova project, it would be irresponsible of the nova team to assume ownership without thorough review. I don't think anyone is arguing with that, including Matthew:
Switching governance doesn't require the core-team to change and the point at which nova-core takes over from nova-powervm-core is when the code moves into openstack/nova. <SNIP>
In the meantime, while there is still a significant gap between the in-tree and out-of-tree versions, it definitely makes sense for the *-powervm projects to have their own core team(s) and PTL.
core-team sure, but what is it that a PTL does/can do that a SIG chair can't? Yours Tony.
On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
core-team sure, but what is it that a PTL does/can do that a SIG chair can't?
Ack patches in other repositories like release, governance, etc.? But yeah, no reason a SIG chair couldn't also do those things, as long as the vote is recognized the same way.
I can't speak to the TC but I think that a SIG chair would basically be a Liaison in the releases repo and we already know how to handle that. Yours Tony.
Tony Breeds wrote:
On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
core-team sure, but what is it that a PTL does/can do that a SIG chair can't?
Ack patches in other repositories like release, governance, etc.? But yeah, no reason a SIG chair couldn't also do those things, as long as the vote is recognized the same way.
I can't speak to the TC but I think that a SIG chair would basically be a Liaison in the releases repo and we already know how to handle that.
So.. switching to my release management hat... that actually brings up an interesting point, and a good reason to keep PowerVMStackers and Winstackers the same. Project teams basically produce "OpenStack" the software release, while SIGs work to make "OpenStack" more relevant for specific cases. While SIGs can produce code and can own git repositories, we currently have no SIG that owns *deliverables* being made part of the regular OpenStack release. The release team only tracks project teams, and it's simpler if it stays that way. It's also a really good delineation as to what is project team territory and what is SIG territory. Both PowerVMStackers or WinStackers currently produce deliverables that are released under a cycle-based model and are included in the final "OpenStack" release. Switching those teams to become SIGs would have an additional consequence: it would remove those deliverables from the "OpenStack" release. So unless those teams actually want that, or the TC decides to do that, I don't think we should switch those teams to SIGs. -- Thierry Carrez (ttx)
On Wed, Apr 10, 2019 at 10:41:31AM +0200, Thierry Carrez wrote:
Tony Breeds wrote:
On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
core-team sure, but what is it that a PTL does/can do that a SIG chair can't?
Ack patches in other repositories like release, governance, etc.? But yeah, no reason a SIG chair couldn't also do those things, as long as the vote is recognized the same way.
I can't speak to the TC but I think that a SIG chair would basically be a Liaison in the releases repo and we already know how to handle that.
So.. switching to my release management hat... that actually brings up an interesting point, and a good reason to keep PowerVMStackers and Winstackers the same.
Project teams basically produce "OpenStack" the software release, while SIGs work to make "OpenStack" more relevant for specific cases. While SIGs can produce code and can own git repositories, we currently have no SIG that owns *deliverables* being made part of the regular OpenStack release.
The release team only tracks project teams, and it's simpler if it stays that way. It's also a really good delineation as to what is project team territory and what is SIG territory.
Both PowerVMStackers or WinStackers currently produce deliverables that are released under a cycle-based model and are included in the final "OpenStack" release. Switching those teams to become SIGs would have an additional consequence: it would remove those deliverables from the "OpenStack" release.
Only *if* those repos don't get 'adopted' by another project. In the hypothetical example we're looking at: openstack/nova-powervm would come under the governance of nova (and therefore still have all the 'rights' of a project) (same with Telemetry and Neutron). The SIG would be there to maintain consistency across the 3 project teams. I feel like that's a better outcome but it isn't the actual proposal we started discussing and I kinda de-railed the conversation ... sorry.
So unless those teams actually want that, or the TC decides to do that, I don't think we should switch those teams to SIGs.
So the original proposal which would be a straight transition doesn't work for this reason which is good to know Yours Tony.
On 4/10/19, 5:24 AM, "Tony Breeds" <tony@bakeyournoodle.com> wrote:
On Wed, Apr 10, 2019 at 10:41:31AM +0200, Thierry Carrez wrote:
Tony Breeds wrote:
On Tue, Apr 09, 2019 at 09:22:43PM -0500, Eric Fried wrote:
core-team sure, but what is it that a PTL does/can do that a SIG chair can't?
Ack patches in other repositories like release, governance, etc.? But yeah, no reason a SIG chair couldn't also do those things, as long as the vote is recognized the same way.
I can't speak to the TC but I think that a SIG chair would basically be a Liaison in the releases repo and we already know how to handle that.
So.. switching to my release management hat... that actually brings up an interesting point, and a good reason to keep PowerVMStackers and Winstackers the same.
Project teams basically produce "OpenStack" the software release, while SIGs work to make "OpenStack" more relevant for specific cases. While SIGs can produce code and can own git repositories, we currently have no SIG that owns *deliverables* being made part of the regular OpenStack release.
The release team only tracks project teams, and it's simpler if it stays that way. It's also a really good delineation as to what is project team territory and what is SIG territory.
Both PowerVMStackers or WinStackers currently produce deliverables that are released under a cycle-based model and are included in the final "OpenStack" release. Switching those teams to become SIGs would have an additional consequence: it would remove those deliverables from the "OpenStack" release.
Only *if* those repos don't get 'adopted' by another project.
In the hypothetical example we're looking at: openstack/nova-powervm would come under the governance of nova (and therefore still have all the 'rights' of a project) (same with Telemetry and Neutron). The SIG would be there to maintain consistency across the 3 project teams.
I feel like that's a better outcome but it isn't the actual proposal we started discussing and I kinda de-railed the conversation ... sorry.
So unless those teams actually want that, or the TC decides to do that, I don't think we should switch those teams to SIGs.
So the original proposal which would be a straight transition doesn't work for this reason which is good to know
Now we're tracking. This (both Thierry's and Tony's emails here) is what I was trying to say. Sorry I wasn't clearer, but you got there anyway... Thanks.
On 9/04/19 6:01 PM, Eric Fried wrote:
In the meantime, while there is still a significant gap between the in-tree and out-of-tree versions, it definitely makes sense for the *-powervm projects to have their own core team(s) and PTL.
I agree with Tony that this part doesn't necessarily follow. Of course the repos should continue to have their own core team, and that's completely possible while being under Nova's governance. I'm sure that the release team can cope with having separate liaisons for different sets of repos within a projects (even though I'm sure they'd appreciate not having a different liaison for e.g. every repo in OpenStack ;). It sounds like moving the PowerVM repos under Nova's governance would be a topic worthy of active discussion between the two projects. cheers, Zane.
It sounds like moving the PowerVM repos under Nova's governance would be a topic worthy of active discussion between the two projects.
/me discusses... As I said previously in this thread [1], "whether by switching governance or porting the code into the nova project, it would be irresponsible of the nova team to assume ownership without thorough review." And actually, it's about more than assuming ownership. Thorough review would be prudent so the nova team has familiarity with the code. That said, as long as *-powervm-core groups could still exist, the PowerVM team - who are patently the experts on that code - would still be able to integrate changes without the blessing of nova-core. (The alternative doesn't seem tenable to me, and is in fact a problem we have with most of the in-tree virt drivers today.) So, forgive me for being dense, but what does that ^ gain anyone? And what does the long-term plan for the in-tree vs. out-of-tree drivers become in this scenario? efried [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004824.htm...
William M Edmonds - edmondsw@us.ibm.com wrote:
[...]
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). 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, 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.
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...) 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. 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. 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 ? 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. -- Thierry Carrez (ttx)
On 4/9/19, 7:26 AM, "Thierry Carrez" <thierry@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/
William M Edmonds - edmondsw@us.ibm.com wrote:
On 4/9/19, 7:26 AM, "Thierry Carrez" <thierry@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?
You can find the reference list of repositories attached to SIGs at: https://git.openstack.org/cgit/openstack/governance/tree/reference/sigs-repo... Most of those maintain documentation repos (and land their code into existing repositories). Only the Security SIG currently maintains code repos. -- Thierry
On Apr 9, 2019, at 8:18 AM, William M Edmonds - edmondsw@us.ibm.com <edmondsw@us.ibm.com> wrote:
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?
The API-SIG has its own repo: https://github.com/openstack/api-sig -- Ed Leafe
participants (10)
-
Ed Leafe
-
Eric Fried
-
Graham Hayes
-
Jeremy Stanley
-
Matt Van Winkle
-
Rico Lin
-
Thierry Carrez
-
Tony Breeds
-
William M Edmonds - edmondsw＠us.ibm.com
-
Zane Bitter