[all]Forum summary: Expose SIGs and WGs
Dear all Here is the summary for forum `Expose SIGs and WGs` (etherpad [1] ). This concept still under development, so this is an open discussion and we need more feedbacks. Here are some general agreements on actions or ideas that we think it's worth to find the answer. *Set up guidelines for SIGs/WGs/Teams for interaction specific to this around tracking cross-project work* We tend to agree that we kind of lack for a guideline or a sample for SIGs/WGs, since all SIGs/WGs formed for different interest, we won't try to unify tools (unless that's what everyone agrees on) or rules for all groups. What we can do is to give more help to groups and provide a clear way for how they can set up cross-project works if they want to. Also, we can provide information on how to reach to users, ops, and developers and bridge them up. And we can even do a more general guideline or sample on how other SIGs/WGs are doing with their own workflow. Like self-healing SIG working on getting user story and feedback and use them to general better document/guideline for other users. Also, public cloud WG working on collect issues from public cloud providers and bring those issues to projects. Those IMO are great examples that we should put them down somewhere for cross SIGs/WGs consideration. As a further idea, we can even discuss if it's a common interest to have a SIG to help on SIGs. *A workflow for tracking:* This kind of follow above item. If we're going to set up a workflow, what we can add in to help people live an easier life? This is also an idea that no one in the room thinks it's a bad one, so it means in long term, it might worth our time to provide more clear information on what exactly workflow that we suggest everyone use. *Discuss SIG spec repo*: The discussion here is how can we monitoring SIGs/WGs health and track tasks. When talking about tasks we not just talking about bugs, but also features that's been considered as essential tasks for SIGs/WGs. We need a place to put them down in a trackable way (from a user story to a patch for implementation). *Ask foundation about have project update for SIGs/WGs*: One action we can start right now is to let SIGs/WGs present a project update (or even like a session but give each group 5 mins to present). This should help group getting more attention. And even capable to send out messages like what's the most important features or bug fixes they need from project teams, or what's the most important tasks that are under planning or working on. Fortunately, we got Melvin Hillsman (UC) volunteer on this task. We also have some real story (Luzi's story) for people to get a better understanding of why current workflow can look like for someone who tries to help. The thing that we also wish to do is to clear the message here. We think most of the tools are already there, so we shouldn't need to ask project teams to do any huge change. But still, we found there are definitely some improvements that we can do to better bridge users, ops, and developers. You might find some information here didn't give you a clear answer. And that's because of we still under open discussion for this. And I assume we gonna keep finding actions from discussions that we can do right away. We will try to avoid that we have to do the exact same session with the same argument over and over again. So please give your feedback, any idea, or give us your help if you also care about this. [1] https://etherpad.openstack.org/p/expose-sigs-and-wgs -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin
On 12/3/2018 11:42 AM, Rico Lin wrote:
We also have some real story (Luzi's story) for people to get a better understanding of why current workflow can look like for someone who tries to help.
I looked over the note on this in the etherpad. They did what they were asked and things have stalled. At this point, I think it comes down to priorities, and in order to prioritize something big like this that requires coordinated work across several projects, we are going to need more stakeholders coming forward and saying they also want this feature so the vendors who are paying the people to work upstream can be given specific time to give this the attention it needs. And that ties back into getting the top 1 or 2 wishlist items from each SIG and trying to sort those based on what is the highest rated most common need for the greatest number of people - sort of like what we see happening with the resource delete API community wide goal proposal. -- Thanks, Matt
Matt Riedemann <mriedemos@gmail.com> wrote:
On 12/3/2018 11:42 AM, Rico Lin wrote:
We also have some real story (Luzi's story) for people to get a better understanding of why current workflow can look like for someone who tries to help.
I looked over the note on this in the etherpad.
Me too - in case anyone missed the link to this initiative around image encryption, it's near the bottom of: https://etherpad.openstack.org/p/expose-sigs-and-wgs And BTW it sounds like a really cool initiative to me! In fact I think it could nicely complement the work I am doing on adding AMD SEV support to nova: https://review.openstack.org/#/c/609779/
They did what they were asked and things have stalled. At this point, I think it comes down to priorities, and in order to prioritize something big like this that requires coordinated work across several projects, we are going to need more stakeholders coming forward and saying they also want this feature so the vendors who are paying the people to work upstream can be given specific time to give this the attention it needs. And that ties back into getting the top 1 or 2 wishlist items from each SIG and trying to sort those based on what is the highest rated most common need for the greatest number of people - sort of like what we see happening with the resource delete API community wide goal proposal.
Agreed. The Security SIG sounds like a natural home for it. I'm going to wildly speculate that maybe part of the reason it stalled is that it was perceived as coming from a couple of individuals rather than a SIG. If the initiative had been backed by the Security SIG as something worth prioritising, then maybe it could have received wider attention. Also maybe copying a couple of tricks from the Self-healing SIG might (or might not) help. Firstly, try to find one or two security-minded people from each involved project who are willing to act as liasons with the Security SIG: https://wiki.openstack.org/wiki/Self-healing_SIG#Project_liasons Those people won't necessarily need to commit any time to development themselves, but hopefully they could volunteer to review specs specific to their project, and later patches too. Secondly, track all work on StoryBoard so that the current status is always clearly visible. A couple of other things struck me about this initiative: - They were requested to propose separate specs for each involved project (Nova, Cinder and Glance in this case). This resulted in quite a bit of duplication between the specs, but maybe that was unavoidable. - The question where to put the shared encryption and decryption code remained unresolved, even though of the three options proposed, only the oslo option had no cons listed: https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption oslo seems like a natural place to put it, so maybe the solution is to submit this spec to oslo? Although if the initiative was hosted by the Security SIG, then as a last resort the SIG could set up a git repository to host the code, at least as a temporary measure.
Am 12.12.18 um 14:20 schrieb Adam Spiers:
Matt Riedemann <mriedemos@gmail.com> wrote:
On 12/3/2018 11:42 AM, Rico Lin wrote:
We also have some real story (Luzi's story) for people to get a better understanding of why current workflow can look like for someone who tries to help.
I looked over the note on this in the etherpad.
Me too - in case anyone missed the link to this initiative around image encryption, it's near the bottom of: https://etherpad.openstack.org/p/expose-sigs-and-wgs
And BTW it sounds like a really cool initiative to me! In fact I think it could nicely complement the work I am doing on adding AMD SEV support to nova: https://review.openstack.org/#/c/609779/
Thank you, it's nice to hear that there are people who would like to have image encryption in OpenStack.
A couple of other things struck me about this initiative: - They were requested to propose separate specs for each involved project (Nova, Cinder and Glance in this case). This resulted in quite a bit of duplication between the specs, but maybe that was unavoidable.
We were told, they need those specs for documentation purposes. So I can understand why we have to do this. The downside is of course, that it not only takes longer to write / update the specs (as we really like to update all at the same time - so they are consistent), but mainly the project teams would only review the spec within their project (with a few exceptions).
- The question where to put the shared encryption and decryption code remained unresolved, even though of the three options proposed, only the oslo option had no cons listed:
https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption
oslo seems like a natural place to put it, so maybe the solution is to submit this spec to oslo?
Actually we already talked to the Security SIG, which are basically the same people as in Barbican, at the Summit. And we agreed that a new library in oslo would be a good option. So we proposed a spec for a new oslo-library: https://review.openstack.org/#/c/618754/ Sadly there aren't many people in the Security SIG / Barbican right now and they also have their own features and projects (Barbican) to maintain. A few people from the other involved project would maybe help. I am currently talking to Ildiko about pop-up teams, which would be an option to organize things. regards, Josephine (Luzi)
On 2018-12-12 14:57:31 +0100 (+0100), Josephine Seifert wrote: [...]
Actually we already talked to the Security SIG, which are basically the same people as in Barbican, at the Summit. [...]
I really appreciate the way you've engaged with other regulars in the Security SIG. It's a bit of a mischaracterization to suggest that they're mostly Barbican folks though. We do see redrobot (Douglas Mendizábal) semi-frequently in our IRC meetings, but most of our regulars at those meetings are vulnerability managers, core reviewers for Keystone, authors on the OpenStack Security Guide, maintainers of the Bandit static analyzer... We've shared a room with the Barbican team at some recent OpenStack Project Team Gatherings to help conserve available space at the conference venues since we definitely have some overlapping interests, so that could be part of the confusion. -- Jeremy Stanley
++ on engaging with us in the Security SIG, it's great to get more activity that is aligned with security and image encryption definitely seems like it fits in OpenStack. Unfortunately, as fungi mentioned, the Security SIG is currently not very active at the moment with the current members' responsibilities stretched over multiple other groups. On Wed, Dec 12, 2018 at 8:46 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-12-12 14:57:31 +0100 (+0100), Josephine Seifert wrote: [...]
Actually we already talked to the Security SIG, which are basically the same people as in Barbican, at the Summit. [...]
I really appreciate the way you've engaged with other regulars in the Security SIG. It's a bit of a mischaracterization to suggest that they're mostly Barbican folks though. We do see redrobot (Douglas Mendizábal) semi-frequently in our IRC meetings, but most of our regulars at those meetings are vulnerability managers, core reviewers for Keystone, authors on the OpenStack Security Guide, maintainers of the Bandit static analyzer... We've shared a room with the Barbican team at some recent OpenStack Project Team Gatherings to help conserve available space at the conference venues since we definitely have some overlapping interests, so that could be part of the confusion. -- Jeremy Stanley
On 13/12/18 3:46 AM, Jeremy Stanley wrote:
On 2018-12-12 14:57:31 +0100 (+0100), Josephine Seifert wrote: [...]
Actually we already talked to the Security SIG, which are basically the same people as in Barbican, at the Summit. [...]
I really appreciate the way you've engaged with other regulars in the Security SIG. It's a bit of a mischaracterization to suggest that they're mostly Barbican folks though. We do see redrobot (Douglas Mendizábal) semi-frequently in our IRC meetings, but most of our regulars at those meetings are vulnerability managers, core reviewers for Keystone, authors on the OpenStack Security Guide, maintainers of the Bandit static analyzer... We've shared a room with the Barbican team at some recent OpenStack Project Team Gatherings to help conserve available space at the conference venues since we definitely have some overlapping interests, so that could be part of the confusion.
Apologies, I was the source of this misinformation. Thanks for the correction. - ZB
Josephine Seifert <josephine.seifert@secustack.com> wrote:
Am 12.12.18 um 14:20 schrieb Adam Spiers:
Matt Riedemann <mriedemos@gmail.com> wrote:
On 12/3/2018 11:42 AM, Rico Lin wrote:
We also have some real story (Luzi's story) for people to get a better understanding of why current workflow can look like for someone who tries to help.
I looked over the note on this in the etherpad.
Me too - in case anyone missed the link to this initiative around image encryption, it's near the bottom of: https://etherpad.openstack.org/p/expose-sigs-and-wgs
And BTW it sounds like a really cool initiative to me! In fact I think it could nicely complement the work I am doing on adding AMD SEV support to nova: https://review.openstack.org/#/c/609779/
Thank you, it's nice to hear that there are people who would like to have image encryption in OpenStack.
:-)
A couple of other things struck me about this initiative: - They were requested to propose separate specs for each involved project (Nova, Cinder and Glance in this case). This resulted in quite a bit of duplication between the specs, but maybe that was unavoidable.
We were told, they need those specs for documentation purposes. So I can understand why we have to do this. The downside is of course, that it not only takes longer to write / update the specs (as we really like to update all at the same time - so they are consistent), but mainly the project teams would only review the spec within their project (with a few exceptions).
- The question where to put the shared encryption and decryption code remained unresolved, even though of the three options proposed, only the oslo option had no cons listed:
https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption
oslo seems like a natural place to put it, so maybe the solution is to submit this spec to oslo?
Actually we already talked to the Security SIG, which are basically the same people as in Barbican, at the Summit. And we agreed that a new library in oslo would be a good option.
Got it - thanks to you and Jeremy for the extra context here.
So we proposed a spec for a new oslo-library: https://review.openstack.org/#/c/618754/
Ah, nice - thanks! What do you think about my suggestion of tracking this whole initiative as a story in StoryBoard? IMHO that would be a convenient way of tracking all the specs and any other related activity together from one place.
What do you think about my suggestion of tracking this whole initiative as a story in StoryBoard? IMHO that would be a convenient way of tracking all the specs and any other related activity together from one place.
I will have to look into this, but it seems like a reasonable idea indeed. Thank you. I might try to combine it with the pop-up team idea :)
On 2018-12-12 13:20:44 +0000 (+0000), Adam Spiers wrote:
Matt Riedemann <mriedemos@gmail.com> wrote: [...]
They did what they were asked and things have stalled. At this point, I think it comes down to priorities, and in order to prioritize something big like this that requires coordinated work across several projects, we are going to need more stakeholders coming forward and saying they also want this feature so the vendors who are paying the people to work upstream can be given specific time to give this the attention it needs. And that ties back into getting the top 1 or 2 wishlist items from each SIG and trying to sort those based on what is the highest rated most common need for the greatest number of people - sort of like what we see happening with the resource delete API community wide goal proposal.
Agreed. The Security SIG sounds like a natural home for it. I'm going to wildly speculate that maybe part of the reason it stalled is that it was perceived as coming from a couple of individuals rather than a SIG. If the initiative had been backed by the Security SIG as something worth prioritising, then maybe it could have received wider attention. [...]
We've seen Luzi and mhen in recent Security SIG weekly IRC meetings talking about the proposed specs for Cinder, Glance and Nova. However most of the representation in the Security SIG is from people involved in VMT work as well as some contributors from the Keystone and Barbican teams. As much as I'd like to say the Security SIG is a sensible place to drive an effort like this, most teams in OpenStack aren't really engaged in that SIG and the people who are regulars to our meetings lack the capacity to act as project managers in that regard. I'm happy to state, as a participant in the Security SIG, that I think having image encryption in OpenStack would be a great feature. I don't expect that alone helps an awful lot though. -- Jeremy Stanley
Adam Spiers wrote:
Matt Riedemann <mriedemos@gmail.com> wrote:
They did what they were asked and things have stalled. At this point, I think it comes down to priorities, and in order to prioritize something big like this that requires coordinated work across several projects, we are going to need more stakeholders coming forward and saying they also want this feature so the vendors who are paying the people to work upstream can be given specific time to give this the attention it needs. And that ties back into getting the top 1 or 2 wishlist items from each SIG and trying to sort those based on what is the highest rated most common need for the greatest number of people - sort of like what we see happening with the resource delete API community wide goal proposal.
Agreed. The Security SIG sounds like a natural home for it. I'm going to wildly speculate that maybe part of the reason it stalled is that it was perceived as coming from a couple of individuals rather than a SIG. If the initiative had been backed by the Security SIG as something worth prioritising, then maybe it could have received wider attention.
Yes... As much as we'd like to think the problem here is purely technical, getting it done in an openly-collaborating community means it's also a social problem. It will compete with a LOT of other things to get priority. In order to get it done, you need to make it well-known, and gather a bit of mindshare, so that it gets on people's radar with some amount of priority. That means the effort needs to be clearly identified (give it a distinctive name), and a lot of communication needs to be done around it (presentations, forum/PTG sessions, ML status reports...). Working under a SIG umbrella definitely facilitates that "promotion" side of the work, since SIGs already have some visibility built in. The "top 2 wishlist per SIG" idea is just one way to encourage focusing this promotion effort on a limited number of things at the same time, because there is just no way you can promote 10 different things and expect them all to stick. -- Thierry Carrez (ttx)
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
Dear all
Here is the summary for forum `Expose SIGs and WGs` (etherpad [1] ). This concept still under development, so this is an open discussion and we need more feedbacks. Here are some general agreements on actions or ideas that we think it's worth to find the answer.
Thanks for driving this, Rico! And sorry for the slow reply.
*Set up guidelines for SIGs/WGs/Teams for interaction specific to this around tracking cross-project work* We tend to agree that we kind of lack for a guideline or a sample for SIGs/WGs, since all SIGs/WGs formed for different interest, we won't try to unify tools (unless that's what everyone agrees on) or rules for all groups. What we can do is to give more help to groups and provide a clear way for how they can set up cross-project works if they want to. Also, we can provide information on how to reach to users, ops, and developers and bridge them up. And we can even do a more general guideline or sample on how other SIGs/WGs are doing with their own workflow. Like self-healing SIG working on getting user story and feedback and use them to general better document/guideline for other users. Also, public cloud WG working on collect issues from public cloud providers and bring those issues to projects. Those IMO are great examples that we should put them down somewhere for cross SIGs/WGs consideration.
We already have some basic guidelines for communication here: https://governance.openstack.org/sigs/ Maybe we should just extend that with some suggested best practices? For example: - Set up an openstack/$signame-sig git repository (we could even create a cookiecutter repo, or is that overkill?) - Set up a StoryBoard project linked with that git repository - For cross-project collaboration, recommend the following: - submit cross-project stories to StoryBoard - submit cross-project specs to the SIG's git repo (and the SIG lead could set up a template for these, e.g. http://git.openstack.org/cgit/openstack/self-healing-sig/tree/specs/template... ) - post cross-project discussion to openstack-discuss@ with [$signame-sig] and all the appropriate [$project] tags in the Subject header
As a further idea, we can even discuss if it's a common interest to have a SIG to help on SIGs.
We already have that ;-) It's the "meta" SIG, mentioned here: https://governance.openstack.org/sigs/
*A workflow for tracking:* This kind of follow above item. If we're going to set up a workflow, what we can add in to help people live an easier life? This is also an idea that no one in the room thinks it's a bad one, so it means in long term, it might worth our time to provide more clear information on what exactly workflow that we suggest everyone use.
Doesn't StoryBoard handle tracking nicely?
*Discuss SIG spec repo*: The discussion here is how can we monitoring SIGs/WGs health and track tasks. When talking about tasks we not just talking about bugs, but also features that's been considered as essential tasks for SIGs/WGs. We need a place to put them down in a trackable way (from a user story to a patch for implementation).
Again I think StoryBoard works nicely for this.
*Ask foundation about have project update for SIGs/WGs*: One action we can start right now is to let SIGs/WGs present a project update (or even like a session but give each group 5 mins to present). This should help group getting more attention. And even capable to send out messages like what's the most important features or bug fixes they need from project teams, or what's the most important tasks that are under planning or working on. Fortunately, we got Melvin Hillsman (UC) volunteer on this task.
Yes, I think this is really important. And from personal experience as a SIG chair, I know it would help me to have someone pestering me to provide project updates ;-)
The thing that we also wish to do is to clear the message here. We think most of the tools are already there, so we shouldn't need to ask project teams to do any huge change. But still, we found there are definitely some improvements that we can do to better bridge users, ops, and developers. You might find some information here didn't give you a clear answer. And that's because of we still under open discussion for this. And I assume we gonna keep finding actions from discussions that we can do right away. We will try to avoid that we have to do the exact same session with the same argument over and over again. So please give your feedback, any idea, or give us your help if you also care about this.
Yes, I think you are right. My simple suggestion is above: just add some best practices to the governance-sigs page.
Adam Spiers wrote:
Rico Lin <rico.lin.guanyu@gmail.com> wrote:
As a further idea, we can even discuss if it's a common interest to have a SIG to help on SIGs.
We already have that ;-) It's the "meta" SIG, mentioned here: https://governance.openstack.org/sigs/
Yes, and so far it's mostly been a two-person effort to bootstrap the SIG concept and encourage SIGs (which are basically groups of like-minded folks wanting to work on a specific topic that does not fit in the more traditional team structure) to be formed. I think the bootstrapping phase is completed now, so it's time to move to phase 2, which is putting some systems in place to make SIGs more successful. We now have enough information on the success and failures of early SIGs to debate what we could put in place to help them. I think this discussion fits right in the goals of the Meta SIG. So far the Meta SIG has been going fully async (no meeting, just ML discussion threads and reviews of proposed changes to the openstack/governance-sigs repository). -- Thierry Carrez (ttx)
Thierry Carrez <thierry@openstack.org> wrote:
I think the bootstrapping phase is completed now, so it's time to move to phase 2, which is putting some systems in place to make SIGs more successful. We now have enough information on the success and failures of early SIGs to debate what we could put in place to help them. I think this discussion fits right in the goals of the Meta SIG.
Makes sense. Should I submit a review to governance-sigs adding some suggested best practices? Here are some ideas I proposed based on what seems to be working fairly well so far for the Self-healing SIG: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000838.... Having said that, I'm sure that there are other SIGs exhibiting better momentum than the steady but modest progress we've achieved so far, so it's entirely likely that others can come up with more effective best practices than what sprang to my mind.
So far the Meta SIG has been going fully async (no meeting, just ML discussion threads and reviews of proposed changes to the openstack/governance-sigs repository).
IMHO that seems to have worked pretty well so far. I suppose we could also set up occasional IRC meetings, e.g. every month or two?
participants (8)
-
Adam Spiers
-
Gage Hugo
-
Jeremy Stanley
-
Josephine Seifert
-
Matt Riedemann
-
Rico Lin
-
Thierry Carrez
-
Zane Bitter