From aspiers at suse.com Mon Sep 3 17:16:11 2018 From: aspiers at suse.com (Adam Spiers) Date: Mon, 3 Sep 2018 18:16:11 +0100 Subject: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops In-Reply-To: References: <20180813165615.m7yltwe5zqkbjdx6@pacific.linksys.moosehall> Message-ID: <20180903171611.xcp3tlcg56vlugcg@pacific.linksys.moosehall> Rico Lin wrote: >On Tue, Aug 14, 2018 at 12:56 AM Adam Spiers wrote: >> This sounds like a great idea to me! I've submitted a story for this: >> >> https://storyboard.openstack.org/#!/story/2003423 >> >> and set up an etherpad for brainstorming: >> >> https://etherpad.openstack.org/p/self-healing-user-survey-questions > >I think those two questions are quite great. Just put some extra idea in >that. >Also, I have proposed you're etherpad under UC discussions in PTG >https://etherpad.openstack.org/p/uc-stein-ptg Cool, thanks! [snipped] >> This sounds reasonable. We already link to the StoryBoard from the >> SIG portal wiki page: >> >> >https://wiki.openstack.org/wiki/Self-healing_SIG#Community_Infrastructure_.2F_Resources >> >> but yes we could also proactively announce this in places which would >> reach more users and operators, inviting them to submit stories. Can >> you suggest how best to do this? We could email the openstack and >> openstack-operators lists, although TBH I have done this several times >> in the past and not gotten much engagement - probably because both >> lists are very high traffic. > >I guess we should keep trying to propose in ML. There're two more places I >think we can try on. As we might be able to have our own page in User >survey, I think we're allow to put more message to point a place(our git >repo, or an etherpad) for Users who like to add more information during >that survey. The second place is SuperUser MagZ. If we can come's up with >an article (which we can plan in PTG if we like to have one) to introduce >our plan, works, and needs. I think Super User will willing to help us post >that article out. If we got some article, we can Use official OpenStack >social media (FB, Twitter, etc) to broadcast that information. An article in SuperUser is a great idea, and it's really funny (and good!) that you suggested that, because Lauren and Allison already suggested that to me, and I made an initial plan which includes asking you to help write the material ;-) https://etherpad.openstack.org/p/HA-self-healing-article I would also like to invite other PTLs working in the self-healing space (e.g. Ifat, Eric) to contribute, and anyone else who thinks they could help (e.g. Nemat, Andrew B). I've added this and a few other things to the agenda for Denver: https://etherpad.openstack.org/p/self-healing-sig-stein-ptg >> I love this idea, and yes the self-healing-sig git repository could >> absolutely be the home for this gating code. I suspect that a big >> part of the challenge will be to simulate failures in order to test >> the self-healing functionality. In fact we already have a story >> regarding automated testing: >> >> https://storyboard.openstack.org/#!/story/2002129 >> >> although that is much more ambitious in scope, i.e. building a >> complete framework which could support testing of many different >> self-healing scenarios. I have some documentation on the Eris project >> which I am planning to upload to the repository on this. >> >> However your proposal sounds less ambitious and more likely to be >> achievable in the short-term, so I'd love to learn more about how you >> think this might work (unfortunately I don't know much about Tempest >> internals yet). > >Since the git just updated with more official project format, we can add >Zuul.yaml to define our periodic job I think we already got a lot of places >to add tempest test(I think we might be able to use heat-tempest-plugin >too), so we shouldn't need to build our own tempest repo Sounds good! Let's discuss further at the PTG! From ifatafekn at gmail.com Tue Sep 4 07:24:08 2018 From: ifatafekn at gmail.com (Ifat Afek) Date: Tue, 4 Sep 2018 10:24:08 +0300 Subject: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops In-Reply-To: <20180903171611.xcp3tlcg56vlugcg@pacific.linksys.moosehall> References: <20180813165615.m7yltwe5zqkbjdx6@pacific.linksys.moosehall> <20180903171611.xcp3tlcg56vlugcg@pacific.linksys.moosehall> Message-ID: On Mon, Sep 3, 2018 at 8:17 PM Adam Spiers wrote: > > An article in SuperUser is a great idea, and it's really funny (and > good!) that you suggested that, because Lauren and Allison already > suggested that to me, and I made an initial plan which includes asking > you to help write the material ;-) > > https://etherpad.openstack.org/p/HA-self-healing-article > > I would also like to invite other PTLs working in the self-healing > space (e.g. Ifat, Eric) to contribute, and anyone else who thinks they > could help (e.g. Nemat, Andrew B). I've added this and a few other > things to the agenda for Denver: > > https://etherpad.openstack.org/p/self-healing-sig-stein-ptg > Hi Adam, Rico, Great initiative! Unfortunately, I will not attend the PTG this time. But I’ll be happy to help with the article or whatever else is needed. Br, Ifat -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifat.afek at nokia.com Tue Sep 4 07:09:20 2018 From: ifat.afek at nokia.com (Afek, Ifat (Nokia - IL/Kfar Sava)) Date: Tue, 4 Sep 2018 07:09:20 +0000 Subject: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops In-Reply-To: <20180903171611.xcp3tlcg56vlugcg@pacific.linksys.moosehall> References: <20180813165615.m7yltwe5zqkbjdx6@pacific.linksys.moosehall> <20180903171611.xcp3tlcg56vlugcg@pacific.linksys.moosehall> Message-ID: On 2018-09-03, 8:16 PM, "Adam Spiers" wrote: An article in SuperUser is a great idea, and it's really funny (and good!) that you suggested that, because Lauren and Allison already suggested that to me, and I made an initial plan which includes asking you to help write the material ;-) https://etherpad.openstack.org/p/HA-self-healing-article I would also like to invite other PTLs working in the self-healing space (e.g. Ifat, Eric) to contribute, and anyone else who thinks they could help (e.g. Nemat, Andrew B). I've added this and a few other things to the agenda for Denver: https://etherpad.openstack.org/p/self-healing-sig-stein-ptg Hi Adam, Rico, Great initiative! Unfortunately, I will not attend the PTG this time. But I’ll be happy to help with the article or whatever else is needed. Br, Ifat From aspiers at suse.com Tue Sep 4 09:40:42 2018 From: aspiers at suse.com (Adam Spiers) Date: Tue, 4 Sep 2018 10:40:42 +0100 Subject: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops In-Reply-To: References: <20180813165615.m7yltwe5zqkbjdx6@pacific.linksys.moosehall> <20180903171611.xcp3tlcg56vlugcg@pacific.linksys.moosehall> Message-ID: <20180904094042.4ilt2ihfinh5gjkt@pacific.linksys.moosehall> Ifat Afek wrote: > >On 2018-09-03, 8:16 PM, "Adam Spiers" wrote: > > An article in SuperUser is a great idea, and it's really funny (and > good!) that you suggested that, because Lauren and Allison already > suggested that to me, and I made an initial plan which includes asking > you to help write the material ;-) > > https://etherpad.openstack.org/p/HA-self-healing-article > > I would also like to invite other PTLs working in the self-healing > space (e.g. Ifat, Eric) to contribute, and anyone else who thinks they > could help (e.g. Nemat, Andrew B). I've added this and a few other > things to the agenda for Denver: > > https://etherpad.openstack.org/p/self-healing-sig-stein-ptg > > >Hi Adam, Rico, > >Great initiative! >Unfortunately, I will not attend the PTG this time. But I’ll be happy to help with the article or whatever else is needed. Sorry to miss you but thanks a lot for the offer of help! We'll be in touch when this initiative picks up momentum :-) From zhipengh512 at gmail.com Fri Sep 7 03:02:33 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Fri, 7 Sep 2018 11:02:33 +0800 Subject: [Openstack-sigs] [publiccloud-wg]PTG session prep Message-ID: Hi Folks, For those of you are interested in the openstack public cloud, please take a look at the etherpad for our agenda[0] , you are more than welcomed to suggest/add new topics ! [0] https://etherpad.openstack.org/p/publiccloud-wg-stein-ptg -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Fri Sep 7 21:01:09 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Fri, 7 Sep 2018 14:01:09 -0700 Subject: [Openstack-sigs] [First Contact] PTG Planning & Meeting Cancelled Message-ID: Hello Everyone! I can't believe the PTG is only a few days away! We have our etherpad of discussion topics here[1]. If there is anything else we need to talk about, please add it! We will be meeting Tuesday Morning in Blanca Peak. I don't think we will fill the whole day, so it will be used for StoryBoard meetings in the afternoon. If there are remote people interested in joining, please let me know and I can set something up. Also, if Tuesday morning doesn't work for people perhaps we can schedule a recap for later in the week. Also, the Wednesday meeting will be cancelled because many of us will be meeting in person :) -Kendall (diablo_rojo) [1]https://etherpad.openstack.org/p/FC_SIG_ptg_stein -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekcs.openstack at gmail.com Tue Sep 11 22:40:52 2018 From: ekcs.openstack at gmail.com (Eric K) Date: Tue, 11 Sep 2018 15:40:52 -0700 Subject: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops In-Reply-To: References: <20180813165615.m7yltwe5zqkbjdx6@pacific.linksys.moosehall> Message-ID: Sorry quite last minute considering the UC sessions tmr. I just added a candidate question to the etherpad which may provide more actionable responses for us: https://etherpad.openstack.org/p/self-healing-user-survey-questions From: Rico Lin Reply-To: Date: Thursday, August 30, 2018 at 9:57 AM To: Subject: Re: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops > > > On Tue, Aug 14, 2018 at 12:56 AM Adam Spiers wrote: >> > >> > This sounds like a great idea to me! I've submitted a story for this: >> > >> > https://storyboard.openstack.org/#!/story/2003423 >> > >> > and set up an etherpad for brainstorming: >> > >> > https://etherpad.openstack.org/p/self-healing-user-survey-questions >> > > I think those two questions are quite great. Just put some extra idea in that. > Also, I have proposed you're etherpad under UC discussions in PTG > https://etherpad.openstack.org/p/uc-stein-ptg > Unfortunately, that's when UC discuss about next survey, so appears we have to > settle down with certain questions before our meeting in PTG. > For me, the current version looks nice. If anyone like to suggest more, feel > free to do so >> > >> > >> > This sounds reasonable. We already link to the StoryBoard from the >> > SIG portal wiki page: >> > >> > >> https://wiki.openstack.org/wiki/Self-healing_SIG#Community_Infrastructure_.2F >> _Resources >> > >> > but yes we could also proactively announce this in places which would >> > reach more users and operators, inviting them to submit stories. Can >> > you suggest how best to do this? We could email the openstack and >> > openstack-operators lists, although TBH I have done this several times >> > in the past and not gotten much engagement - probably because both >> > lists are very high traffic. >> > > I guess we should keep trying to propose in ML. There're two more places I > think we can try on. As we might be able to have our own page in User survey, > I think we're allow to put more message to point a place(our git repo, or an > etherpad) for Users who like to add more information during that survey. The > second place is SuperUser MagZ. If we can come's up with an article (which we > can plan in PTG if we like to have one) to introduce our plan, works, and > needs. I think Super User will willing to help us post that article out. If we > got some article, we can Use official OpenStack social media (FB, Twitter, > etc) to broadcast that information. >> > >> > >> > I love this idea, and yes the self-healing-sig git repository could >> > absolutely be the home for this gating code. I suspect that a big >> > part of the challenge will be to simulate failures in order to test >> > the self-healing functionality. In fact we already have a story >> > regarding automated testing: >> > >> > https://storyboard.openstack.org/#!/story/2002129 >> > >> > although that is much more ambitious in scope, i.e. building a >> > complete framework which could support testing of many different >> > self-healing scenarios. I have some documentation on the Eris project >> > which I am planning to upload to the repository on this. >> > >> > However your proposal sounds less ambitious and more likely to be >> > achievable in the short-term, so I'd love to learn more about how you >> > think this might work (unfortunately I don't know much about Tempest >> > internals yet). > > Since the git just updated with more official project format, we can add > Zuul.yaml to define our periodic job I think we already got a lot of places to > add tempest test(I think we might be able to use heat-tempest-plugin too), so > we shouldn't need to build our own tempest repo >> > >> > Thanks a lot for your ideas! They are great - please keep them coming ;-) >> > >> > Adam > _______________________________________________ openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Wed Sep 12 09:03:37 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 12 Sep 2018 10:03:37 +0100 Subject: [Openstack-sigs] [scientific] IRC Meeting today 1100 UTC - PTG proceedings, conference meetups Message-ID: <6334A8AA-2D9D-4C2E-B19E-D48A350C0FCF@telfer.org> Hi All - We have a Scientific SIG IRC meeting today in channel #openstack-meeting at 1100 UTC (about 2 hours time). Everyone is welcome. Today we can cover the SIG session at the PTG, and planning for SIG participating in upcoming conferences. If anyone has other items to add to the agenda, please get in touch (or add them to the agenda on the wiki). The full agenda is at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_September_12th_2018 Cheers, Stig -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Wed Sep 12 15:47:27 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Sep 2018 09:47:27 -0600 Subject: [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials) Message-ID: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> Rather than take a tangent on Kristi's candidacy thread [1], I'll bring this up separately. Kristi said: "Ultimately, this list isn’t exclusive and I’d love to hear your and other people's opinions about what you think the I should focus on." Well since you asked... Some feedback I gave to the public cloud work group yesterday was to get their RFE/bug list ranked from the operator community (because some of the requests are not exclusive to public cloud), and then put pressure on the TC to help project manage the delivery of the top issue. I would like all of the SIGs to do this. The upgrades SIG should rank and socialize their #1 issue that needs attention from the developer community - maybe that's better upgrade CI testing for deployment projects, maybe it's getting the pre-upgrade checks goal done for Stein. The UC should also be doing this; maybe that's the UC saying, "we need help on closing feature gaps in openstack client and/or the SDK". I don't want SIGs to bombard the developers with *all* of their requirements, but I want to get past *talking* about the *same* issues *every* time we get together. I want each group to say, "this is our top issue and we want developers to focus on it." For example, the extended maintenance resolution [2] was purely birthed from frustration about talking about LTS and stable branch EOL every time we get together. It's also the responsibility of the operator and user communities to weigh in on proposed release goals, but the TC should be actively trying to get feedback from those communities about proposed goals, because I bet operators and users don't care about mox removal [3]. I want to see the TC be more of a cross-project project management group, like a group of Ildikos and what she did between nova and cinder to get volume multi-attach done, which took persistent supervision to herd the cats and get it delivered. Lance is already trying to do this with unified limits. Doug is doing this with the python3 goal. I want my elected TC members to be pushing tangible technical deliverables forward. I don't find any value in the TC debating ad nauseam about visions and constellations and "what is openstack?". Scope will change over time depending on who is contributing to openstack, we should just accept this. And we need to realize that if we are failing to deliver value to operators and users, they aren't going to use openstack and then "what is openstack?" won't matter because no one will care. So I encourage all elected TC members to work directly with the various SIGs to figure out their top issue and then work on managing those deliverables across the community because the TC is particularly well suited to do so given the elected position. I realize political and bureaucratic "how should openstack deal with x?" things will come up, but those should not be the priority of the TC. So instead of philosophizing about things like, "should all compute agents be in a single service with a REST API" for hours and hours, every few months - immediately ask, "would doing that get us any closer to achieving top technical priority x?" Because if not, or it's so fuzzy in scope that no one sees the way forward, document a decision and then drop it. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html [2] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html -- Thanks, Matt From zhipengh512 at gmail.com Wed Sep 12 15:59:24 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Wed, 12 Sep 2018 09:59:24 -0600 Subject: [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> Message-ID: Well Public Cloud WG has prepared the ammo as you know and to discuss with TC on Friday :) A hundred percent with you on this matter. On Wed, Sep 12, 2018 at 9:47 AM Matt Riedemann wrote: > Rather than take a tangent on Kristi's candidacy thread [1], I'll bring > this up separately. > > Kristi said: > > "Ultimately, this list isn’t exclusive and I’d love to hear your and > other people's opinions about what you think the I should focus on." > > Well since you asked... > > Some feedback I gave to the public cloud work group yesterday was to get > their RFE/bug list ranked from the operator community (because some of > the requests are not exclusive to public cloud), and then put pressure > on the TC to help project manage the delivery of the top issue. I would > like all of the SIGs to do this. The upgrades SIG should rank and > socialize their #1 issue that needs attention from the developer > community - maybe that's better upgrade CI testing for deployment > projects, maybe it's getting the pre-upgrade checks goal done for Stein. > The UC should also be doing this; maybe that's the UC saying, "we need > help on closing feature gaps in openstack client and/or the SDK". I > don't want SIGs to bombard the developers with *all* of their > requirements, but I want to get past *talking* about the *same* issues > *every* time we get together. I want each group to say, "this is our top > issue and we want developers to focus on it." For example, the extended > maintenance resolution [2] was purely birthed from frustration about > talking about LTS and stable branch EOL every time we get together. It's > also the responsibility of the operator and user communities to weigh in > on proposed release goals, but the TC should be actively trying to get > feedback from those communities about proposed goals, because I bet > operators and users don't care about mox removal [3]. > > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > > So I encourage all elected TC members to work directly with the various > SIGs to figure out their top issue and then work on managing those > deliverables across the community because the TC is particularly well > suited to do so given the elected position. I realize political and > bureaucratic "how should openstack deal with x?" things will come up, > but those should not be the priority of the TC. So instead of > philosophizing about things like, "should all compute agents be in a > single service with a REST API" for hours and hours, every few months - > immediately ask, "would doing that get us any closer to achieving top > technical priority x?" Because if not, or it's so fuzzy in scope that no > one sees the way forward, document a decision and then drop it. > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html > [2] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html > [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html > > -- > > Thanks, > > Matt > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Sep 12 18:25:47 2018 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 12 Sep 2018 20:25:47 +0200 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> Message-ID: <03705d03-d986-285a-8b17-c2ae554ed11d@openstack.org> Matt Riedemann wrote: > [...] > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > [...] I agree that we generally need more of those cross-project champions, and generally TC members are in a good position to do that kind of work. The TC itself is also in a good position to "bless" those initiatives and give them some amount of priority (with our limited influence). I'm just a bit worried to limit that role to the elected TC members. If we say "it's the role of the TC to do cross-project PM in OpenStack" then we artificially limit the number of people who would sign up to do that kind of work. You mention Ildiko and Lance: they did that line of work without being elected. So I would definitely support having champions to drive SIG cross-project priorities, and use the TC both to support them and as a natural pool of champion candidates -- I would just avoid tying the role to the elected group? -- Thierry Carrez (ttx) From rico.lin.guanyu at gmail.com Wed Sep 12 20:34:51 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Wed, 12 Sep 2018 14:34:51 -0600 Subject: [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> Message-ID: I'm glad we have this request/letter I have raised the same discussion around PTG with TCs, PTLs, UCs (as many as I can find this week). Also on Ops-meetup, K8S-SIG, FC SIG session. And on Self-healing SIG's ML [1](the session is not started yet so as TC's session). I propose we expose SIGs/WGs and provide a single window (just like we have discussed in ML about integrating Mailing lists) for users and ops so if they got any issues/bugs/features they can have a more stride forward place to put their story in a single place so it's easier to go from story to multi-project tasks for each team to trace and work on. and other users/ops can easier to find similar issues. Which will also easier to trigger a cross-project meeting for some real scenarios. Also potentially cross-project gatting, and cycle goal cross projects. After asking opinions around, generally, the feedbacks are mostly good (there are some concerns, I will send more detail out later, once PTG is done). So in order to accomplish this task, we need to redefine project teams, SIGs and WGs's permission to make sure the flow from users/ops to developers and back to users/ops is clear. But first of all, we need to collect more feedback from all group (will do it after PTG or after sessions) will be super if TCs can go for this idea!! [1] http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html On Wed, Sep 12, 2018 at 9:47 AM Matt Riedemann wrote: > Rather than take a tangent on Kristi's candidacy thread [1], I'll bring > this up separately. > > Kristi said: > > "Ultimately, this list isn’t exclusive and I’d love to hear your and > other people's opinions about what you think the I should focus on." > > Well since you asked... > > Some feedback I gave to the public cloud work group yesterday was to get > their RFE/bug list ranked from the operator community (because some of > the requests are not exclusive to public cloud), and then put pressure > on the TC to help project manage the delivery of the top issue. I would > like all of the SIGs to do this. The upgrades SIG should rank and > socialize their #1 issue that needs attention from the developer > community - maybe that's better upgrade CI testing for deployment > projects, maybe it's getting the pre-upgrade checks goal done for Stein. > The UC should also be doing this; maybe that's the UC saying, "we need > help on closing feature gaps in openstack client and/or the SDK". I > don't want SIGs to bombard the developers with *all* of their > requirements, but I want to get past *talking* about the *same* issues > *every* time we get together. I want each group to say, "this is our top > issue and we want developers to focus on it." For example, the extended > maintenance resolution [2] was purely birthed from frustration about > talking about LTS and stable branch EOL every time we get together. It's > also the responsibility of the operator and user communities to weigh in > on proposed release goals, but the TC should be actively trying to get > feedback from those communities about proposed goals, because I bet > operators and users don't care about mox removal [3]. > > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > > So I encourage all elected TC members to work directly with the various > SIGs to figure out their top issue and then work on managing those > deliverables across the community because the TC is particularly well > suited to do so given the elected position. I realize political and > bureaucratic "how should openstack deal with x?" things will come up, > but those should not be the priority of the TC. So instead of > philosophizing about things like, "should all compute agents be in a > single service with a REST API" for hours and hours, every few months - > immediately ask, "would doing that get us any closer to achieving top > technical priority x?" Because if not, or it's so fuzzy in scope that no > one sees the way forward, document a decision and then drop it. > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html > [2] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html > [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html > > -- > > Thanks, > > Matt > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From davanum at gmail.com Wed Sep 12 21:41:45 2018 From: davanum at gmail.com (Davanum Srinivas) Date: Wed, 12 Sep 2018 15:41:45 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <03705d03-d986-285a-8b17-c2ae554ed11d@openstack.org> Message-ID: On Wed, Sep 12, 2018 at 3:30 PM Dan Smith wrote: > > I'm just a bit worried to limit that role to the elected TC members. If > > we say "it's the role of the TC to do cross-project PM in OpenStack" > > then we artificially limit the number of people who would sign up to do > > that kind of work. You mention Ildiko and Lance: they did that line of > > work without being elected. > > Why would saying that we _expect_ the TC members to do that work limit > such activities only to those that are on the TC? I would expect the TC > to take on the less-fun or often-neglected efforts that we all know are > needed but don't have an obvious champion or sponsor. > > I think we expect some amount of widely-focused technical or project > leadership from TC members, and certainly that expectation doesn't > prevent others from leading efforts (even in the areas of proposing TC > resolutions, etc) right? > +1 Dan! > --Dan > > __________________________________________________________________________ > 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 > -- Davanum Srinivas :: https://twitter.com/dims -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Sep 12 21:55:28 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 12 Sep 2018 21:55:28 +0000 Subject: [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> Message-ID: <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote: [...] > So I encourage all elected TC members to work directly with the > various SIGs to figure out their top issue and then work on > managing those deliverables across the community because the TC is > particularly well suited to do so given the elected position. [...] I almost agree with you. I think the OpenStack TC members should be actively engaged in recruiting and enabling interested people in the community to do those things, but I don't think such work should be solely the domain of the TC and would hate to give the impression that you must be on the TC to have such an impact. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From zhipengh512 at gmail.com Wed Sep 12 22:03:12 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Wed, 12 Sep 2018 16:03:12 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> Message-ID: On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley wrote: > On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote: > [...] > > So I encourage all elected TC members to work directly with the > > various SIGs to figure out their top issue and then work on > > managing those deliverables across the community because the TC is > > particularly well suited to do so given the elected position. > [...] > > I almost agree with you. I think the OpenStack TC members should be > actively engaged in recruiting and enabling interested people in the > community to do those things, but I don't think such work should be > solely the domain of the TC and would hate to give the impression > that you must be on the TC to have such an impact. > -- > Jeremy Stanley > Jeremy, this is not to say that one must be on the TC to have such an impact, it is that TC has the duty more than anyone else to get this specific cross-project goal done. I would even argue it is not the job description of TC to enable/recruit, but to just do it. -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Sep 12 22:14:17 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 12 Sep 2018 22:14:17 +0000 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> Message-ID: <20180912221417.hxmsq6smyaxvvyqo@yuggoth.org> On 2018-09-12 16:03:12 -0600 (-0600), Zhipeng Huang wrote: > On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley wrote: > > On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote: > > [...] > > > So I encourage all elected TC members to work directly with the > > > various SIGs to figure out their top issue and then work on > > > managing those deliverables across the community because the TC is > > > particularly well suited to do so given the elected position. > > [...] > > > > I almost agree with you. I think the OpenStack TC members should be > > actively engaged in recruiting and enabling interested people in the > > community to do those things, but I don't think such work should be > > solely the domain of the TC and would hate to give the impression > > that you must be on the TC to have such an impact. > > Jeremy, this is not to say that one must be on the TC to have such an > impact, it is that TC has the duty more than anyone else to get this > specific cross-project goal done. I would even argue it is not the job > description of TC to enable/recruit, but to just do it. I think Doug's work leading the Python 3 First effort is a great example. He has helped find and enable several other goal champions to collaborate on this. I appreciate the variety of other things Doug already does with his available time and would rather he not stop doing those things to spend all his time acting as a project manager. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From mriedemos at gmail.com Wed Sep 12 23:00:04 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Sep 2018 17:00:04 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <03705d03-d986-285a-8b17-c2ae554ed11d@openstack.org> Message-ID: On 9/12/2018 3:30 PM, Dan Smith wrote: >> I'm just a bit worried to limit that role to the elected TC members. If >> we say "it's the role of the TC to do cross-project PM in OpenStack" >> then we artificially limit the number of people who would sign up to do >> that kind of work. You mention Ildiko and Lance: they did that line of >> work without being elected. > Why would saying that we_expect_ the TC members to do that work limit > such activities only to those that are on the TC? I would expect the TC > to take on the less-fun or often-neglected efforts that we all know are > needed but don't have an obvious champion or sponsor. > > I think we expect some amount of widely-focused technical or project > leadership from TC members, and certainly that expectation doesn't > prevent others from leading efforts (even in the areas of proposing TC > resolutions, etc) right? Absolutely. I'm not saying the cross-project project management should be restricted to or solely the responsibility of the TC. It's obvious there are people outside of the TC that have already been doing this - and no it's not always elected PTLs either. What I want is elected TC members to prioritize driving technical deliverables to completion based on ranked input from operators/users/SIGs over philosophical debates and politics/bureaucracy and help to complete the technical tasks if possible. -- Thanks, Matt From mriedemos at gmail.com Wed Sep 12 23:01:42 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Sep 2018 17:01:42 -0600 Subject: [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> Message-ID: <970b673d-be91-f763-86a1-31f5e9ce52a3@gmail.com> On 9/12/2018 3:55 PM, Jeremy Stanley wrote: > I almost agree with you. I think the OpenStack TC members should be > actively engaged in recruiting and enabling interested people in the > community to do those things, but I don't think such work should be > solely the domain of the TC and would hate to give the impression > that you must be on the TC to have such an impact. See my reply to Thierry. This isn't what I'm saying. But I expect the elected TC members to be *much* more *directly* involved in managing and driving hard cross-project technical deliverables. -- Thanks, Matt From mriedemos at gmail.com Wed Sep 12 23:03:10 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Sep 2018 17:03:10 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <20180912221417.hxmsq6smyaxvvyqo@yuggoth.org> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> <20180912221417.hxmsq6smyaxvvyqo@yuggoth.org> Message-ID: On 9/12/2018 4:14 PM, Jeremy Stanley wrote: > I think Doug's work leading the Python 3 First effort is a great > example. He has helped find and enable several other goal champions > to collaborate on this. I appreciate the variety of other things > Doug already does with his available time and would rather he not > stop doing those things to spend all his time acting as a project > manager. I specifically called out what Doug is doing as an example of things I want to see the TC doing. I want more/all TC members doing that. -- Thanks, Matt From fungi at yuggoth.org Wed Sep 12 23:06:54 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 12 Sep 2018 23:06:54 +0000 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> <20180912221417.hxmsq6smyaxvvyqo@yuggoth.org> Message-ID: <20180912230654.5ldabmmtxlusrxep@yuggoth.org> On 2018-09-12 17:03:10 -0600 (-0600), Matt Riedemann wrote: > On 9/12/2018 4:14 PM, Jeremy Stanley wrote: > > I think Doug's work leading the Python 3 First effort is a great > > example. He has helped find and enable several other goal champions > > to collaborate on this. I appreciate the variety of other things > > Doug already does with his available time and would rather he not > > stop doing those things to spend all his time acting as a project > > manager. > > I specifically called out what Doug is doing as an example of > things I want to see the TC doing. I want more/all TC members > doing that. With that I was replying to Zhipeng Huang's message which you have trimmed above, specifically countering the assertion that recruiting others to help with these efforts is a waste of time and that TC members should simply do all the work themselves instead. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From mriedemos at gmail.com Wed Sep 12 23:50:30 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Sep 2018 17:50:30 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <20180912231338.f2v5so7jelg3am7y@yuggoth.org> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> <20180912231338.f2v5so7jelg3am7y@yuggoth.org> Message-ID: <9ed16b6f-bc3a-4de3-bbbd-db62ac1ec32d@gmail.com> On 9/12/2018 5:13 PM, Jeremy Stanley wrote: > Sure, and I'm saying that instead I think the influence of TC > members_can_ be more valuable in finding and helping additional > people to do these things rather than doing it all themselves, and > it's not just about the limited number of available hours in the day > for one person versus many. The successes goal champions experience, > the connections they make and the elevated reputation they gain > throughout the community during the process of these efforts builds > new leaders for us all. Again, I'm not saying TC members should be doing all of the work themselves. That's not realistic, especially when critical parts of any major effort are going to involve developers from projects on which none of the TC members are active contributors (e.g. nova). I want to see TC members herd cats, for lack of a better analogy, and help out technically (with code) where possible. Given the repeated mention of how the "help wanted" list continues to not draw in contributors, I think the recruiting role of the TC should take a back seat to actually stepping in and helping work on those items directly. For example, Sean McGinnis is taking an active role in the operators guide and other related docs that continue to be discussed at every face to face event since those docs were dropped from openstack-manuals (in Pike). I think it's fair to say that the people generally elected to the TC are those most visible in the community (it's a popularity contest) and those people are generally the most visible because they have the luxury of working upstream the majority of their time. As such, it's their duty to oversee and spend time working on the hard cross-project technical deliverables that operators and users are asking for, rather than think of an infinite number of ways to try and draw *others* to help work on those gaps. As I think it's the role of a PTL within a given project to have a finger on the pulse of the technical priorities of that project and manage the developers involved (of which the PTL certainly may be one), it's the role of the TC to do the same across openstack as a whole. If a PTL doesn't have the time or willingness to do that within their project, they shouldn't be the PTL. The same goes for TC members IMO. -- Thanks, Matt From mriedemos at gmail.com Wed Sep 12 23:52:06 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 12 Sep 2018 17:52:06 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> <20180912231338.f2v5so7jelg3am7y@yuggoth.org> Message-ID: <6e3b031f-c450-22fd-391c-c71c8ad827cd@gmail.com> On 9/12/2018 5:32 PM, Melvin Hillsman wrote: > We basically spent the day focusing on two things specific to what you > bring up and are in agreement with you regarding action not just talk > around feedback and outreach. [1] > We wiped the agenda clean, discussed our availability (set reasonable > expectations), and revisited how we can be more diligent and successful > around these two principles which target your first comment, "...get > their RFE/bug list ranked from the operator community (because some of > the requests are not exclusive to public cloud), and then put pressure > on the TC to help project manage the delivery of the top issue..." > > I will not get into much detail because again this response is specific > to a portion of your email so in keeping with feedback and outreach the > UC is making it a point to be intentional. We have already got action > items [2] which target the concern you raise. We have agreed to hold > each other accountable and adjusted our meeting structure to facilitate > being successful. > > Not that the UC (elected members) are the only ones who can do this but > we believe it is our responsibility to; regardless of what anyone else > does. The UC is also expected to enlist others and hopefully through our > efforts others are encouraged participate and enlist others. > > [1] https://etherpad.openstack.org/p/uc-stein-ptg > [2] https://etherpad.openstack.org/p/UC-Election-Qualifications Awesome, thank you Melvin and others on the UC. -- Thanks, Matt From mrhillsman at gmail.com Thu Sep 13 02:08:10 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Wed, 12 Sep 2018 20:08:10 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <6e3b031f-c450-22fd-391c-c71c8ad827cd@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> <20180912231338.f2v5so7jelg3am7y@yuggoth.org> <6e3b031f-c450-22fd-391c-c71c8ad827cd@gmail.com> Message-ID: You're welcome! -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 On Wed, Sep 12, 2018, 5:52 PM Matt Riedemann wrote: > On 9/12/2018 5:32 PM, Melvin Hillsman wrote: > > We basically spent the day focusing on two things specific to what you > > bring up and are in agreement with you regarding action not just talk > > around feedback and outreach. [1] > > We wiped the agenda clean, discussed our availability (set reasonable > > expectations), and revisited how we can be more diligent and successful > > around these two principles which target your first comment, "...get > > their RFE/bug list ranked from the operator community (because some of > > the requests are not exclusive to public cloud), and then put pressure > > on the TC to help project manage the delivery of the top issue..." > > > > I will not get into much detail because again this response is specific > > to a portion of your email so in keeping with feedback and outreach the > > UC is making it a point to be intentional. We have already got action > > items [2] which target the concern you raise. We have agreed to hold > > each other accountable and adjusted our meeting structure to facilitate > > being successful. > > > > Not that the UC (elected members) are the only ones who can do this but > > we believe it is our responsibility to; regardless of what anyone else > > does. The UC is also expected to enlist others and hopefully through our > > efforts others are encouraged participate and enlist others. > > > > [1] https://etherpad.openstack.org/p/uc-stein-ptg > > [2] https://etherpad.openstack.org/p/UC-Election-Qualifications > > Awesome, thank you Melvin and others on the UC. > > -- > > Thanks, > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Sep 13 14:19:21 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 13 Sep 2018 23:19:21 +0900 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> Message-ID: <165d34cf822.b5f4da7688669.7192778226044204749@ghanshyammann.com> ---- On Thu, 13 Sep 2018 00:47:27 +0900 Matt Riedemann wrote ---- > Rather than take a tangent on Kristi's candidacy thread [1], I'll bring > this up separately. > > Kristi said: > > "Ultimately, this list isn’t exclusive and I’d love to hear your and > other people's opinions about what you think the I should focus on." > > Well since you asked... > > Some feedback I gave to the public cloud work group yesterday was to get > their RFE/bug list ranked from the operator community (because some of > the requests are not exclusive to public cloud), and then put pressure > on the TC to help project manage the delivery of the top issue. I would > like all of the SIGs to do this. The upgrades SIG should rank and > socialize their #1 issue that needs attention from the developer > community - maybe that's better upgrade CI testing for deployment > projects, maybe it's getting the pre-upgrade checks goal done for Stein. > The UC should also be doing this; maybe that's the UC saying, "we need > help on closing feature gaps in openstack client and/or the SDK". I > don't want SIGs to bombard the developers with *all* of their > requirements, but I want to get past *talking* about the *same* issues > *every* time we get together. I want each group to say, "this is our top > issue and we want developers to focus on it." For example, the extended > maintenance resolution [2] was purely birthed from frustration about > talking about LTS and stable branch EOL every time we get together. It's > also the responsibility of the operator and user communities to weigh in > on proposed release goals, but the TC should be actively trying to get > feedback from those communities about proposed goals, because I bet > operators and users don't care about mox removal [3]. I agree on this and i feel this is real value we can add with current situation where contributors are less in almost all of the projects. When we set goal for any cycle, we should have user/operator/SIG weightage on priority in selection checklist and categorize the goal into respective category/tag something like "user-oriented" or "coding-oriented"(only developer/maintaining code benefits). And then we concentrate more on first category and leave second one more on project team. Project team further can plan the second catagory items as per their bandwidth and priority. I am not saying code/developer oriented goals should not be initiated by TC but those should be on low priority list kind of. -gmann > > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > > So I encourage all elected TC members to work directly with the various > SIGs to figure out their top issue and then work on managing those > deliverables across the community because the TC is particularly well > suited to do so given the elected position. I realize political and > bureaucratic "how should openstack deal with x?" things will come up, > but those should not be the priority of the TC. So instead of > philosophizing about things like, "should all compute agents be in a > single service with a REST API" for hours and hours, every few months - > immediately ask, "would doing that get us any closer to achieving top > technical priority x?" Because if not, or it's so fuzzy in scope that no > one sees the way forward, document a decision and then drop it. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html > [2] > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html > [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html > > -- > > Thanks, > > Matt > > __________________________________________________________________________ > 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 > From Kevin.Fox at pnnl.gov Thu Sep 13 16:14:22 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Thu, 13 Sep 2018 16:14:22 +0000 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <03705d03-d986-285a-8b17-c2ae554ed11d@openstack.org> , Message-ID: <1A3C52DFCD06494D8528644858247BF01C19A62A@EX10MBOX03.pnnl.gov> How about stated this way, Its the tc's responsibility to get it done. Either by delegating the activity, or by doing it themselves. But either way, it needs to get done. Its a ball that has been dropped too much in OpenStacks history. If no one is ultimately responsible, balls will keep getting dropped. Thanks, Kevin ________________________________________ From: Matt Riedemann [mriedemos at gmail.com] Sent: Wednesday, September 12, 2018 4:00 PM To: Dan Smith; Thierry Carrez Cc: OpenStack Development Mailing List (not for usage questions); openstack-sigs at lists.openstack.org; openstack-operators at lists.openstack.org Subject: Re: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) On 9/12/2018 3:30 PM, Dan Smith wrote: >> I'm just a bit worried to limit that role to the elected TC members. If >> we say "it's the role of the TC to do cross-project PM in OpenStack" >> then we artificially limit the number of people who would sign up to do >> that kind of work. You mention Ildiko and Lance: they did that line of >> work without being elected. > Why would saying that we_expect_ the TC members to do that work limit > such activities only to those that are on the TC? I would expect the TC > to take on the less-fun or often-neglected efforts that we all know are > needed but don't have an obvious champion or sponsor. > > I think we expect some amount of widely-focused technical or project > leadership from TC members, and certainly that expectation doesn't > prevent others from leading efforts (even in the areas of proposing TC > resolutions, etc) right? Absolutely. I'm not saying the cross-project project management should be restricted to or solely the responsibility of the TC. It's obvious there are people outside of the TC that have already been doing this - and no it's not always elected PTLs either. What I want is elected TC members to prioritize driving technical deliverables to completion based on ranked input from operators/users/SIGs over philosophical debates and politics/bureaucracy and help to complete the technical tasks if possible. -- Thanks, Matt _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From zhipengh512 at gmail.com Thu Sep 13 16:38:31 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 13 Sep 2018 10:38:31 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C19A62A@EX10MBOX03.pnnl.gov> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <03705d03-d986-285a-8b17-c2ae554ed11d@openstack.org> <1A3C52DFCD06494D8528644858247BF01C19A62A@EX10MBOX03.pnnl.gov> Message-ID: On Thu, Sep 13, 2018 at 10:15 AM Fox, Kevin M wrote: > How about stated this way, > Its the tc's responsibility to get it done. Either by delegating the > activity, or by doing it themselves. But either way, it needs to get done. > Its a ball that has been dropped too much in OpenStacks history. If no one > is ultimately responsible, balls will keep getting dropped. > > Thanks, > Kevin > +1 Kevin -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel at cassi.ba Thu Sep 13 19:58:28 2018 From: samuel at cassi.ba (Samuel Cassiba) Date: Thu, 13 Sep 2018 12:58:28 -0700 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <1A3C52DFCD06494D8528644858247BF01C19A62A@EX10MBOX03.pnnl.gov> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <03705d03-d986-285a-8b17-c2ae554ed11d@openstack.org> <1A3C52DFCD06494D8528644858247BF01C19A62A@EX10MBOX03.pnnl.gov> Message-ID: On Thu, Sep 13, 2018 at 9:14 AM, Fox, Kevin M wrote: > How about stated this way, > Its the tc's responsibility to get it done. Either by delegating the activity, or by doing it themselves. But either way, it needs to get done. Its a ball that has been dropped too much in OpenStacks history. If no one is ultimately responsible, balls will keep getting dropped. > > Thanks, > Kevin I see the role of TC the same way I do the PTL hat, but on more of a meta scale: too much direct involvement can stifle things. On the inverse, not enough involvement can result in people saying one's work is legacy, to be nice, or dead, at worst. All too often, we humans get hung up on the definitions of words, sometimes to the point of inaction. It seems only when someone says sod it do things move forward, regardless of anyone's level of involvement. I look to TC as the group that sets the tone, de facto product owners, to paraphrase from OpenStack's native tongue. The more hands-on an individual is with the output, TC or not, a perception arises that a given effort needs only that person's attention; thereby, setting a much different narrative than might otherwise be immediately noticed or desired. The place I see TC is making sure that there is meaningful progress on agreed-upon efforts, however that needs to exist. Sometimes that might be recruiting, but I don't see browbeating social media to be particularly valuable from an individual standpoint. Sometimes that would be collaborating through code, if it comes down to it. From an overarching perspective, I view hands-on coding by TC to be somewhat of a last resort effort due to individual commitments. Perceptions surrounding actions, like the oft used 'stepping up' phrase, creates an effect where people do not carve out enough time to effect change, becoming too busy, repeat ad infinitum. Best, Samuel From fungi at yuggoth.org Thu Sep 13 20:44:29 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 13 Sep 2018 20:44:29 +0000 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <9ed16b6f-bc3a-4de3-bbbd-db62ac1ec32d@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> <20180912231338.f2v5so7jelg3am7y@yuggoth.org> <9ed16b6f-bc3a-4de3-bbbd-db62ac1ec32d@gmail.com> Message-ID: <20180913204428.bydeuacugcydpfxj@yuggoth.org> On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote: [...] > Again, I'm not saying TC members should be doing all of the work > themselves. That's not realistic, especially when critical parts > of any major effort are going to involve developers from projects > on which none of the TC members are active contributors (e.g. > nova). I want to see TC members herd cats, for lack of a better > analogy, and help out technically (with code) where possible. I can respect that. I think that OpenStack made a mistake in naming its community management governance body the "technical" committee. I do agree that having TC members engage in activities with tangible outcomes is preferable, and that the needs of the users of its software should weigh heavily in prioritization decisions, but those are not the only problems our community faces nor is it as if there are no other responsibilities associated with being a TC member. > Given the repeated mention of how the "help wanted" list continues > to not draw in contributors, I think the recruiting role of the TC > should take a back seat to actually stepping in and helping work > on those items directly. For example, Sean McGinnis is taking an > active role in the operators guide and other related docs that > continue to be discussed at every face to face event since those > docs were dropped from openstack-manuals (in Pike). I completely agree that the help wanted list hasn't worked out well in practice. It was based on requests from the board of directors to provide some means of communicating to their business-focused constituency where resources would be most useful to the project. We've had a subsequent request to reorient it to be more like a set of job descriptions along with clearer business use cases explaining the benefit to them of contributing to these efforts. In my opinion it's very much the responsibility of the TC to find ways to accomplish these sorts of things as well. > I think it's fair to say that the people generally elected to the > TC are those most visible in the community (it's a popularity > contest) and those people are generally the most visible because > they have the luxury of working upstream the majority of their > time. As such, it's their duty to oversee and spend time working > on the hard cross-project technical deliverables that operators > and users are asking for, rather than think of an infinite number > of ways to try and draw *others* to help work on those gaps. But not everyone who is funded for full-time involvement with the community is necessarily "visible" in ways that make them electable. Higher-profile involvement in such activities over time is what gets them the visibility to be more easily elected to governance positions via "popularity contest" mechanics. > As I think it's the role of a PTL within a given project to have a > finger on the pulse of the technical priorities of that project > and manage the developers involved (of which the PTL certainly may > be one), it's the role of the TC to do the same across openstack > as a whole. If a PTL doesn't have the time or willingness to do > that within their project, they shouldn't be the PTL. The same > goes for TC members IMO. Completely agree, I think we might just disagree on where to strike the balance of purely technical priorities for the TC (as I personally think the TC is somewhat incorrectly named). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From tony at bakeyournoodle.com Fri Sep 14 07:36:49 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 14 Sep 2018 17:36:49 +1000 Subject: [Openstack-sigs] [stable] (ex) PTL on vacation Message-ID: <20180914073649.GA23273@thor.bakeyournoodle.com> Hi All, As Stable is no longer a project, I'm no longer a PTL so I don't really need to do this but ... I'm going on vacation for 3'ish weeks. I do plan on checking my email from time-to-time but really if anything comes up that needs urgent attention you'll need to ping stable-maint-core. I'm not fussy about my open changes so if they need fixing and you'd like them merged while I'm out feel free to upload your own revision. Have fun, I know I will ;D Yours Tony. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From davanum at gmail.com Fri Sep 14 14:45:05 2018 From: davanum at gmail.com (Davanum Srinivas) Date: Fri, 14 Sep 2018 08:45:05 -0600 Subject: [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <20180913204428.bydeuacugcydpfxj@yuggoth.org> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> <20180912215528.kpkxrg7ifaagoyvy@yuggoth.org> <20180912231338.f2v5so7jelg3am7y@yuggoth.org> <9ed16b6f-bc3a-4de3-bbbd-db62ac1ec32d@gmail.com> <20180913204428.bydeuacugcydpfxj@yuggoth.org> Message-ID: Folks, Sorry for the top post - Those of you that are still at PTG, please feel free to drop in to the Clear Creek room today. Thanks, Dims On Thu, Sep 13, 2018 at 2:44 PM Jeremy Stanley wrote: > On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote: > [...] > > Again, I'm not saying TC members should be doing all of the work > > themselves. That's not realistic, especially when critical parts > > of any major effort are going to involve developers from projects > > on which none of the TC members are active contributors (e.g. > > nova). I want to see TC members herd cats, for lack of a better > > analogy, and help out technically (with code) where possible. > > I can respect that. I think that OpenStack made a mistake in naming > its community management governance body the "technical" committee. > I do agree that having TC members engage in activities with tangible > outcomes is preferable, and that the needs of the users of its > software should weigh heavily in prioritization decisions, but those > are not the only problems our community faces nor is it as if there > are no other responsibilities associated with being a TC member. > > > Given the repeated mention of how the "help wanted" list continues > > to not draw in contributors, I think the recruiting role of the TC > > should take a back seat to actually stepping in and helping work > > on those items directly. For example, Sean McGinnis is taking an > > active role in the operators guide and other related docs that > > continue to be discussed at every face to face event since those > > docs were dropped from openstack-manuals (in Pike). > > I completely agree that the help wanted list hasn't worked out well > in practice. It was based on requests from the board of directors to > provide some means of communicating to their business-focused > constituency where resources would be most useful to the project. > We've had a subsequent request to reorient it to be more like a set > of job descriptions along with clearer business use cases explaining > the benefit to them of contributing to these efforts. In my opinion > it's very much the responsibility of the TC to find ways to > accomplish these sorts of things as well. > > > I think it's fair to say that the people generally elected to the > > TC are those most visible in the community (it's a popularity > > contest) and those people are generally the most visible because > > they have the luxury of working upstream the majority of their > > time. As such, it's their duty to oversee and spend time working > > on the hard cross-project technical deliverables that operators > > and users are asking for, rather than think of an infinite number > > of ways to try and draw *others* to help work on those gaps. > > But not everyone who is funded for full-time involvement with the > community is necessarily "visible" in ways that make them electable. > Higher-profile involvement in such activities over time is what gets > them the visibility to be more easily elected to governance > positions via "popularity contest" mechanics. > > > As I think it's the role of a PTL within a given project to have a > > finger on the pulse of the technical priorities of that project > > and manage the developers involved (of which the PTL certainly may > > be one), it's the role of the TC to do the same across openstack > > as a whole. If a PTL doesn't have the time or willingness to do > > that within their project, they shouldn't be the PTL. The same > > goes for TC members IMO. > > Completely agree, I think we might just disagree on where to strike > the balance of purely technical priorities for the TC (as I > personally think the TC is somewhat incorrectly named). > -- > Jeremy Stanley > __________________________________________________________________________ > 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 > -- Davanum Srinivas :: https://twitter.com/dims -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Fri Sep 14 17:26:06 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Fri, 14 Sep 2018 11:26:06 -0600 Subject: [Openstack-sigs] [PTG] Stein Team Photo Files Message-ID: Hello! Here are the photos we took this week of various teams :) https://www.dropbox.com/sh/2pmvfkstudih2wf/AAAGg7c0bYZcWQwKDOKiSwR7a?dl=0 Enjoy! -the Kendalls (diablo_rojo & wendallkaters) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengh512 at gmail.com Fri Sep 14 17:49:40 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Fri, 14 Sep 2018 11:49:40 -0600 Subject: [Openstack-sigs] [tc]Global Reachout Proposal Message-ID: Hi all, Follow up the diversity discussion we had in the tc session this morning [0], I've proposed a resolution on facilitating technical community in large to engage in global reachout for OpenStack more efficiently. Your feedbacks are welcomed. Whether this should be a new resolution or not at the end of the day, this is a conversation worthy to have. [0] https://review.openstack.org/602697 -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From rico.lin.guanyu at gmail.com Fri Sep 14 21:57:22 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Fri, 14 Sep 2018 15:57:22 -0600 Subject: [Openstack-sigs] [Openstack-operators][openstack-dev][all]Expose SIGs/WGs as single window for Users/Ops scenario Message-ID: The Idea has been raising around (from me or from Matt's ML), so I would like to give people more update on this (in terms of what I have been raising, what people have been feedbacks, and what init idea I can collect or I have as actions. *Why are we doing this?* The basic concept for this is to allow users/ops get a single window for important scenario/user cases or issues (here's an example [1])into traceable tasks in single story/place and ask developers be responsible (by changing the mission of government policy) to co-work on that task. SIGs/WGs are so desired to get feedbacks or use cases, so as to project teams (not gonna speak for all projects/SIGs/WGs but we like to collect for more idea for sure). And the project team got a central place to develop for specific user requirements (Edge, NFV, Self-healing, K8s). One more idea on this is that we can also use SIGs and WGs as a place for cross-project docs and those documents can be some more general information on how a user can plan for that area (again Edge, NFV, Self-healing, K8s). There also needs clear information to Users/Ops about what's the dependency cross projects which involved. Also, a potential way to expose more projects. From this step, we can plan to cross-project gating ( in projects gate or periodic) implementation *So what's triggering and feedback:* - This idea has been raising as a topic in K8S SIG, Self-healing SIG session. Feedback from K8s-sig and Self-healing-sig are generally looking forward to this. SIGs appears are desired to get use cases and user issues (I didn't so through this idea to rest SIGs/WGs yet, but place leave feedback if you're in that group). Most because this can value up SIGs/WGs on what they're interesting on. - This idea has been raising as a topic in Ops-meetup session Most of ops think it will be super if actually anyone willing to handle their own issues. The concerns about this are that we have to make some structure or guidelines to avoid a crazy number of useless issues (maybe like setup template for issues). Another feedback from an operator is that he concerns about ops should just try to go through everything in detail by themselves and contact to teams by themselves. IMO it depends on teams to set template and say you must have some specific information or even figure out which project should be in charge of which failed. - This idea has been raising as a topic in TC session Public cloud WGs also got this idea as well (and they done a good job!), appears it's a very preferred way for them. What happens to them is public cloud WG collect bunch number of use cases, but would like to see immediate actions or a traceable way to keep tracing those task. Doug: It might be hard to push developers to SIGs/WGs, but SIGs/WGs can always raise the cross-project forum. Also, it's important to let people know that who they can talk to. Melvin: Make it easier for everyone, and give a visibility. How can we possible to make one thing done is very important. Thierry: Have a way to expose the top priority which is important for OpenStack. - Also, raise to some PTLs and UCs. Generally good, Amy (super cute UC member) do ask the concern about there are manual works to bind tasks to cross bug tracing platform (like if you like to create a story in Self-healing SIG, and said it's relative to Heat, and Neutron. you create a task for Heat in that story, but you need to create a launchpad bug and link it to that story.). That issue might in now still need to be manually done, but what we might able to change is to consider migrate most of the relative teams to a single channel in long-term. I didn't get the chance to reach most of PTLs but do hope this is the place PTLs can also share their feedbacks. - There are ML in Self-healing-sig [2] not like a lot of feedback to this ML, but generally looks good *What are the actions we can do right away:* - Please give feedback to us - Give a forum for this topic for all to discuss this (I already add a brainstorm in TC etherpad, but it's across projects, UCs, TCs, WGs, SIGs). - Set up a cross-committee discuss for restructuring missions to make sure teams are responsible for hep on development, SIGs/WGs are responsible to trace task as story level and help to trigger cross-project discussion, and operators are responsible to follow the structure to send issues and provide valuable information. - We can also do an experiment on try on SIGs/WGs who and the relative projects are willing to join this for a while and see how the outcomes and adjust on them. - Can we set cross-projects as a goal for a group of projects instead of only community goal? - Also if this is a nice idea, we can have a guideline for SIGs/WGs to like suggest how they can have a cross-project gate, have a way to let users/ops to file story/issue in a format that is useful, or how to trigger the attention from other projects to join this. These are what I got from PTG, but let's start from here together and scratch what's done shall we!! P.S. Sorry about the bad writing, but have to catch a flight. [1] https://storyboard.openstack.org/#!/story/2002684 [2] http://lists.openstack.org/pipermail/openstack-sigs/2018-July/000432.html -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Fri Sep 14 23:25:19 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Fri, 14 Sep 2018 17:25:19 -0600 Subject: [Openstack-sigs] [nova][publiccloud-wg] Proposal to shelve on stop/suspend Message-ID: <80609709-7b11-f920-5a2b-2b980e936cf3@gmail.com> tl;dr: I'm proposing a new parameter to the server stop (and suspend?) APIs to control if nova shelve offloads the server. Long form: This came up during the public cloud WG session this week based on a couple of feature requests [1][2]. When a user stops/suspends a server, the hypervisor frees up resources on the host but nova continues to track those resources as being used on the host so the scheduler can't put more servers there. What operators would like to do is that when a user stops a server, nova actually shelve offloads the server from the host so they can schedule new servers on that host. On start/resume of the server, nova would find a new host for the server. This also came up in Vancouver where operators would like to free up limited expensive resources like GPUs when the server is stopped. This is also the behavior in AWS. The problem with shelve is that it's great for operators but users just don't use it, maybe because they don't know what it is and stop works just fine. So how do you get users to opt into shelving their server? I've proposed a high-level blueprint [3] where we'd add a new (microversioned) parameter to the stop API with three options: * auto * offload * retain Naming is obviously up for debate. The point is we would default to auto and if auto is used, the API checks a config option to determine the behavior - offload or retain. By default we would retain for backward compatibility. For users that don't care, they get auto and it's fine. For users that do care, they either (1) don't opt into the microversion or (2) specify the specific behavior they want. I don't think we need to expose what the cloud's configuration for auto is because again, if you don't care then it doesn't matter and if you do care, you can opt out of this. "How do we get users to use the new microversion?" I'm glad you asked. Well, nova CLI defaults to using the latest available microversion negotiated between the client and the server, so by default, anyone using "nova stop" would get the 'auto' behavior (assuming the client and server are new enough to support it). Long-term, openstack client plans on doing the same version negotiation. As for the server status changes, if the server is stopped and shelved, the status would be 'SHELVED_OFFLOADED' rather than 'SHUTDOWN'. I believe this is fine especially if a user is not being specific and doesn't care about the actual backend behavior. On start, the API would allow starting (unshelving) shelved offloaded (rather than just stopped) instances. Trying to hide shelved servers as stopped in the API would be overly complex IMO so I don't want to try and mask that. It is possible that a user that stopped and shelved their server could hit a NoValidHost when starting (unshelving) the server, but that really shouldn't happen in a cloud that's configuring nova to shelve by default because if they are doing this, their SLA needs to reflect they have the capacity to unshelve the server. If you can't honor that SLA, don't shelve by default. So, what are the general feelings on this before I go off and start writing up a spec? [1] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791681 [2] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791679 [3] https://blueprints.launchpad.net/nova/+spec/shelve-on-stop -- Thanks, Matt From zhipengh512 at gmail.com Sat Sep 15 00:51:40 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Fri, 14 Sep 2018 18:51:40 -0600 Subject: [Openstack-sigs] [tc][uc]Community Wide Long Term Goals Message-ID: Hi, Based upon the discussion we had at the TC session in the afternoon, I'm starting to draft a patch to add long term goal mechanism into governance. It is by no means a complete solution at the moment (still have not thought through the execution method yet to make sure the outcome), but feel free to provide your feedback at https://review.openstack.org/#/c/602799/ . -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bell at cern.ch Sat Sep 15 12:38:07 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Sat, 15 Sep 2018 12:38:07 +0000 Subject: [Openstack-sigs] [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend In-Reply-To: <80609709-7b11-f920-5a2b-2b980e936cf3@gmail.com> References: <80609709-7b11-f920-5a2b-2b980e936cf3@gmail.com> Message-ID: <01331699-F5B4-44AF-91CF-95416A44910B@cern.ch> One extra user motivation that came up during past forums was to have a different quota for shelved instances (or remove them from the project quota all together). Currently, I believe that a shelved instance still counts towards the instances/cores quota thus the reduction of usage by the user is not reflected in the quotas. One discussion at the time was that the user is still reserving IPs so it is not zero resource usage and the instances still occupy storage. (We disabled shelving for other reasons so I'm not able to check easily) Tim -----Original Message----- From: Matt Riedemann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Saturday, 15 September 2018 at 01:27 To: "OpenStack Development Mailing List (not for usage questions)" , "openstack-operators at lists.openstack.org" , "openstack-sigs at lists.openstack.org" Subject: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend tl;dr: I'm proposing a new parameter to the server stop (and suspend?) APIs to control if nova shelve offloads the server. Long form: This came up during the public cloud WG session this week based on a couple of feature requests [1][2]. When a user stops/suspends a server, the hypervisor frees up resources on the host but nova continues to track those resources as being used on the host so the scheduler can't put more servers there. What operators would like to do is that when a user stops a server, nova actually shelve offloads the server from the host so they can schedule new servers on that host. On start/resume of the server, nova would find a new host for the server. This also came up in Vancouver where operators would like to free up limited expensive resources like GPUs when the server is stopped. This is also the behavior in AWS. The problem with shelve is that it's great for operators but users just don't use it, maybe because they don't know what it is and stop works just fine. So how do you get users to opt into shelving their server? I've proposed a high-level blueprint [3] where we'd add a new (microversioned) parameter to the stop API with three options: * auto * offload * retain Naming is obviously up for debate. The point is we would default to auto and if auto is used, the API checks a config option to determine the behavior - offload or retain. By default we would retain for backward compatibility. For users that don't care, they get auto and it's fine. For users that do care, they either (1) don't opt into the microversion or (2) specify the specific behavior they want. I don't think we need to expose what the cloud's configuration for auto is because again, if you don't care then it doesn't matter and if you do care, you can opt out of this. "How do we get users to use the new microversion?" I'm glad you asked. Well, nova CLI defaults to using the latest available microversion negotiated between the client and the server, so by default, anyone using "nova stop" would get the 'auto' behavior (assuming the client and server are new enough to support it). Long-term, openstack client plans on doing the same version negotiation. As for the server status changes, if the server is stopped and shelved, the status would be 'SHELVED_OFFLOADED' rather than 'SHUTDOWN'. I believe this is fine especially if a user is not being specific and doesn't care about the actual backend behavior. On start, the API would allow starting (unshelving) shelved offloaded (rather than just stopped) instances. Trying to hide shelved servers as stopped in the API would be overly complex IMO so I don't want to try and mask that. It is possible that a user that stopped and shelved their server could hit a NoValidHost when starting (unshelving) the server, but that really shouldn't happen in a cloud that's configuring nova to shelve by default because if they are doing this, their SLA needs to reflect they have the capacity to unshelve the server. If you can't honor that SLA, don't shelve by default. So, what are the general feelings on this before I go off and start writing up a spec? [1] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791681 [2] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791679 [3] https://blueprints.launchpad.net/nova/+spec/shelve-on-stop -- Thanks, Matt __________________________________________________________________________ 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 From Tim.Bell at cern.ch Sat Sep 15 14:51:26 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Sat, 15 Sep 2018 14:51:26 +0000 Subject: [Openstack-sigs] [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend In-Reply-To: <01331699-F5B4-44AF-91CF-95416A44910B@cern.ch> References: <80609709-7b11-f920-5a2b-2b980e936cf3@gmail.com> <01331699-F5B4-44AF-91CF-95416A44910B@cern.ch> Message-ID: <5D0C9FC3-38EF-4F8E-B6F0-7B3B7DD508C0@cern.ch> Found the previous discussion at http://lists.openstack.org/pipermail/openstack-operators/2016-August/011321.html from 2016. Tim -----Original Message----- From: Tim Bell Date: Saturday, 15 September 2018 at 14:38 To: "OpenStack Development Mailing List (not for usage questions)" , "openstack-operators at lists.openstack.org" , "openstack-sigs at lists.openstack.org" Subject: Re: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend One extra user motivation that came up during past forums was to have a different quota for shelved instances (or remove them from the project quota all together). Currently, I believe that a shelved instance still counts towards the instances/cores quota thus the reduction of usage by the user is not reflected in the quotas. One discussion at the time was that the user is still reserving IPs so it is not zero resource usage and the instances still occupy storage. (We disabled shelving for other reasons so I'm not able to check easily) Tim -----Original Message----- From: Matt Riedemann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Saturday, 15 September 2018 at 01:27 To: "OpenStack Development Mailing List (not for usage questions)" , "openstack-operators at lists.openstack.org" , "openstack-sigs at lists.openstack.org" Subject: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend tl;dr: I'm proposing a new parameter to the server stop (and suspend?) APIs to control if nova shelve offloads the server. Long form: This came up during the public cloud WG session this week based on a couple of feature requests [1][2]. When a user stops/suspends a server, the hypervisor frees up resources on the host but nova continues to track those resources as being used on the host so the scheduler can't put more servers there. What operators would like to do is that when a user stops a server, nova actually shelve offloads the server from the host so they can schedule new servers on that host. On start/resume of the server, nova would find a new host for the server. This also came up in Vancouver where operators would like to free up limited expensive resources like GPUs when the server is stopped. This is also the behavior in AWS. The problem with shelve is that it's great for operators but users just don't use it, maybe because they don't know what it is and stop works just fine. So how do you get users to opt into shelving their server? I've proposed a high-level blueprint [3] where we'd add a new (microversioned) parameter to the stop API with three options: * auto * offload * retain Naming is obviously up for debate. The point is we would default to auto and if auto is used, the API checks a config option to determine the behavior - offload or retain. By default we would retain for backward compatibility. For users that don't care, they get auto and it's fine. For users that do care, they either (1) don't opt into the microversion or (2) specify the specific behavior they want. I don't think we need to expose what the cloud's configuration for auto is because again, if you don't care then it doesn't matter and if you do care, you can opt out of this. "How do we get users to use the new microversion?" I'm glad you asked. Well, nova CLI defaults to using the latest available microversion negotiated between the client and the server, so by default, anyone using "nova stop" would get the 'auto' behavior (assuming the client and server are new enough to support it). Long-term, openstack client plans on doing the same version negotiation. As for the server status changes, if the server is stopped and shelved, the status would be 'SHELVED_OFFLOADED' rather than 'SHUTDOWN'. I believe this is fine especially if a user is not being specific and doesn't care about the actual backend behavior. On start, the API would allow starting (unshelving) shelved offloaded (rather than just stopped) instances. Trying to hide shelved servers as stopped in the API would be overly complex IMO so I don't want to try and mask that. It is possible that a user that stopped and shelved their server could hit a NoValidHost when starting (unshelving) the server, but that really shouldn't happen in a cloud that's configuring nova to shelve by default because if they are doing this, their SLA needs to reflect they have the capacity to unshelve the server. If you can't honor that SLA, don't shelve by default. So, what are the general feelings on this before I go off and start writing up a spec? [1] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791681 [2] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791679 [3] https://blueprints.launchpad.net/nova/+spec/shelve-on-stop -- Thanks, Matt __________________________________________________________________________ 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 From zhipengh512 at gmail.com Sun Sep 16 14:28:13 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Sun, 16 Sep 2018 07:28:13 -0700 Subject: [Openstack-sigs] [tc][uc]Community Wide Long Term Goals In-Reply-To: References: Message-ID: Just a quick update, the execution part of the proposal has been added in patch-2 , so if you have the similar concern shared in Matt's open letter , please help review and comment. On Fri, Sep 14, 2018, 5:51 PM Zhipeng Huang wrote: > Hi, > > Based upon the discussion we had at the TC session in the afternoon, I'm > starting to draft a patch to add long term goal mechanism into governance. > It is by no means a complete solution at the moment (still have not thought > through the execution method yet to make sure the outcome), but feel free > to provide your feedback at https://review.openstack.org/#/c/602799/ . > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhipeng at huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipengh at uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Mon Sep 17 17:42:58 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 17 Sep 2018 11:42:58 -0600 Subject: [Openstack-sigs] Fwd: [Starlingx-discuss] Forum Topic Submission Period Message-ID: <1537206068-sup-2844@lrrr.local> Since this came up during the TC meeting Friday at the summit: SIG chairs, if you have items you think may qualify for community goals or other project work, *please* propose forum sessions to publicize and discuss them. Doug --- Begin forwarded message from Jimmy McArthur --- From: Jimmy McArthur To: "\"OpenStack-operators at lists.openstack.org\"" , openstack-dev , "community at lists.openstack.org" , "starlingx-discuss at lists.starlingx.io" , kata-dev , airship-discuss , Zuul-discuss Date: Mon, 17 Sep 2018 11:13:47 -0500 Subject: [Starlingx-discuss] Forum Topic Submission Period Hello Everyone! The Forum Topic Submission session started September 12 and will run through September 26th. Now is the time to wrangle the topics you gathered during your Brainstorming Phase and start pushing forum topics through. Don't rely only on a PTL to make the agenda... step on up and place the items you consider important front and center. As you may have noticed on the Forum Wiki (https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP tool this year. We did our best to remove Summit specific language, but if you notice something, just know that you are submitting to the Forum. URL is here: https://www.openstack.org/summit/berlin-2018/call-for-presentations Looking forward to seeing everyone's submissions! If you have questions or concerns about the process, please don't hesitate to reach out. Cheers, Jimmy --- End forwarded message --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rico.lin.guanyu at gmail.com Tue Sep 18 01:46:22 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Tue, 18 Sep 2018 09:46:22 +0800 Subject: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops In-Reply-To: References: <20180813165615.m7yltwe5zqkbjdx6@pacific.linksys.moosehall> Message-ID: Here is the summarize from some follow-up discussion in PTG for SIGs/WGs expose, http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html On Wed, Sep 12, 2018 at 6:40 AM Eric K wrote: > Sorry quite last minute considering the UC sessions tmr. I just added a > candidate question to the etherpad which may provide more actionable > responses for us: > https://etherpad.openstack.org/p/self-healing-user-survey-questions > > From: Rico Lin > Reply-To: > Date: Thursday, August 30, 2018 at 9:57 AM > To: > Subject: Re: [Openstack-sigs] [self-healing][all] Expose SIG to user/ops > > > > On Tue, Aug 14, 2018 at 12:56 AM Adam Spiers wrote: > > > > This sounds like a great idea to me! I've submitted a story for this: > > > > https://storyboard.openstack.org/#!/story/2003423 > > > > and set up an etherpad for brainstorming: > > > > https://etherpad.openstack.org/p/self-healing-user-survey-questions > > > I think those two questions are quite great. Just put some extra idea in > that. > Also, I have proposed you're etherpad under UC discussions in PTG > https://etherpad.openstack.org/p/uc-stein-ptg > Unfortunately, that's when UC discuss about next survey, so appears we > have to settle down with certain questions before our meeting in PTG. > For me, the current version looks nice. If anyone like to suggest more, > feel free to do so > > > > > > This sounds reasonable. We already link to the StoryBoard from the > > SIG portal wiki page: > > > > > https://wiki.openstack.org/wiki/Self-healing_SIG#Community_Infrastructure_.2F_Resources > > > > but yes we could also proactively announce this in places which would > > reach more users and operators, inviting them to submit stories. Can > > you suggest how best to do this? We could email the openstack and > > openstack-operators lists, although TBH I have done this several times > > in the past and not gotten much engagement - probably because both > > lists are very high traffic. > > > I guess we should keep trying to propose in ML. There're two more places I > think we can try on. As we might be able to have our own page in User > survey, I think we're allow to put more message to point a place(our git > repo, or an etherpad) for Users who like to add more information during > that survey. The second place is SuperUser MagZ. If we can come's up with > an article (which we can plan in PTG if we like to have one) to introduce > our plan, works, and needs. I think Super User will willing to help us post > that article out. If we got some article, we can Use official OpenStack > social media (FB, Twitter, etc) to broadcast that information. > > > > > > I love this idea, and yes the self-healing-sig git repository could > > absolutely be the home for this gating code. I suspect that a big > > part of the challenge will be to simulate failures in order to test > > the self-healing functionality. In fact we already have a story > > regarding automated testing: > > > > https://storyboard.openstack.org/#!/story/2002129 > > > > although that is much more ambitious in scope, i.e. building a > > complete framework which could support testing of many different > > self-healing scenarios. I have some documentation on the Eris project > > which I am planning to upload to the repository on this. > > > > However your proposal sounds less ambitious and more likely to be > > achievable in the short-term, so I'd love to learn more about how you > > think this might work (unfortunately I don't know much about Tempest > > internals yet). > > Since the git just updated with more official project format, we can add > Zuul.yaml to define our periodic job I think we already got a lot of places > to add tempest test(I think we might be able to use heat-tempest-plugin > too), so we shouldn't need to build our own tempest repo > > > > Thanks a lot for your ideas! They are great - please keep them coming > ;-) > > > > Adam > > _______________________________________________ openstack-sigs mailing > list openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rico.lin.guanyu at gmail.com Tue Sep 18 01:58:36 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Tue, 18 Sep 2018 09:58:36 +0800 Subject: [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials) In-Reply-To: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> References: <5511f82b-80d9-5818-b53f-3e7abe7adf93@gmail.com> Message-ID: Hope you all safely travel back to home now. Here is the summarize from some discussions (as much as I can trigger or attend) in PTG for SIGs/WGs expose and some idea for action, http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html I also like the idea to at least expose the information of SIGs/WGs right away. Feel free to give your feedback. And not like the following message matters to anyone, but just in case. I believe this is a goal for all group in the community so just don't let who your duty, position, or full hand of good tasks to limit what you think about the relative of this goal with you. Give your positive or negative opinions to help us get a better shape. On Wed, Sep 12, 2018 at 11:47 PM Matt Riedemann wrote: > Rather than take a tangent on Kristi's candidacy thread [1], I'll bring > this up separately. > > Kristi said: > > "Ultimately, this list isn’t exclusive and I’d love to hear your and > other people's opinions about what you think the I should focus on." > > Well since you asked... > > Some feedback I gave to the public cloud work group yesterday was to get > their RFE/bug list ranked from the operator community (because some of > the requests are not exclusive to public cloud), and then put pressure > on the TC to help project manage the delivery of the top issue. I would > like all of the SIGs to do this. The upgrades SIG should rank and > socialize their #1 issue that needs attention from the developer > community - maybe that's better upgrade CI testing for deployment > projects, maybe it's getting the pre-upgrade checks goal done for Stein. > The UC should also be doing this; maybe that's the UC saying, "we need > help on closing feature gaps in openstack client and/or the SDK". I > don't want SIGs to bombard the developers with *all* of their > requirements, but I want to get past *talking* about the *same* issues > *every* time we get together. I want each group to say, "this is our top > issue and we want developers to focus on it." For example, the extended > maintenance resolution [2] was purely birthed from frustration about > talking about LTS and stable branch EOL every time we get together. It's > also the responsibility of the operator and user communities to weigh in > on proposed release goals, but the TC should be actively trying to get > feedback from those communities about proposed goals, because I bet > operators and users don't care about mox removal [3]. > > I want to see the TC be more of a cross-project project management > group, like a group of Ildikos and what she did between nova and cinder > to get volume multi-attach done, which took persistent supervision to > herd the cats and get it delivered. Lance is already trying to do this > with unified limits. Doug is doing this with the python3 goal. I want my > elected TC members to be pushing tangible technical deliverables forward. > > I don't find any value in the TC debating ad nauseam about visions and > constellations and "what is openstack?". Scope will change over time > depending on who is contributing to openstack, we should just accept > this. And we need to realize that if we are failing to deliver value to > operators and users, they aren't going to use openstack and then "what > is openstack?" won't matter because no one will care. > > So I encourage all elected TC members to work directly with the various > SIGs to figure out their top issue and then work on managing those > deliverables across the community because the TC is particularly well > suited to do so given the elected position. I realize political and > bureaucratic "how should openstack deal with x?" things will come up, > but those should not be the priority of the TC. So instead of > philosophizing about things like, "should all compute agents be in a > single service with a REST API" for hours and hours, every few months - > immediately ask, "would doing that get us any closer to achieving top > technical priority x?" Because if not, or it's so fuzzy in scope that no > one sees the way forward, document a decision and then drop it. > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html > [2] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html > [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html > > -- > > Thanks, > > Matt > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Sep 18 02:26:57 2018 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 18 Sep 2018 11:26:57 +0900 Subject: [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: References: Message-ID: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> ---- On Sat, 15 Sep 2018 02:49:40 +0900 Zhipeng Huang wrote ---- > Hi all, > Follow up the diversity discussion we had in the tc session this morning [0], I've proposed a resolution on facilitating technical community in large to engage in global reachout for OpenStack more efficiently. > Your feedbacks are welcomed. Whether this should be a new resolution or not at the end of the day, this is a conversation worthy to have. > [0] https://review.openstack.org/602697 I like that we are discussing the Global Reachout things which i personally feel is very important. There are many obstacle to have a standard global communication way. Honestly saying, there cannot be any standard communication channel which can accommodate different language, cultures , company/govt restriction. So the better we can do is best solution. I can understand that IRC cannot be used in China which is very painful and mostly it is used weChat. But there are few key points we need to consider for any social app to use? - Technical discussions which needs more people to participate and need ref of links etc cannot be done on mobile app. You need desktop version of that app. - Many of the social app have # of participation, invitation, logging restriction. - Those apps are not restricted to other place. - It does not split the community members among more than one app or exiting channel. With all those point, we need to think what all communication channel we really want to promote as community. IMO, we should educate and motivate people to participate over existing channel like IRC, ML as much as possible. At least ML does not have any issue about usage. Ambassador and local user groups people can play a critical role here or local developers (i saw Alex volunteer for nova discussion in china) and they can ask them to start communication in ML or if they cannot then they can start the thread and proxy for them. I know slack is being used for Japan community and most of the communication there is in Japanese so i cannot help there even I join it. When talking to Akira (Japan Ambassador ) and as per him most of the developers do communicate in IRC, ML but users hesitate to do so because of culture and language. So if proposal is to participate community (Developers, TC, UC, Ambassador, User Group members etc) in local chat app and encourage people to move to ML etc then it is great idea. But if we want to promote all different chat app as community practice then, it can lead to lot of other problems than solving the current one. For example: It will divide the technical discussion etc -gmann > -- > Zhipeng (Howard) Huang > Standard EngineerIT Standard & Patent/IT Product LineHuawei Technologies Co,. LtdEmail: huangzhipeng at huawei.comOffice: Huawei Industrial Base, Longgang, Shenzhen > (Previous) > Research AssistantMobile Ad-Hoc Network Lab, Calit2University of California, IrvineEmail: zhipengh at uci.eduOffice: Calit2 Building Room 2402 > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > From fungi at yuggoth.org Tue Sep 18 12:40:50 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 18 Sep 2018 12:40:50 +0000 Subject: [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> References: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> Message-ID: <20180918124049.jw7xbufikxfx3w37@yuggoth.org> On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: [...] > I can understand that IRC cannot be used in China which is very > painful and mostly it is used weChat. [...] I have yet to hear anyone provide first-hand confirmation that access to Freenode's IRC servers is explicitly blocked by the mainland Chinese government. There has been a lot of speculation that the usual draconian corporate firewall policies (surprise, the rest of the World gets to struggle with those too, it's not just a problem in China) are blocking a variety of messaging protocols from workplace networks and the people who encounter this can't tell the difference because they're already accustomed to much of their other communications being blocked at the border. I too have heard from someone who's heard from someone that "IRC can't be used in China" but the concrete reasons why continue to be missing from these discussions. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From doug at doughellmann.com Tue Sep 18 12:55:20 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 18 Sep 2018 06:55:20 -0600 Subject: [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: <20180918124049.jw7xbufikxfx3w37@yuggoth.org> References: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> <20180918124049.jw7xbufikxfx3w37@yuggoth.org> Message-ID: <1537275239-sup-1858@lrrr.local> Excerpts from Jeremy Stanley's message of 2018-09-18 12:40:50 +0000: > On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: > [...] > > I can understand that IRC cannot be used in China which is very > > painful and mostly it is used weChat. > [...] > > I have yet to hear anyone provide first-hand confirmation that > access to Freenode's IRC servers is explicitly blocked by the > mainland Chinese government. There has been a lot of speculation > that the usual draconian corporate firewall policies (surprise, the > rest of the World gets to struggle with those too, it's not just a > problem in China) are blocking a variety of messaging protocols from > workplace networks and the people who encounter this can't tell the > difference because they're already accustomed to much of their other > communications being blocked at the border. I too have heard from > someone who's heard from someone that "IRC can't be used in China" > but the concrete reasons why continue to be missing from these > discussions. Given the time zone differences between many of our regular contributors and the folks in China, I wonder if it would be better to emphasize the use of the mailing list anyway. Doug From fungi at yuggoth.org Tue Sep 18 13:57:58 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 18 Sep 2018 13:57:58 +0000 Subject: [Openstack-sigs] [openstack-dev] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: References: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> <20180918124049.jw7xbufikxfx3w37@yuggoth.org> Message-ID: <20180918135758.2h6fqhwc3ika3xpf@yuggoth.org> On 2018-09-18 14:52:28 +0200 (+0200), Sylvain Bauza wrote: [...] > Why are we discussing about WeChat now? Is that because a large > set of our contributors *can't* access IRC or because they > *prefer* any other? Until we get confirmation either way, I'm going to work under the assumption that there are actual network barriers to using IRC for these contributors and that it's not just a matter of preference. I mainly want to know the source of these barriers because that will determine how to go about addressing them. If it's restrictions imposed by employers, it may be hard for employees to raise the issue in predominantly confrontation-averse cultures. The First Contact SIG is working on a document which outlines the communications and workflows used by our community with a focus on explaining to managers and other staff at contributing organizations what allowances they can make to ease and improve the experience of those they've tasked with working upstream. If the barriers are instead imposed by national government, then urging contributors within those borders to flaunt the law and interact with the rest of our community over IRC is not something which should be taken lightly. That's not to say it can't be solved, but the topic then is a much more political one and our community may not be an appropriate venue for those discussions. > In the past, we made clear for a couple of times why IRC is our > communication channel. I don't see those reasons to be invalid > now, but I'm still open to understand the problems about why our > community becomes de facto fragmented. I think the extended community is already fragmented across a variety of discussion fora. Some watch for relevant hashtags on Twitter and engage in discussions there. I gather there's an unofficial OpenStack Slack channel where lots of newcomers show up to ask questions because they assume the OpenStack community relies on Slack the same way the Kubernetes community does, and so a few volunteers from our community hang out there and try to redirect questions to more appropriate places. I've also heard tell of an OpenStack subReddit which some stackers help moderate and try to provide damage control/correct misstatements there. I don't think these are necessarily a problem, and the members of our community who work to spread accurate information to these places are in many cases helping reduce the actual degree of fragmentation. I'm still trying to make up my mind on 602697 which is why I haven't weighed in on the proposal yet. So far I feel like it probably doesn't bring anything new, since we already declare how and where official discussion takes place and the measure doesn't make any attempt to change that. We also don't regulate where unofficial discussions are allowed to take place, and so it doesn't open up any new possibilities which were previously disallowed. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From thierry at openstack.org Tue Sep 18 13:59:51 2018 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 18 Sep 2018 15:59:51 +0200 Subject: [Openstack-sigs] [openstack-dev] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: References: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> <20180918124049.jw7xbufikxfx3w37@yuggoth.org> Message-ID: <204f0abc-6391-3001-deae-b14a8de6710f@openstack.org> Sylvain Bauza wrote: > > > Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley > a écrit : > > On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: > [...] > > I can understand that IRC cannot be used in China which is very > > painful and mostly it is used weChat. > [...] > > I have yet to hear anyone provide first-hand confirmation that > access to Freenode's IRC servers is explicitly blocked by the > mainland Chinese government. There has been a lot of speculation > that the usual draconian corporate firewall policies (surprise, the > rest of the World gets to struggle with those too, it's not just a > problem in China) are blocking a variety of messaging protocols from > workplace networks and the people who encounter this can't tell the > difference because they're already accustomed to much of their other > communications being blocked at the border. I too have heard from > someone who's heard from someone that "IRC can't be used in China" > but the concrete reasons why continue to be missing from these > discussions. > > Thanks fungi, that's the crux of the problem I'd like to see discussed > in the governance change. > In this change, it states the non-use of existing and official > communication tools as to be "cumbersome". See my comment on PS1, I > thought the original concern was technical. > > Why are we discussing about WeChat now ? Is that because a large set of > our contributors *can't* access IRC or because they *prefer* any other ? > In the past, we made clear for a couple of times why IRC is our > communication channel. I don't see those reasons to be invalid now, but > I'm still open to understand the problems about why our community > becomes de facto fragmented. Agreed, I'm still trying to grasp the issue we are trying to solve here. We really need to differentiate between technical blockers (firewall), cultural blockers (language) and network effect preferences (preferred platform). We should definitely try to address technical blockers, as we don't want to exclude anyone. We can also allow for a bit of flexibility in the tools used in our community, to accommodate cultural blockers as much as we possibly can (keeping in mind that in the end, the code has to be written, proposed and discussed in a single language). We can even encourage community members to reach out on local social networks... But I'm reluctant to pass an official resolution to recommend that TC members engage on specific platforms because "everyone is there". -- Thierry Carrez (ttx) From dtroyer at gmail.com Tue Sep 18 14:52:25 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Tue, 18 Sep 2018 09:52:25 -0500 Subject: [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: <20180918124049.jw7xbufikxfx3w37@yuggoth.org> References: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> <20180918124049.jw7xbufikxfx3w37@yuggoth.org> Message-ID: On Tue, Sep 18, 2018 at 7:40 AM, Jeremy Stanley wrote: > I have yet to hear anyone provide first-hand confirmation that > access to Freenode's IRC servers is explicitly blocked by the > mainland Chinese government. There has been a lot of speculation [...] Data point: I have a couple of reports from some of our StarlingX contributors that access to Freenode IRC works from our (Intel) sites but not from home. I am not going to speculate as to the cause, it clearly is not open access, but also not totally closed off. dt -- Dean Troyer dtroyer at gmail.com From cdent+os at anticdent.org Tue Sep 18 17:58:19 2018 From: cdent+os at anticdent.org (Chris Dent) Date: Tue, 18 Sep 2018 18:58:19 +0100 (BST) Subject: [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: <1537275239-sup-1858@lrrr.local> References: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> <20180918124049.jw7xbufikxfx3w37@yuggoth.org> <1537275239-sup-1858@lrrr.local> Message-ID: On Tue, 18 Sep 2018, Doug Hellmann wrote: > Given the time zone differences between many of our regular > contributors and the folks in China, I wonder if it would be better > to emphasize the use of the mailing list anyway. Yes. If our goal is to have a medium which is accessible and useful to a diveristy of time zones and languages, the mailing list is the async medium that we've got. I agree that if there are synchronous media that (only some) people choose to use then some one or several from those media should try to reflect important stuff in both directions and strive to drive people to the mailing list(s). -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent From mriedemos at gmail.com Tue Sep 18 19:27:03 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 18 Sep 2018 14:27:03 -0500 Subject: [Openstack-sigs] Are we ready to put stable/ocata into extended maintenance mode? Message-ID: The release page says Ocata is planned to go into extended maintenance mode on Aug 27 [1]. There really isn't much to this except it means we don't do releases for Ocata anymore [2]. There is a caveat that project teams that do not wish to maintain stable/ocata after this point can immediately end of life the branch for their project [3]. We can still run CI using tags, e.g. if keystone goes ocata-eol, devstack on stable/ocata can still continue to install from stable/ocata for nova and the ocata-eol tag for keystone. Having said that, if there is no undue burden on the project team keeping the lights on for stable/ocata, I would recommend not tagging the stable/ocata branch end of life at this point. So, questions that need answering are: 1. Should we cut a final release for projects with stable/ocata branches before going into extended maintenance mode? I tend to think "yes" to flush the queue of backports. In fact, [3] doesn't mention it, but the resolution said we'd tag the branch [4] to indicate it has entered the EM phase. 2. Are there any projects that would want to skip EM and go directly to EOL (yes this feels like a Monopoly question)? [1] https://releases.openstack.org/ [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases [3] https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance [4] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life -- Thanks, Matt From sean.mcginnis at gmx.com Tue Sep 18 19:29:40 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Tue, 18 Sep 2018 14:29:40 -0500 Subject: [Openstack-sigs] Are we ready to put stable/ocata into extended maintenance mode? In-Reply-To: References: Message-ID: <20180918192940.GA10869@sm-workstation> On Tue, Sep 18, 2018 at 02:27:03PM -0500, Matt Riedemann wrote: > The release page says Ocata is planned to go into extended maintenance mode > on Aug 27 [1]. There really isn't much to this except it means we don't do > releases for Ocata anymore [2]. There is a caveat that project teams that do > not wish to maintain stable/ocata after this point can immediately end of > life the branch for their project [3]. We can still run CI using tags, e.g. > if keystone goes ocata-eol, devstack on stable/ocata can still continue to > install from stable/ocata for nova and the ocata-eol tag for keystone. > Having said that, if there is no undue burden on the project team keeping > the lights on for stable/ocata, I would recommend not tagging the > stable/ocata branch end of life at this point. > > So, questions that need answering are: > > 1. Should we cut a final release for projects with stable/ocata branches > before going into extended maintenance mode? I tend to think "yes" to flush > the queue of backports. In fact, [3] doesn't mention it, but the resolution > said we'd tag the branch [4] to indicate it has entered the EM phase. > > 2. Are there any projects that would want to skip EM and go directly to EOL > (yes this feels like a Monopoly question)? > > [1] https://releases.openstack.org/ > [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases > [3] https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance > [4] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life > > -- > > Thanks, > > Matt I have a patch that's been pending for marking it as extended maintenance: https://review.openstack.org/#/c/598164/ That's just the state for Ocata. You raise some other good points here that I am curious to see input on. Sean From stig.openstack at telfer.org Tue Sep 18 19:52:19 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Tue, 18 Sep 2018 20:52:19 +0100 Subject: [Openstack-sigs] [scientific] IRC meeting 2100 UTC - Berlin SIG activities, forum activities, etc. Message-ID: Hi all - We have a Scientific SIG IRC meeting at 2100UTC (about an hour’s time) in channel #openstack-meeting. Everyone is welcome. Today’s agenda is available here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_September_18th_2018 We’ll be starting some of the preparation for Berlin, please if you can come prepared with ideas for forum proposals. Cheers, Stig -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbitter at redhat.com Tue Sep 18 20:30:36 2018 From: zbitter at redhat.com (Zane Bitter) Date: Tue, 18 Sep 2018 16:30:36 -0400 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: References: Message-ID: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> On 14/09/18 1:49 PM, Zhipeng Huang wrote: > Hi all, > > Follow up the diversity discussion we had in the tc session this morning > [0], I've proposed a resolution on facilitating technical community in > large to engage in global reachout for OpenStack more efficiently. > > Your feedbacks are welcomed. Whether this should be a new resolution or > not at the end of the day, this is a conversation worthy to have. > > [0] https://review.openstack.org/602697 As others have mentioned, I think this is diving into solutions when we haven't defined the problems. I know you mentioned it briefly in the PTG session, but that context never made it to the review or the mailing list. So AIUI the issue you're trying to solve here is that the TC members seem distant and inaccessible to Chinese contributors because we're not on the same social networks they are? Perhaps there are others too? Obvious questions to ask from there would be: - Whether this is the most important issue facing contributors from the APAC region - To what extent the proposed solution is expected to help cheers, Zane. From yihleong at gmail.com Wed Sep 19 01:08:08 2018 From: yihleong at gmail.com (Yih Leong, Sun.) Date: Tue, 18 Sep 2018 18:08:08 -0700 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> Message-ID: I would encourage folks/users/developers in other region of the globe (e.g PRC, APAC, etc) to actively participate in this conversion. Your input is critically important for the committee to reach a fruitful decision. 谨在此鼓励其他地区(e.g. 中国大陆, 亚太区等) 的用户/开发人员 积极参与讨论, 您的意见将为委员会提供宝贵信息. https://review.openstack.org/602697 Thanks! Yih Leong Sun. Member of User Committee. On Tue, Sep 18, 2018 at 1:30 PM Zane Bitter wrote: > On 14/09/18 1:49 PM, Zhipeng Huang wrote: > > Hi all, > > > > Follow up the diversity discussion we had in the tc session this morning > > [0], I've proposed a resolution on facilitating technical community in > > large to engage in global reachout for OpenStack more efficiently. > > > > Your feedbacks are welcomed. Whether this should be a new resolution or > > not at the end of the day, this is a conversation worthy to have. > > > > [0] https://review.openstack.org/602697 > > As others have mentioned, I think this is diving into solutions when we > haven't defined the problems. I know you mentioned it briefly in the PTG > session, but that context never made it to the review or the mailing list. > > So AIUI the issue you're trying to solve here is that the TC members > seem distant and inaccessible to Chinese contributors because we're not > on the same social networks they are? > > Perhaps there are others too? > > Obvious questions to ask from there would be: > > - Whether this is the most important issue facing contributors from the > APAC region > > - To what extent the proposed solution is expected to help > > cheers, > Zane. > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluejay.ahn at gmail.com Wed Sep 19 01:10:45 2018 From: bluejay.ahn at gmail.com (Jaesuk Ahn) Date: Wed, 19 Sep 2018 10:10:45 +0900 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> Message-ID: On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter wrote: > ... > > Perhaps there are others too? > > Obvious questions to ask from there would be: > > - Whether this is the most important issue facing contributors from the > APAC region > > - To what extent the proposed solution is expected to help > I do agree with Zane on the above point. As one of OpenStack participants from Asia region, I will put my personal opinion. IRC and ML has been an unified and standard way of communication in OpenStack Community, and that has been a good way to encourage "open communication" on a unified method wherever you are from, or whatever background you have. If the whole community start recognize some other tools (say WeChat) as recommended alternative communication method because there are many people there, ironically, it might be a way to break "diversity" and "openness" we want to embrace. Using whatever social media (or tools) in a specific region due to any reason is not a problem. Anyone is free to use anything. Only thing we need to make sure is, if you want to communicate officially with the whole community, there is a very well defined and unified way to do it. This is currently IRC and ML. Some of Korean dev has difficulties to use IRC. However, there is not a perfect tool out there in this world, and we accept all the reason why the community selected IRC as official tool But, that being said, There are some things I am facing with IRC from here in Korea As a person from Asia, I do have some of pain points. Because of time differences, often, I have to do achieve searching since most of conversations happened while I am sleeping. IRC is not a good tool to perform "search backlog". Although there is message archive you can dig, it is still hard. This is a problem. I do love to see any technical solution for me to efficiently and easily go through irc backlog, like most of modern chat tools. Secondly, IRC is not a popular one even in dev community here in Korea. In addition, in order to properly use irc, you need to do extra work, something like setting up bouncing server. I had to do google search to figure out how to use it. In that sense, It would be great to have OpenStack community provided, simplified and well-written, written in multiple language, IRC guide docs. Alternatively, if OpenStack community can provide a good web-based irc client tool, that would be fantastic. As I described the above, we can certainly have a healthy discussion on what different and real problems we are facing from Asia. However, I don't think this TC resolution is good way to do that. Cheers, -- Jaesuk Ahn, Team Lead Virtualization SW Lab, SW R&D Center SK Telecom -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengh512 at gmail.com Wed Sep 19 04:35:52 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Wed, 19 Sep 2018 12:35:52 +0800 Subject: [Openstack-sigs] [User-committee] [publiccloud-wg] Meeting tomorrow In-Reply-To: <70976fdd-3d0f-dafa-a792-4cb4daf96af1@citynetwork.eu> References: <70976fdd-3d0f-dafa-a792-4cb4daf96af1@citynetwork.eu> Message-ID: cc'ed sig list. Kind reminder for the meeting about 2 and half hours away, we will do a review of the denver ptg summary [0] and then go over the forum sessions which we want to propose [1] This is an EU/APAC friendly meeting so please do join us if you are in the region :) [0]https://etherpad.openstack.org/p/publiccloud-wg-stein-ptg-summary [1]https://etherpad.openstack.org/p/BER-forum-public-cloud On Tue, Sep 18, 2018 at 8:05 PM Tobias Rydberg < tobias.rydberg at citynetwork.eu> wrote: > Hi everyone, > > Don't forget that we have a meeting tomorrow at 0700 UTC at IRC channel > #openstack-publiccloud. > > See you all there! > > Cheers, > Tobias > > -- > Tobias Rydberg > Senior Developer > Twitter & IRC: tobberydberg > > www.citynetwork.eu | www.citycloud.com > > INNOVATION THROUGH OPEN IT INFRASTRUCTURE > ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED > > > _______________________________________________ > User-committee mailing list > User-committee at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Wed Sep 19 09:00:32 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 19 Sep 2018 10:00:32 +0100 Subject: [Openstack-sigs] [scientific] SIG input for advocacy at the forum Message-ID: Hi All - In yesterday’s SIG meeting we started gathering input for forum proposals for Berlin. It would be really helpful to gather input from the breadth of interests in the SIG. Please take a look and add items you’d like to see argued for: https://etherpad.openstack.org/p/BER-stein-forum-scientific-sig Cheers, Stig -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Wed Sep 19 11:16:31 2018 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Wed, 19 Sep 2018 13:16:31 +0200 Subject: [Openstack-sigs] Are we ready to put stable/ocata into extended maintenance mode? In-Reply-To: References: Message-ID: <5d24ac83-5636-b639-abac-f9523a111409@redhat.com> On 9/18/18 9:27 PM, Matt Riedemann wrote: > The release page says Ocata is planned to go into extended maintenance mode on > Aug 27 [1]. There really isn't much to this except it means we don't do releases > for Ocata anymore [2]. There is a caveat that project teams that do not wish to > maintain stable/ocata after this point can immediately end of life the branch > for their project [3]. We can still run CI using tags, e.g. if keystone goes > ocata-eol, devstack on stable/ocata can still continue to install from > stable/ocata for nova and the ocata-eol tag for keystone. Having said that, if > there is no undue burden on the project team keeping the lights on for > stable/ocata, I would recommend not tagging the stable/ocata branch end of life > at this point. > > So, questions that need answering are: > > 1. Should we cut a final release for projects with stable/ocata branches before > going into extended maintenance mode? I tend to think "yes" to flush the queue > of backports. In fact, [3] doesn't mention it, but the resolution said we'd tag > the branch [4] to indicate it has entered the EM phase. Some ironic projects have outstanding changes, I guess we should release them. > > 2. Are there any projects that would want to skip EM and go directly to EOL (yes > this feels like a Monopoly question)? > > [1] https://releases.openstack.org/ > [2] > https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases > > [3] > https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance > > [4] > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life > > From aspiers at suse.com Wed Sep 19 11:57:25 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 19 Sep 2018 12:57:25 +0100 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> Message-ID: <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> [Meta-topic: I see that this thread started as a cross-post to openstack-{dev,operators,sigs}, but this subthread is only on -sigs, which presumably fractures the thread. Is there an accepted best practice addressing this problem?] Jaesuk Ahn wrote: >On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter wrote: >>... >> >>Perhaps there are others too? >> >>Obvious questions to ask from there would be: >> >>- Whether this is the most important issue facing contributors from the >>APAC region >> >>- To what extent the proposed solution is expected to help > >I do agree with Zane on the above point. > >As one of OpenStack participants from Asia region, I will put my personal >opinion. >IRC and ML has been an unified and standard way of communication in >OpenStack Community, and that has been a good way to encourage "open >communication" on a unified method wherever you are from, or whatever >background you have. If the whole community start recognize some other >tools (say WeChat) as recommended alternative communication method because >there are many people there, ironically, it might be a way to break >"diversity" and "openness" we want to embrace. Agreed. >Using whatever social media (or tools) in a specific region due to any >reason is not a problem. Anyone is free to use anything. Only thing we need >to make sure is, if you want to communicate officially with the whole >community, there is a very well defined and unified way to do it. This is >currently IRC and ML. Some of Korean dev has difficulties to use IRC. Any chance you could clarify what kind of difficulties they are encountering? As several TC members and others within this thread have already pointed out, that would help the community decide whether those difficulties can be addressed whilst keeping IRC, or whether it's worth considering replacing IRC with something else. >However, there is not a perfect tool out there in this world, and we accept >all the reason why the community selected IRC as official tool > >But, that being said, There are some things I am facing with IRC from here >in Korea > >As a person from Asia, I do have some of pain points. Because of time >differences, often, I have to do achieve searching since most of >conversations happened while I am sleeping. IRC is not a good tool to >perform "search backlog". Although there is message archive you can dig, it >is still hard. This is a problem. I do love to see any technical solution >for me to efficiently and easily go through irc backlog, like most of >modern chat tools. Would this particular pain point be solved by providing a friendly web search interface to the IRC log archives? BTW it is already possible to search them via google, by including site:eavesdrop.openstack.org in the search, but of course this is not very user-friendly. >Secondly, IRC is not a popular one even in dev community here in Korea. In >addition, in order to properly use irc, you need to do extra work, >something like setting up bouncing server. I had to do google search to >figure out how to use it. I agree - this is probably the biggest issue with IRC, not just in Korea or even in Asia, but globally. People are much more aware of this pain now because modern alternatives such as Slack, HipChat, Rocket.chat, Matrix etc. all solve that problem without requiring any extra effort from the user. >In that sense, It would be great to have >OpenStack community provided, simplified and well-written, written in >multiple language, IRC guide docs. Yes, if we stick with IRC then this certainly makes sense. >Alternatively, if OpenStack community >can provide a good web-based irc client tool, that would be fantastic. It already exists: Matrix's web client Riot has a built-in bridge with Freenode: https://opensource.com/article/17/5/introducing-riot-IRC Thinking further ahead, I have previously floated the idea of the community switching to Matrix altogether: http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000332.html I have to be honest: right now, whilst Matrix's usability is actually pretty good, it still needs a bit of work before it gets as slick as something like Slack. In particular, performance of the Freenode bridge is not always great. But like IRC, Matrix is all open source with a decentralized architecture, so I'm fairly confident that with a bit of investment from the OpenStack community (whether that's financial or developer resources), we could get it good enough for what we want. And I think that would help push for the best outcome for the wider FLOSS community outside OpenStack and the rest of the world, too. >As I described the above, we can certainly have a healthy discussion on >what different and real problems we are facing from Asia. >However, I don't think this TC resolution is good way to do that. Thanks a lot for sharing your perspective! IMHO it's very helpful. From bluejay.ahn at gmail.com Wed Sep 19 12:42:29 2018 From: bluejay.ahn at gmail.com (Jaesuk Ahn) Date: Wed, 19 Sep 2018 21:42:29 +0900 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> Message-ID: On Wed, Sep 19, 2018 at 8:58 PM Adam Spiers wrote: > [Meta-topic: I see that this thread started as a cross-post to > openstack-{dev,operators,sigs}, but this subthread is only on -sigs, > which presumably fractures the thread. Is there an accepted best > practice addressing this problem?] > Ah, I did not push "reply all" when I wrote this one. Sorry, not my intention to make fractures. I will put my additional thought on the original cross-post thread after this one. > > Jaesuk Ahn wrote: > >On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter wrote: > >>... > >> > >>Perhaps there are others too? > >> > >>Obvious questions to ask from there would be: > >> > >>- Whether this is the most important issue facing contributors from the > >>APAC region > >> > >>- To what extent the proposed solution is expected to help > > > >I do agree with Zane on the above point. > > > >As one of OpenStack participants from Asia region, I will put my personal > >opinion. > >IRC and ML has been an unified and standard way of communication in > >OpenStack Community, and that has been a good way to encourage "open > >communication" on a unified method wherever you are from, or whatever > >background you have. If the whole community start recognize some other > >tools (say WeChat) as recommended alternative communication method > because > >there are many people there, ironically, it might be a way to break > >"diversity" and "openness" we want to embrace. > > Agreed. > > >Using whatever social media (or tools) in a specific region due to any > >reason is not a problem. Anyone is free to use anything. Only thing we > need > >to make sure is, if you want to communicate officially with the whole > >community, there is a very well defined and unified way to do it. This is > >currently IRC and ML. Some of Korean dev has difficulties to use IRC. > > Any chance you could clarify what kind of difficulties they are > encountering? As several TC members and others within this thread > have already pointed out, that would help the community decide whether > those difficulties can be addressed whilst keeping IRC, or whether > it's worth considering replacing IRC with something else. > I have listed two main ones already. :) > > >However, there is not a perfect tool out there in this world, and we > accept > >all the reason why the community selected IRC as official tool > > > >But, that being said, There are some things I am facing with IRC from > here > >in Korea > > > >As a person from Asia, I do have some of pain points. Because of time > >differences, often, I have to do achieve searching since most of > >conversations happened while I am sleeping. IRC is not a good tool to > >perform "search backlog". Although there is message archive you can dig, > it > >is still hard. This is a problem. I do love to see any technical solution > >for me to efficiently and easily go through irc backlog, like most of > >modern chat tools. > > Would this particular pain point be solved by providing a friendly web > search interface to the IRC log archives? BTW it is already possible to > search them via google, by including > > site:eavesdrop.openstack.org > > in the search, but of course this is not very user-friendly. > Difficulties not mainly comes from "search", rather comes from difficulties to read through what has been discussed afterwards. Thanks for the tip though. FYI, I am using "a paid service that provide web-based irc client". This makes me so easy to be on IRC, go through logs, and connect all the time through mobile and web browser. Honestly, this paid service has removed most of my pain points to use irc. However, this is "paid" service, not a solution in general. > > >Secondly, IRC is not a popular one even in dev community here in Korea. > In > >addition, in order to properly use irc, you need to do extra work, > >something like setting up bouncing server. I had to do google search to > >figure out how to use it. > > I agree - this is probably the biggest issue with IRC, not just in > Korea or even in Asia, but globally. People are much more aware of > this pain now because modern alternatives such as Slack, HipChat, > Rocket.chat, Matrix etc. all solve that problem without requiring any > extra effort from the user. > > >In that sense, It would be great to have > >OpenStack community provided, simplified and well-written, written in > >multiple language, IRC guide docs. > > Yes, if we stick with IRC then this certainly makes sense. > > >Alternatively, if OpenStack community > >can provide a good web-based irc client tool, that would be fantastic. > > It already exists: Matrix's web client Riot has a built-in bridge with > Freenode: > > https://opensource.com/article/17/5/introducing-riot-IRC > > Thinking further ahead, I have previously floated the idea of the > community switching to Matrix altogether: > > > http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000332.html > > I have to be honest: right now, whilst Matrix's usability is actually > pretty good, it still needs a bit of work before it gets as slick as > something like Slack. In particular, performance of the Freenode bridge > is not always great. But like IRC, Matrix is all open source with a > decentralized architecture, so I'm fairly confident that with a bit of > investment from the OpenStack community (whether that's financial or > developer resources), we could get it good enough for what we want. > And I think that would help push for the best outcome for the wider > FLOSS community outside OpenStack and the rest of the world, too. > This is good information to know. > >As I described the above, we can certainly have a healthy discussion on > >what different and real problems we are facing from Asia. > >However, I don't think this TC resolution is good way to do that. > > Thanks a lot for sharing your perspective! IMHO it's very helpful. > I really love to interact more on this topic. Thanks for saying it was helpful. I do value Zhipeng's post now, since it triggered a valuable discussion across the community. :) > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Jaesuk Ahn, Team Lead Virtualization SW Lab, SW R&D Center SK Telecom -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Sep 19 13:33:39 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 19 Sep 2018 13:33:39 +0000 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> Message-ID: <20180919133338.xg6cpgbzonsp4hax@yuggoth.org> On 2018-09-19 12:57:25 +0100 (+0100), Adam Spiers wrote: > [Meta-topic: I see that this thread started as a cross-post to > openstack-{dev,operators,sigs}, but this subthread is only on -sigs, > which presumably fractures the thread. Is there an accepted best > practice addressing this problem?] [...] Not to be glib, but http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000493.html will solve it in the future for threads cross-posted to this particular set of lists. I'm in the process of preconfiguring the new list now and will follow up soon on that thread with the plan we worked out at the PTG. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From jean-philippe at evrard.me Wed Sep 19 14:47:41 2018 From: jean-philippe at evrard.me (=?utf-8?q?jean-philippe=40evrard=2Eme?=) Date: Wed, 19 Sep 2018 16:47:41 +0200 Subject: [Openstack-sigs] =?utf-8?b?Pz09P3V0Zi04P3E/ICBbdGNdR2xvYmFsIFJl?= =?utf-8?q?achout_Proposal?= In-Reply-To: <20180919133338.xg6cpgbzonsp4hax@yuggoth.org> Message-ID: <5c9c-5ba26180-11-7c22c600@62446028> > Not to be glib, but > http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000493.html > will solve it in the future for threads cross-posted to this > particular set of lists. I'm in the process of preconfiguring the > new list now and will follow up soon on that thread with the plan we > worked out at the PTG. > -- > Jeremy Stanley Thanks again for this work :) From aspiers at suse.com Wed Sep 19 14:55:01 2018 From: aspiers at suse.com (Adam Spiers) Date: Wed, 19 Sep 2018 15:55:01 +0100 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: <20180919133338.xg6cpgbzonsp4hax@yuggoth.org> References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> <20180919133338.xg6cpgbzonsp4hax@yuggoth.org> Message-ID: <20180919145501.zesnhqkyecxeguwp@pacific.linksys.moosehall> Jeremy Stanley wrote: >On 2018-09-19 12:57:25 +0100 (+0100), Adam Spiers wrote: >> [Meta-topic: I see that this thread started as a cross-post to >> openstack-{dev,operators,sigs}, but this subthread is only on -sigs, >> which presumably fractures the thread. Is there an accepted best >> practice addressing this problem?] >[...] > >Not to be glib, but >http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000493.html >will solve it in the future for threads cross-posted to this >particular set of lists. I'm in the process of preconfiguring the >new list now and will follow up soon on that thread with the plan we >worked out at the PTG. Great, thanks! I'd missed that initiative. From zbitter at redhat.com Wed Sep 19 16:09:30 2018 From: zbitter at redhat.com (Zane Bitter) Date: Wed, 19 Sep 2018 12:09:30 -0400 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> <20180919115725.n5eck36sz5trz4aw@pacific.linksys.moosehall> Message-ID: <943b962f-9ad9-42fd-b623-25479c21f27d@redhat.com> On 19/09/18 7:57 AM, Adam Spiers wrote: > [Meta-topic: I see that this thread started as a cross-post to > openstack-{dev,operators,sigs}, but this subthread is only on -sigs, > which presumably fractures the thread.  Is there an accepted best > practice addressing this problem?] My fault, I must have hit 'Reply List' instead of 'Reply All' Looking forward to all being on one list :) > Jaesuk Ahn wrote: >> On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter wrote: >>> ... >>> >>> Perhaps there are others too? >>> Obvious questions to ask from there would be: >>> - Whether this is the most important issue facing contributors from >>> the APAC region >>> - To what extent the proposed solution is expected to help >> >> I do agree with Zane on the above point. >> As one of OpenStack participants from Asia region, I will put my >> personal opinion. >> IRC and ML has been an unified and standard way of communication in >> OpenStack Community, and that has been a good way to encourage "open >> communication" on a unified method wherever you are from, or whatever >> background you have. If the whole community start recognize some other >> tools (say WeChat) as recommended alternative communication method >> because there are many people there, ironically, it might be a way to >> break "diversity" and "openness" we want to embrace. > > Agreed. > >> Using whatever social media (or tools) in a specific region due to any >> reason is not a problem. Anyone is free to use anything. Only thing we >> need to make sure is, if you want to communicate officially with the >> whole community, there is a very well defined and unified way to do >> it. This is currently IRC and ML. Some of Korean dev has difficulties >> to use IRC. > > Any chance you could clarify what kind of difficulties they are > encountering?  As several TC members and others within this thread > have already pointed out, that would help the community decide whether > those difficulties can be addressed whilst keeping IRC, or whether > it's worth considering replacing IRC with something else. > >> However, there is not a perfect tool out there in this world, and we >> accept all the reason why the community selected IRC as official tool >> But, that being said, There are some things I am facing with IRC from >> here in Korea >> >> As a person from Asia, I do have some of pain points. Because of time >> differences, often, I have to do achieve searching since most of >> conversations happened while I am sleeping. IRC is not a good tool to >> perform "search backlog". Although there is message archive you can >> dig, it is still hard. This is a problem. I do love to see any >> technical solution for me to efficiently and easily go through irc >> backlog, like most of modern chat tools. > > Would this particular pain point be solved by providing a friendly web > search interface to the IRC log archives?  BTW it is already possible to > search them via google, by including >    site:eavesdrop.openstack.org > > in the search, but of course this is not very user-friendly. >> Secondly, IRC is not a popular one even in dev community here in >> Korea. In addition, in order to properly use irc, you need to do extra >> work, something like setting up bouncing server. I had to do google >> search to figure out how to use it. > > I agree - this is probably the biggest issue with IRC, not just in Korea > or even in Asia, but globally.  People are much more aware of this pain > now because modern alternatives such as Slack, HipChat, Rocket.chat, > Matrix etc. all solve that problem without requiring any extra effort > from the user. >> In that sense, It would be great to have OpenStack community provided, >> simplified and well-written, written in multiple language, IRC guide >> docs. > > Yes, if we stick with IRC then this certainly makes sense. >> Alternatively, if OpenStack community can provide a good web-based irc >> client tool, that would be fantastic. > > It already exists: Matrix's web client Riot has a built-in bridge with > Freenode: >    https://opensource.com/article/17/5/introducing-riot-IRC > > Thinking further ahead, I have previously floated the idea of the > community switching to Matrix altogether: > > http://lists.openstack.org/pipermail/openstack-sigs/2018-March/000332.html > > I have to be honest: right now, whilst Matrix's usability is actually > pretty good, it still needs a bit of work before it gets as slick as > something like Slack.  In particular, performance of the Freenode bridge > is not always great.  But like IRC, Matrix is all open source with a > decentralized architecture, so I'm fairly confident that with a bit of > investment from the OpenStack community (whether that's financial or > developer resources), we could get it good enough for what we want. And > I think that would help push for the best outcome for the wider FLOSS > community outside OpenStack and the rest of the world, too. >> As I described the above, we can certainly have a healthy discussion >> on what different and real problems we are facing from Asia. However, >> I don't think this TC resolution is good way to do that. > > Thanks a lot for sharing your perspective!  IMHO it's very helpful. > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From zbitter at redhat.com Wed Sep 19 17:17:59 2018 From: zbitter at redhat.com (Zane Bitter) Date: Wed, 19 Sep 2018 13:17:59 -0400 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> Message-ID: <08783f7e-8201-e6ad-993b-dbb0193de536@redhat.com> On 18/09/18 9:10 PM, Jaesuk Ahn wrote: > On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter > wrote: Resotring the whole quote here because I accidentally sent the original to the -sigs list only and not the -dev list. >> As others have mentioned, I think this is diving into solutions when we haven't defined the problems. I know you mentioned it briefly in the PTG session, but that context never made it to the review or the mailing list. >> >> So AIUI the issue you're trying to solve here is that the TC members seem distant and inaccessible to Chinese contributors because we're not on the same social networks they are? >> >> Perhaps there are others too? >> >> Obvious questions to ask from there would be: >> >> - Whether this is the most important issue facing contributors from the APAC region >> >> - To what extent the proposed solution is expected to help > > > I do agree with Zane on the above point. For the record, I didn't express an opinion. I'm just pointing out what the questions are. > As one of OpenStack participants from Asia region, I will put my > personal opinion. > IRC and ML has been an unified and standard way of communication in > OpenStack Community, and that has been a good way to encourage "open > communication" on a unified method wherever you are from, or whatever > background you have. If the whole community start recognize some other > tools (say WeChat) as recommended alternative communication method > because there are many people there, ironically, it might be a way to > break "diversity" and "openness" we want to embrace. > > Using whatever social media (or tools) in a specific region due to any > reason is not a problem. Anyone is free to use anything. Only thing we > need to make sure is, if you want to communicate officially with the > whole community, there is a very well defined and unified way to do it. > This is currently IRC and ML. Some of Korean dev has difficulties to use > IRC. However, there is not a perfect tool out there in this world, and > we accept all the reason why the community selected IRC as official tool > > But, that being said, There are some things I am facing with IRC from > here in Korea > > As a person from Asia, I do have some of pain points. Because of time > differences, often, I have to do achieve searching since most of > conversations happened while I am sleeping. IRC is not a good tool to > perform "search backlog". Although there is message archive you can dig, > it is still hard. This is a problem. I do love to see any technical > solution for me to efficiently and easily go through irc backlog, like > most of modern chat tools. > > Secondly, IRC is not a popular one even in dev community here in Korea. > In addition, in order to properly use irc, you need to do extra work, > something like setting up bouncing server. I had to do google search to > figure out how to use it. I think part of the disconnect here is that people have different ideas about what IRC (and chat in general) is for. For me it's a way to conduct synchronous conversations. These tend to go badly on the mailing list (really long threads of 1 sentence per message) or on code review (have to keep refreshing), so it's good that we have another tool to do this. I answer a lot of user questions, clarify comments on patches, and obviously join team meetings in IRC. The key part is 'synchronous' though. If I'm not there, the conversation is not going to be synchronous. I don't run a bouncer, although I generally leave my computer running when I'm not working so you'll often (but not always) be able to ping me, and I'll usually look back to see if it was something important. Otherwise it's 50-50 whether I'll even bother to read scrollback, and certainly not for more than a couple of channels. Other people, however, have a completely different perspective: they want a place where they are guaranteed to be reachable at any time (even if they don't see it until later) and the entire record is always right there. I think Slack was built for those kinds of people. You would have to drag me kicking and screaming into Slack even if it weren't proprietary software. I don't know where WeChat falls on that spectrum. But maybe part of the issue is that we're creating too high an expectation of what it means to participate in the community (e.g. if you're not going to set up a bouncer and be reachable 24/7 then you might as well not get involved at all - this is 100% untrue). I've seen several assertions, including in the review, that any decisions must be documented on the mailing list or IRC, and I'm not sure I agree. IMHO, any decisions should be documented on the mailing list, period. I'd love to see more participation on the mailing list. Since it is asynchronous already it's somewhat friendlier to those in APAC time zones (although there are still issues, real or perceived, with decisions being reached before anyone on that side of the world has a chance to weigh in), and a lot easier than carrying on a conversation in real time for those who don't speak English natively. And while can still be technical challenges with mailing lists, almost every company allows email through their corporate firewall. AIUI though, augmenting IRC was not the point of the proposal. Rather, I think it was for TC members to 'fly the flag' in WeChat to be more visible and available to the portion of the community that is there. > In that sense, It would be great to have > OpenStack community provided, simplified and well-written, written in > multiple language, IRC guide docs. Alternatively, if OpenStack community > can provide a good web-based irc client tool, that would be fantastic. I haven't tried it but: https://webchat.freenode.net/ > As I described the above, we can certainly have a healthy discussion on > what different and real problems we are facing from Asia. > However, I don't think this TC resolution is good way to do that. > > Cheers, > -- > > Jaesuk Ahn, Team Lead > Virtualization SW Lab, SW R&D Center > > SK Telecom > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > From mrhillsman at gmail.com Wed Sep 19 17:33:33 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Wed, 19 Sep 2018 12:33:33 -0500 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: <08783f7e-8201-e6ad-993b-dbb0193de536@redhat.com> References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> <08783f7e-8201-e6ad-993b-dbb0193de536@redhat.com> Message-ID: Regarding some web clients that are potentially useful https://webchat.freenode.net/ - Zane mentioned this already and I can say I tried/used it some time ago until I opted for CLI/alternatives https://riot.im (iOS and Android apps available along with online client) - i find it a bit sluggish at times, others have not, either way it is a decent alternative https://thelounge.chat/ - have not tried it yet but looks promising especially self-hosted option https://irccloud.com - what I currently use, I do believe it can be blocked, i am looking into riot and thelounge tbh On Wed, Sep 19, 2018 at 12:18 PM Zane Bitter wrote: > On 18/09/18 9:10 PM, Jaesuk Ahn wrote: > > On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter > > wrote: > > Resotring the whole quote here because I accidentally sent the original > to the -sigs list only and not the -dev list. > > >> As others have mentioned, I think this is diving into solutions when we > haven't defined the problems. I know you mentioned it briefly in the PTG > session, but that context never made it to the review or the mailing list. > >> > >> So AIUI the issue you're trying to solve here is that the TC members > seem distant and inaccessible to Chinese contributors because we're not on > the same social networks they are? > >> > >> Perhaps there are others too? > >> > >> Obvious questions to ask from there would be: > >> > >> - Whether this is the most important issue facing contributors from the > APAC region > >> > >> - To what extent the proposed solution is expected to help > > > > > > I do agree with Zane on the above point. > > For the record, I didn't express an opinion. I'm just pointing out what > the questions are. > > > As one of OpenStack participants from Asia region, I will put my > > personal opinion. > > IRC and ML has been an unified and standard way of communication in > > OpenStack Community, and that has been a good way to encourage "open > > communication" on a unified method wherever you are from, or whatever > > background you have. If the whole community start recognize some other > > tools (say WeChat) as recommended alternative communication method > > because there are many people there, ironically, it might be a way to > > break "diversity" and "openness" we want to embrace. > > > > Using whatever social media (or tools) in a specific region due to any > > reason is not a problem. Anyone is free to use anything. Only thing we > > need to make sure is, if you want to communicate officially with the > > whole community, there is a very well defined and unified way to do it. > > This is currently IRC and ML. Some of Korean dev has difficulties to use > > IRC. However, there is not a perfect tool out there in this world, and > > we accept all the reason why the community selected IRC as official tool > > > > But, that being said, There are some things I am facing with IRC from > > here in Korea > > > > As a person from Asia, I do have some of pain points. Because of time > > differences, often, I have to do achieve searching since most of > > conversations happened while I am sleeping. IRC is not a good tool to > > perform "search backlog". Although there is message archive you can dig, > > it is still hard. This is a problem. I do love to see any technical > > solution for me to efficiently and easily go through irc backlog, like > > most of modern chat tools. > > > > Secondly, IRC is not a popular one even in dev community here in Korea. > > In addition, in order to properly use irc, you need to do extra work, > > something like setting up bouncing server. I had to do google search to > > figure out how to use it. > > I think part of the disconnect here is that people have different ideas > about what IRC (and chat in general) is for. > > For me it's a way to conduct synchronous conversations. These tend to go > badly on the mailing list (really long threads of 1 sentence per > message) or on code review (have to keep refreshing), so it's good that > we have another tool to do this. I answer a lot of user questions, > clarify comments on patches, and obviously join team meetings in IRC. > > The key part is 'synchronous' though. If I'm not there, the conversation > is not going to be synchronous. I don't run a bouncer, although I > generally leave my computer running when I'm not working so you'll often > (but not always) be able to ping me, and I'll usually look back to see > if it was something important. Otherwise it's 50-50 whether I'll even > bother to read scrollback, and certainly not for more than a couple of > channels. > > Other people, however, have a completely different perspective: they > want a place where they are guaranteed to be reachable at any time (even > if they don't see it until later) and the entire record is always right > there. I think Slack was built for those kinds of people. You would have > to drag me kicking and screaming into Slack even if it weren't > proprietary software. > > I don't know where WeChat falls on that spectrum. But maybe part of the > issue is that we're creating too high an expectation of what it means to > participate in the community (e.g. if you're not going to set up a > bouncer and be reachable 24/7 then you might as well not get involved at > all - this is 100% untrue). I've seen several assertions, including in > the review, that any decisions must be documented on the mailing list or > IRC, and I'm not sure I agree. IMHO, any decisions should be documented > on the mailing list, period. > > I'd love to see more participation on the mailing list. Since it is > asynchronous already it's somewhat friendlier to those in APAC time > zones (although there are still issues, real or perceived, with > decisions being reached before anyone on that side of the world has a > chance to weigh in), and a lot easier than carrying on a conversation in > real time for those who don't speak English natively. And while can > still be technical challenges with mailing lists, almost every company > allows email through their corporate firewall. > > AIUI though, augmenting IRC was not the point of the proposal. Rather, I > think it was for TC members to 'fly the flag' in WeChat to be more > visible and available to the portion of the community that is there. > > > In that sense, It would be great to have > > OpenStack community provided, simplified and well-written, written in > > multiple language, IRC guide docs. Alternatively, if OpenStack community > > can provide a good web-based irc client tool, that would be fantastic. > > I haven't tried it but: https://webchat.freenode.net/ > > > As I described the above, we can certainly have a healthy discussion on > > what different and real problems we are facing from Asia. > > However, I don't think this TC resolution is good way to do that. > > > > Cheers, > > -- > > > > Jaesuk Ahn, Team Lead > > Virtualization SW Lab, SW R&D Center > > > > SK Telecom > > > > > > _______________________________________________ > > openstack-sigs mailing list > > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekcs.openstack at gmail.com Wed Sep 19 21:03:50 2018 From: ekcs.openstack at gmail.com (Eric K) Date: Wed, 19 Sep 2018 14:03:50 -0700 Subject: [Openstack-sigs] [self-healing] poll for sessions at berlin forum Message-ID: Hi all, Please complete this short poll [1] asap so we can request the appropriate sessions and times for the SIG at the berlin summit forum. Our request to forum organizers is expected by 9/21. Thanks so much! Eric Kao [1] https://docs.google.com/forms/d/e/1FAIpQLScUguawt-28FR-O83eEaNAbL1Fkb3b23UHBAeEKVkaFDXusWA/viewform From zhipengh512 at gmail.com Wed Sep 19 23:15:51 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 20 Sep 2018 07:15:51 +0800 Subject: [Openstack-sigs] [tc]Global Reachout Proposal In-Reply-To: References: <55c81a61-5670-c1c3-20f1-aa4d8153c8a2@redhat.com> <08783f7e-8201-e6ad-993b-dbb0193de536@redhat.com> Message-ID: A quick sidenote for anyone is using riot.im but not super familiar with it like I did ... Its global search could not cache all the openstack channels, therefore you have to manually join them via their own cmd lines as I recently discover the methods .. 1. add @appservice-irc:matrix.org for friend 2. type in the console : !join chat.freenode.net #openstack-xxx For registration, it is more wacky but I found it on google anyways: 1. add @appservice-irc:matrix.org for friend 2. type in the console : !storepass chat.freenode.net PASSWORD 3. add NickServ(IRC) for friend 4. type in the console : identify NICK PASSWORD viola .... On Thu, Sep 20, 2018 at 1:34 AM Melvin Hillsman wrote: > Regarding some web clients that are potentially useful > > https://webchat.freenode.net/ > - Zane mentioned this already and I can say I tried/used it some time > ago until I opted for CLI/alternatives > https://riot.im (iOS and Android apps available along with online client) > - i find it a bit sluggish at times, others have not, either way it is a > decent alternative > https://thelounge.chat/ > - have not tried it yet but looks promising especially self-hosted option > https://irccloud.com > - what I currently use, I do believe it can be blocked, i am looking > into riot and thelounge tbh > > > On Wed, Sep 19, 2018 at 12:18 PM Zane Bitter wrote: > >> On 18/09/18 9:10 PM, Jaesuk Ahn wrote: >> > On Wed, Sep 19, 2018 at 5:30 AM Zane Bitter > > > wrote: >> >> Resotring the whole quote here because I accidentally sent the original >> to the -sigs list only and not the -dev list. >> >> >> As others have mentioned, I think this is diving into solutions when >> we haven't defined the problems. I know you mentioned it briefly in the PTG >> session, but that context never made it to the review or the mailing list. >> >> >> >> So AIUI the issue you're trying to solve here is that the TC members >> seem distant and inaccessible to Chinese contributors because we're not on >> the same social networks they are? >> >> >> >> Perhaps there are others too? >> >> >> >> Obvious questions to ask from there would be: >> >> >> >> - Whether this is the most important issue facing contributors from >> the APAC region >> >> >> >> - To what extent the proposed solution is expected to help >> > >> > >> > I do agree with Zane on the above point. >> >> For the record, I didn't express an opinion. I'm just pointing out what >> the questions are. >> >> > As one of OpenStack participants from Asia region, I will put my >> > personal opinion. >> > IRC and ML has been an unified and standard way of communication in >> > OpenStack Community, and that has been a good way to encourage "open >> > communication" on a unified method wherever you are from, or whatever >> > background you have. If the whole community start recognize some other >> > tools (say WeChat) as recommended alternative communication method >> > because there are many people there, ironically, it might be a way to >> > break "diversity" and "openness" we want to embrace. >> > >> > Using whatever social media (or tools) in a specific region due to any >> > reason is not a problem. Anyone is free to use anything. Only thing we >> > need to make sure is, if you want to communicate officially with the >> > whole community, there is a very well defined and unified way to do it. >> > This is currently IRC and ML. Some of Korean dev has difficulties to >> use >> > IRC. However, there is not a perfect tool out there in this world, and >> > we accept all the reason why the community selected IRC as official tool >> > >> > But, that being said, There are some things I am facing with IRC from >> > here in Korea >> > >> > As a person from Asia, I do have some of pain points. Because of time >> > differences, often, I have to do achieve searching since most of >> > conversations happened while I am sleeping. IRC is not a good tool to >> > perform "search backlog". Although there is message archive you can >> dig, >> > it is still hard. This is a problem. I do love to see any technical >> > solution for me to efficiently and easily go through irc backlog, like >> > most of modern chat tools. >> > >> > Secondly, IRC is not a popular one even in dev community here in Korea. >> > In addition, in order to properly use irc, you need to do extra work, >> > something like setting up bouncing server. I had to do google search to >> > figure out how to use it. >> >> I think part of the disconnect here is that people have different ideas >> about what IRC (and chat in general) is for. >> >> For me it's a way to conduct synchronous conversations. These tend to go >> badly on the mailing list (really long threads of 1 sentence per >> message) or on code review (have to keep refreshing), so it's good that >> we have another tool to do this. I answer a lot of user questions, >> clarify comments on patches, and obviously join team meetings in IRC. >> >> The key part is 'synchronous' though. If I'm not there, the conversation >> is not going to be synchronous. I don't run a bouncer, although I >> generally leave my computer running when I'm not working so you'll often >> (but not always) be able to ping me, and I'll usually look back to see >> if it was something important. Otherwise it's 50-50 whether I'll even >> bother to read scrollback, and certainly not for more than a couple of >> channels. >> >> Other people, however, have a completely different perspective: they >> want a place where they are guaranteed to be reachable at any time (even >> if they don't see it until later) and the entire record is always right >> there. I think Slack was built for those kinds of people. You would have >> to drag me kicking and screaming into Slack even if it weren't >> proprietary software. >> >> I don't know where WeChat falls on that spectrum. But maybe part of the >> issue is that we're creating too high an expectation of what it means to >> participate in the community (e.g. if you're not going to set up a >> bouncer and be reachable 24/7 then you might as well not get involved at >> all - this is 100% untrue). I've seen several assertions, including in >> the review, that any decisions must be documented on the mailing list or >> IRC, and I'm not sure I agree. IMHO, any decisions should be documented >> on the mailing list, period. >> >> I'd love to see more participation on the mailing list. Since it is >> asynchronous already it's somewhat friendlier to those in APAC time >> zones (although there are still issues, real or perceived, with >> decisions being reached before anyone on that side of the world has a >> chance to weigh in), and a lot easier than carrying on a conversation in >> real time for those who don't speak English natively. And while can >> still be technical challenges with mailing lists, almost every company >> allows email through their corporate firewall. >> >> AIUI though, augmenting IRC was not the point of the proposal. Rather, I >> think it was for TC members to 'fly the flag' in WeChat to be more >> visible and available to the portion of the community that is there. >> >> > In that sense, It would be great to have >> > OpenStack community provided, simplified and well-written, written in >> > multiple language, IRC guide docs. Alternatively, if OpenStack >> community >> > can provide a good web-based irc client tool, that would be fantastic. >> >> I haven't tried it but: https://webchat.freenode.net/ >> >> > As I described the above, we can certainly have a healthy discussion on >> > what different and real problems we are facing from Asia. >> > However, I don't think this TC resolution is good way to do that. >> > >> > Cheers, >> > -- >> > >> > Jaesuk Ahn, Team Lead >> > Virtualization SW Lab, SW R&D Center >> > >> > SK Telecom >> > >> > >> > _______________________________________________ >> > openstack-sigs mailing list >> > openstack-sigs at lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > >> >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > > -- > Kind regards, > > Melvin Hillsman > mrhillsman at gmail.com > mobile: (832) 264-2646 > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspiers at suse.com Thu Sep 20 01:47:47 2018 From: aspiers at suse.com (Adam Spiers) Date: Thu, 20 Sep 2018 02:47:47 +0100 Subject: [Openstack-sigs] [self-healing] poll for sessions at berlin forum In-Reply-To: References: Message-ID: <20180920014747.q24mt5dkr6s4n2di@pacific.linksys.moosehall> Eric Kao wrote: >Hi all, >Please complete this short poll [1] asap so we can request the >appropriate sessions and times for the SIG at the berlin summit forum. >Our request to forum organizers is expected by 9/21. Thanks so much! Yikes, lucky you are so on top of this because I had totally missed that deadline! Once again thanks a lot for saving the day Eric! ;-D From kennelson11 at gmail.com Thu Sep 20 05:23:26 2018 From: kennelson11 at gmail.com (Kendall Nelson) Date: Wed, 19 Sep 2018 22:23:26 -0700 Subject: [Openstack-sigs] [First Contact] SIG PTG Summary Message-ID: Hello Everyone! The first half of the week was particularly busy and I know a lot of people wanted to come to the First Contact SIG room that could not, or couldn’t be there for the whole time. So! For those of you interested that maybe couldn’t make it for the whole time, here is a beautiful summary :) And the etherpad if you want that too[1]. State of the Union ============== We started off with a state of the union on all of the outreach/new contributor groups to get everyone involved on the same page so we can better disseminate the info to new comers and potential contributors. Outreachy -------------- The winter round of applications for mentees opens the 19th and remains open until October 30th. There are two Outreachy internships sponsored for this round[2]. Close to the end of this round of internships- they end in March- the next round will kickoff sponsorships and applications for projects in February. Google Summer of Code --------------------------------- We applied and were not accepted last year. We would like to urge the community to apply again. There’s no info on when applications will open to organisations to apply for interns. OpenStack Upstream Institute ---------------------------------------- We continue to offer this before each summit and at a variety of OpenStack Day and OpenInfra Day events. Over the last year we have held the training in Vancouver, Seoul, Krakow, Sao Paulo, and Rio de Janiero. In October, the training will be held at OpenStack Day Nordics in Stockholm[3] and preceeding the summit in Berlin[4]. A modified version will also be held at the Open Source Day at the upcoming Grace Hopper Conference in Houston[5]. Cohort Mentoring Program ----------------------------------- Formerly the Longterm Mentoring Program organized by the Women of OpenStack, the mentoring program has changed hands and gotten a facelift. The program is now cohort style- groups of mentees and mentors focusing on a single goal like passing the COA, or getting your first patch merged- rather than the 1x1 loosely timeboxed model. Its also now organized and mediated by the Diversity Working Group. If you are interested in getting involved, more details are here[6]. Organization Guide =============== Back in Sydney, we started discussing creating a guide for organizations to educate them on what their contributors need to be effective and successful members of the community. There is a patch out for review right now[7] that we want to get merged as soon as possible so that we can publicize it in Berlin and start introducing it when new companies join the foundation. It was concluded that we needed to add more rationalizations to the requirements and we delegated those out to ricolin, jungleboyj, and spotz to help mattoliverau with content. As soon as this patch gets merged, I volunteered to work to get it onto the soonest board meeting possible. Operator Inclusion/ Ops Feedback ========================== Unfortunately, many operators were in the Operators room- yeah..they got scheduled to overlap..oh well. We did have a few representatives join us though. Basically we concluded that the operator section of the Contributor Guide is wholly unattractive as it’s a daunting outline of a bunch of things that aren’t immediately obvious as important to Operators. It needs to be broken up and the ‘Allows you to’ subsections of each part of the outline need to be moved up to the top level so that operators can more easily see and understand why sections of it are important. There are a few other cosmetic things that also need to be resolved- more details are in the etherpad from Tuesday’s discussions lines 49-62[1]. The operators are also currently trying to get their docs up and running again after having been unsupported, partially migrated to wikis, and then moved back to a repository. Once these are a little more fleshed out and settled, we will link to them from the Contributor Guide. I also attended the Operator’s room on Monday and tried to put a call out for a single point of contact, like a project liaison, so that any operators we see asking for help or resources can be directed to that point of contact. No one stepped up during the meeting, but its still something we see as being important, and will keep pushing to get one or two names to direct new operators to. Forum Proposals ============= Submissions are now open! We have an etherpad from the brainstorming period[8], but basically we want a forum session that will focus on the Operator section of the Contributor guide and jimmymacarthur volunteered to write up and submit this. The only other topic we really discussed around Berlin was a Meet & Greet sort of room that we would request during the call for BoF’s for the summit. This call recently went out, and I will put in the request by the end of the week. Translation of the Contributor Guide =========================== Basically, we want it translated- code & docs, operators, users, and organisations sections; all of it. The discussion focused on a lot of the nitty gritty- what sort of translators would be interested in helping- technical or more high level translators. What is our timeline? When would our string freezes be? The todo’s that came about were for me to talk to ashfergs about getting this on the discussion docket for the Ambassadors and to help ianychoi with setting up the connection between the repo and zanata. Contributor Landing Page on Docs.o.o ============================= This was a short discussion with pkovar about how we might want to style this. We talked about having links into the various parts of the contributor guide and having a list of links to all of the contribution sections of the project specific docs. No real todo’s came out of this, but its definitely something we will want to circle back to once some of the other day’s todo’s get accomplished. Summary & Contacting Us Further ========================== Lots happened and I am probably missing things (it was already a week ago and it was a bit chaotic at times), but I think I hit on most of the big stuff. Good news is we had a few people step up to take things on so its not all on me ;) We continue our biweekly meetings at 7:00 UTC in #openstack-meeting if you can join us! Otherwise we mostly all live on IRC in a variety of channels #openstack-dev, #openstack-upstream-institute, #openstack-doc. Our irc nicks and timezones are listed on our wikipage here[9]! If asynchronous communication is more your style, we use the [First Contact] tag on both the openstack-sigs and openstack-dev mailing lists. See you around :) -Kendall Nelson (diablo_rojo) [1] https://etherpad.openstack.org/p/FC_SIG_ptg_stein [2] https://www.outreachy.org/apply/project-selection/ [3] http://stockholm.openstacknordic.org/program [4] https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=Upstream+Institute [5] https://ghc.anitab.org/2018-attend/schedule-overview/open-source-day/ [6] https://wiki.openstack.org/wiki/Mentoring#Long_Term_Mentoring [7] https://review.openstack.org/#/c/578676 [8] https://etherpad.openstack.org/p/FC_SIG_BER_Planning [9] https://wiki.openstack.org/wiki/First_Contact_SIG -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengh512 at gmail.com Thu Sep 20 08:39:43 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 20 Sep 2018 16:39:43 +0800 Subject: [Openstack-sigs] [openstack-dev] [Openstack-operators] [tc]Global Reachout Proposal In-Reply-To: <96743b2c-7d12-0769-9176-746c2d4edbbe@anteaya.info> References: <165ea808b5b.e023df6f175915.5632015242635271704@ghanshyammann.com> <20180918124049.jw7xbufikxfx3w37@yuggoth.org> <96743b2c-7d12-0769-9176-746c2d4edbbe@anteaya.info> Message-ID: Thanks Anita, will definitely do as you kindly suggested :) On Thu, Sep 20, 2018, 12:04 PM Anita Kuno wrote: > On 2018-09-18 08:40 AM, Jeremy Stanley wrote: > > On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: > > [...] > >> I can understand that IRC cannot be used in China which is very > >> painful and mostly it is used weChat. > > [...] > > > > I have yet to hear anyone provide first-hand confirmation that > > access to Freenode's IRC servers is explicitly blocked by the > > mainland Chinese government. There has been a lot of speculation > > that the usual draconian corporate firewall policies (surprise, the > > rest of the World gets to struggle with those too, it's not just a > > problem in China) are blocking a variety of messaging protocols from > > workplace networks and the people who encounter this can't tell the > > difference because they're already accustomed to much of their other > > communications being blocked at the border. I too have heard from > > someone who's heard from someone that "IRC can't be used in China" > > but the concrete reasons why continue to be missing from these > > discussions. > > > > I'll reply to this email arbitrarily in order to comply with Zhipeng > Huang's wishes that the conversation concerned with understanding the > actual obstacles to communication takes place on the mailing list. I do > hope I am posting to the correct thread. > > In response to part of your comment on the patch at > https://review.openstack.org/#/c/602697/ which you posted about 5 hours > ago you said "@Anita you are absolutely right it is only me stuck my > head out speaks itself the problem I stated in the patch. Many of the > community tools that we are comfortable with are not that accessible to > a broader ecosystem. And please assured that I meant I refer the patch > to the Chinese community, as Leong also did on the ML, to try to bring > them over to join the convo." and I would like to reply. > > I would like to say that I am honoured by your generosity. Thank you. > Now, when the Chinese community consumes the patch, as well as the > conversation in the comments, please encourage folks to ask for > clarification if any descriptions or phrases don't make sense to them. > One of the best ways of ensuring clear communication is to start off > slowly and take the time to ask what the other side means. It can seem > tedious and a waste of time, but I have found it to be very educational > and helpful in understanding how the other person perceives the > situation. It also helps me to understand how I am creating obstacles in > ways that I talk. > > Taking time to clarify helps me to adjust how I am speaking so that my > meaning is more likely to be understood by the group to which I am > trying to offer my perspective. I do appreciate that many people are > trying to avoid embarrassment, but I have never found any way to > understand people in a culture that is not the one I group up in, other > than embarrassing myself and working through it. Usually I find the > group I am wanting to understand is more than willing to rescue me from > my embarrassment and support me in my learning. In a strange way, the > embarrassment is kind of helpful in order to create understanding > between myself and those people I am trying to understand. > > Thank you, Anita > > __________________________________________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Thu Sep 20 14:19:46 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Sep 2018 09:19:46 -0500 Subject: [Openstack-sigs] [openstack-dev] Forum Topic Submission Period In-Reply-To: <5B9FD2BB.3060806@openstack.org> References: <5B9FD2BB.3060806@openstack.org> Message-ID: <51580429-12ad-04b8-0efa-e11a14eaa87b@gmail.com> On 9/17/2018 11:13 AM, Jimmy McArthur wrote: > The Forum Topic Submission session started September 12 and will run > through September 26th.  Now is the time to wrangle the topics you > gathered during your Brainstorming Phase and start pushing forum topics > through. Don't rely only on a PTL to make the agenda... step on up and > place the items you consider important front and center. > > As you may have noticed on the Forum Wiki > (https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP > tool this year. We did our best to remove Summit specific language, but > if you notice something, just know that you are submitting to the > Forum.  URL is here: > > https://www.openstack.org/summit/berlin-2018/call-for-presentations > > Looking forward to seeing everyone's submissions! > > If you have questions or concerns about the process, please don't > hesitate to reach out. Another question. In the before times, when we just had that simple form to submit forum sessions and then the TC/UC/Foundation reviewed the list and picked the sessions, it was very simple to see what other sessions were proposed and say, "oh good someone is covering this already, I don't need to worry about it". With the move to the CFP forms like the summit sessions, that is no longer available, as far as I know. There have been at least a few cases this week where someone has said, "this might be a good topic, but keystone is probably already covering it, or $FOO SIG is probably already covering it", but without herding the cats to ask and find out who is all doing what, it's hard to know. Is there some way we can get back to having a public view of what has been proposed for the forum so we an avoid overlap, or at worst not proposing something because people assume someone else is going to cover it? -- Thanks, Matt From mriedemos at gmail.com Thu Sep 20 16:27:25 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 20 Sep 2018 11:27:25 -0500 Subject: [Openstack-sigs] [openstack-dev] Forum Topic Submission Period In-Reply-To: <5BA3BB5D.3060404@openstack.org> References: <5B9FD2BB.3060806@openstack.org> <51580429-12ad-04b8-0efa-e11a14eaa87b@gmail.com> <5BA3BB5D.3060404@openstack.org> Message-ID: On 9/20/2018 10:23 AM, Jimmy McArthur wrote: > This is basically the CFP equivalent: > https://www.openstack.org/summit/berlin-2018/vote-for-speakers  Voting > isn't necessary, of course, but it should allow you to see submissions > as they roll in. > > Does this work for your purposes? Yup, that should do it, thanks! -- Thanks, Matt From jimmy at openstack.org Thu Sep 20 15:23:09 2018 From: jimmy at openstack.org (Jimmy McArthur) Date: Thu, 20 Sep 2018 10:23:09 -0500 Subject: [Openstack-sigs] [openstack-dev] Forum Topic Submission Period In-Reply-To: <51580429-12ad-04b8-0efa-e11a14eaa87b@gmail.com> References: <5B9FD2BB.3060806@openstack.org> <51580429-12ad-04b8-0efa-e11a14eaa87b@gmail.com> Message-ID: <5BA3BB5D.3060404@openstack.org> Matt, Another good question... Matt Riedemann wrote: > On 9/17/2018 11:13 AM, Jimmy McArthur wrote: >> SNIP > > Another question. In the before times, when we just had that simple > form to submit forum sessions and then the TC/UC/Foundation reviewed > the list and picked the sessions, it was very simple to see what other > sessions were proposed and say, "oh good someone is covering this > already, I don't need to worry about it". With the move to the CFP > forms like the summit sessions, that is no longer available, as far as > I know. There have been at least a few cases this week where someone > has said, "this might be a good topic, but keystone is probably > already covering it, or $FOO SIG is probably already covering it", but > without herding the cats to ask and find out who is all doing what, > it's hard to know. > > Is there some way we can get back to having a public view of what has > been proposed for the forum so we an avoid overlap, or at worst not > proposing something because people assume someone else is going to > cover it? This is basically the CFP equivalent: https://www.openstack.org/summit/berlin-2018/vote-for-speakers Voting isn't necessary, of course, but it should allow you to see submissions as they roll in. Does this work for your purposes? Thanks, Jimmy From fungi at yuggoth.org Thu Sep 20 16:32:49 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 20 Sep 2018 16:32:49 +0000 Subject: [Openstack-sigs] [all] We're combining the lists! (was: Bringing the community together...) In-Reply-To: <20180830170350.wrz4wlanb276kncb@yuggoth.org> References: <20180830170350.wrz4wlanb276kncb@yuggoth.org> Message-ID: <20180920163248.oia5t7zjqcfwluwz@yuggoth.org> tl;dr: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-discuss at lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. Now on to the details... The original proposal[1] I cross-posted to these lists in August received overwhelmingly positive feedback (indeed only one strong objection[2] was posted, thanks Thomas for speaking up, and my apologies in advance if this makes things less convenient for you), which is unusual since our community usually tends to operate on silent assent and tacit agreement. Seeing what we can only interpret as majority consensus for the plan among the people reading messages posted to these lists, a group of interested individuals met last week in the Infrastructure team room at the PTG to work out the finer details[3]. We devised a phased timeline: During the first phase (which begins with this announcement) the new openstack-discuss mailing list will accept subscriptions but not posts. Its short and full descriptions indicate this, as does the welcome message sent to all new subscribers during this phase. The list is configured for "emergency moderation" mode so that all posts, even those from subscribers, immediately land in the moderation queue and can be rejected with an appropriate message. We strongly recommend everyone who is on any of the current general openstack, openstack-dev, openstack-operators and openstack-sigs lists subscribe to openstack-discuss during this phase in order to avoid missing any messages to the new list. Phase one lasts roughly one month and ends on Monday November 19, just after the OpenStack Stein Summit in Berlin. The second phase picks up at the end of the first. During this phase, emergency moderation is no longer in effect and subscribers can post to the list normally (non-subscribers are subject to moderation of course in order to limit spam). Any owners/moderators from the original lists who wish it will be added to the new one to collaborate on moderation tasks. At this time the openstack-discuss list address itself will be subscribed to posts from the openstack, openstack-dev, openstack-operators and openstack-sigs mailing lists so anyone who wishes to unsubscribe from those can do so at any time during this phase without missing any replies sent there. The list descriptions and welcome message will also be updated to their production prose. Phase two runs for two weeks ending on Monday December 3. The third and final phase begins at the end of the second, when further posts to the general openstack, openstack-dev, openstack-operators and openstack-sigs lists will be refused and the descriptions for those lists updated to indicate they're indefinitely retired from use. The old archives will still be preserved of course, but no new content will appear in them. A note about DMARC/DKIM: during the planning discussion we also spoke briefly about the problems we encounter on the current lists whereby subscriber MTAs which check DKIM signatures appearing in some posts reject them and cause those subscribers to get unsubscribed after too many of these bounces. While reviewing the various possible mitigation options available to us, we eventually resolved that the least objectionable solution was to cease modifying the list subject and body. As such, for the new openstack-discuss list you won't see [openstack-discuss] prepended to message subjects, and there will be no list footer block added to the message body. Rest assured the usual RFC 2369 List-* headers[4] will still be added so MUAs can continue to take filtering actions based on them as on our other lists. I'm also including a couple of FAQs which have come up over the course of this... Why make a new list instead of just directing people to join an existing one such as the openstack general ML? For one, the above list behavior change to address DMARC/DKIM issues is a good reason to want a new list; making those changes to any of the existing lists is already likely to be disruptive anyway as subscribers may be relying on the subject mangling for purposes of filtering list traffic. Also as noted earlier in the thread for the original proposal, we have many suspected defunct subscribers who are not bouncing (either due to abandoned mailboxes or MTAs black-holing them) so this is a good opportunity to clean up the subscriber list and reduce the overall amount of E-mail unnecessarily sent by the server. Why not simply auto-subscribe everyone from the four older lists to the new one and call it a day? Well, I personally would find it rude if a list admin mass-subscribed me to a mailing list I hadn't directly requested. Doing so may even be illegal in some jurisdictions (we could probably make a case that it's warranted, but it's cleaner to not need to justify such an action). Much like the answer to the previous question, the changes in behavior (and also in the list name itself) are likely to cause lots of subscribers to need to update their message filtering rules anyway. I know by default it would all start landing in my main inbox, and annoy me mightily. What subject tags are we going to be using to identify messages of interest and to be able to skip those we don't care about? We're going to continuously deploy a list of recommended subject tags in a visible space, either on the listserv's WebUI or the Infra Manual and link to it liberally. There is already an initial set of suggestions[5] being brainstormed, so feel free to add any there you feel might be missing. It's not yet been decided whether we'll also include these in the Mailman "Topics" configuration to enable server-side filtering on them (as there's a good chance we'll be unable to continue supporting that after an upgrade to Mailman 3), so for now it's best to assume you may need to add them to your client-side filters if you rely on that capability. If you have any further questions, please feel free to respond to this announcement so we can make sure they're answered. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000493.html [2] http://lists.openstack.org/pipermail/openstack-dev/2018-August/134074.html [3] https://etherpad.openstack.org/p/infra-ptg-denver-2018 [4] https://www.ietf.org/rfc/rfc2369.txt [5] https://etherpad.openstack.org/p/common-openstack-ml-topics -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From mrhillsman at gmail.com Thu Sep 20 22:30:32 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Thu, 20 Sep 2018 17:30:32 -0500 Subject: [Openstack-sigs] Capturing Feedback/Input Message-ID: Hey everyone, During the TC meeting at the PTG we discussed the ideal way to capture user-centric feedback; particular from our various groups like SIGs, WGs, etc. Options that were mentioned ranged from a wiki page to a standalone solution like discourse. While there is no perfect solution it was determined that Storyboard could facilitate this. It would play out where there is a project group openstack-uc? and each of the SIGs, WGs, etc would have a project under this group; if I am wrong someone else in the room correct me. The entire point is a first step (maybe final) in centralizing user-centric feedback that does not require any extra overhead be it cost, time, or otherwise. Just kicking off a discussion so others have a chance to chime in before anyone pulls the plug or pushes the button on anything and we settle as a community on what makes sense. -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhipengh512 at gmail.com Thu Sep 20 22:40:56 2018 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Fri, 21 Sep 2018 06:40:56 +0800 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: References: Message-ID: big +1, really look forward to the storyboard setup On Fri, Sep 21, 2018 at 6:31 AM Melvin Hillsman wrote: > Hey everyone, > > During the TC meeting at the PTG we discussed the ideal way to capture > user-centric feedback; particular from our various groups like SIGs, WGs, > etc. > > Options that were mentioned ranged from a wiki page to a standalone > solution like discourse. > > While there is no perfect solution it was determined that Storyboard could > facilitate this. It would play out where there is a project group > openstack-uc? and each of the SIGs, WGs, etc would have a project under > this group; if I am wrong someone else in the room correct me. > > The entire point is a first step (maybe final) in centralizing > user-centric feedback that does not require any extra overhead be it cost, > time, or otherwise. Just kicking off a discussion so others have a chance > to chime in before anyone pulls the plug or pushes the button on anything > and we settle as a community on what makes sense. > > -- > Kind regards, > > Melvin Hillsman > mrhillsman at gmail.com > mobile: (832) 264-2646 > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng at huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipengh at uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Fri Sep 21 00:21:53 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 20 Sep 2018 19:21:53 -0500 Subject: [Openstack-sigs] [openstack-dev] Capturing Feedback/Input In-Reply-To: References: Message-ID: <20180921002152.GB16789@sm-workstation> On Thu, Sep 20, 2018 at 05:30:32PM -0500, Melvin Hillsman wrote: > Hey everyone, > > During the TC meeting at the PTG we discussed the ideal way to capture > user-centric feedback; particular from our various groups like SIGs, WGs, > etc. > > Options that were mentioned ranged from a wiki page to a standalone > solution like discourse. > > While there is no perfect solution it was determined that Storyboard could > facilitate this. It would play out where there is a project group > openstack-uc? and each of the SIGs, WGs, etc would have a project under > this group; if I am wrong someone else in the room correct me. > > The entire point is a first step (maybe final) in centralizing user-centric > feedback that does not require any extra overhead be it cost, time, or > otherwise. Just kicking off a discussion so others have a chance to chime > in before anyone pulls the plug or pushes the button on anything and we > settle as a community on what makes sense. > > -- > Kind regards, > > Melvin Hillsman I think Storyboard would be a good place to manage SIG/WG feedback. It will take some time before the majority of projects have moved over from Launchpad, but once they do, this will make it much easier to track SIG initiatives all the way through to code implementation. From rico.lin.guanyu at gmail.com Fri Sep 21 03:42:56 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Fri, 21 Sep 2018 11:42:56 +0800 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: References: Message-ID: On Fri, Sep 21, 2018 at 6:31 AM Melvin Hillsman wrote: > > During the TC meeting at the PTG we discussed the ideal way to capture user-centric feedback; particular from our various groups like SIGs, WGs, etc. And I'm so glad to have you there to provide valuable inputs > Options that were mentioned ranged from a wiki page to a standalone solution like discourse. > > While there is no perfect solution it was determined that Storyboard could facilitate this. It would play out where there is a project group openstack-uc? and each of the SIGs, WGs, etc would have a project under this group; if I am wrong someone else in the room correct me. I like the idea to have an openstack-uc group for rest of SIGs/WGs, so we not limit our self for the timeline of storyboard migration. And we can also provide a better one window concept (as you mentioned as `centralizing user-centric feedback`) I suggest we move current SIGs/WGs storyboard to that new group too, so can reuse some of the current sig storyboards. I believe some other SIGs/WGs are more than willing to migrate to StoryBoard (the migration process is very quick) if we ask. > The entire point is a first step (maybe final) in centralizing user-centric feedback that does not require any extra overhead be it cost, time, or otherwise. Just kicking off a discussion so others have a chance to chime in before anyone pulls the plug or pushes the button on anything and we settle as a community on what makes sense. > -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rico.lin.guanyu at gmail.com Fri Sep 21 07:01:39 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Fri, 21 Sep 2018 15:01:39 +0800 Subject: [Openstack-sigs] [First Contact] SIG PTG Summary In-Reply-To: References: Message-ID: On Thu, Sep 20, 2018 at 1:23 PM Kendall Nelson wrote: Organization Guide > > =============== > > Back in Sydney, we started discussing creating a guide for organizations > to educate them on what their contributors need to be effective and > successful members of the community. There is a patch out for review right > now[7] that we want to get merged as soon as possible so that we can > publicize it in Berlin and start introducing it when new companies join the > foundation. It was concluded that we needed to add more rationalizations to > the requirements and we delegated those out to ricolin, jungleboyj, and > spotz to help mattoliverau with content. As soon as this patch gets merged, > I volunteered to work to get it onto the soonest board meeting possible. > Dear all, As an action, I just post some suggest changes for `Technical` section (with comments) in [7], please take a look. > > [7] https://review.openstack.org/#/c/578676 > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.rydberg at citynetwork.eu Fri Sep 21 12:28:24 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Fri, 21 Sep 2018 14:28:24 +0200 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: References: Message-ID: <3067b8cd-28e1-46e2-b002-f4afad3b3dcf@citynetwork.eu> +1 to this as well. Regarding migrating everything for all WGs to storyboard, not 100 convinced that all WGs/SIGs will agree on that, even though I like the structure of the proposal here. I still think that it would be great to setup up this structure and start off easy, like adding the "top 3 items" as discussed earlier. Just let me know Melvin what you need me to do to help you out here! Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED On 2018-09-21 05:42, Rico Lin wrote: > > > On Fri, Sep 21, 2018 at 6:31 AM Melvin Hillsman > wrote: > > > > During the TC meeting at the PTG we discussed the ideal way to > capture user-centric feedback; particular from our various groups like > SIGs, WGs, etc. > > And I'm so glad to have you there to provide valuable inputs > > > Options that were mentioned ranged from a wiki page to a standalone > solution like discourse. > > > > While there is no perfect solution it was determined that Storyboard > could facilitate this. It would play out where there is a project > group openstack-uc? and each of the SIGs, WGs, etc would have a > project under this group; if I am wrong someone else in the room > correct me. > > I like the idea to have an openstack-uc group for rest of SIGs/WGs, so > we not limit our self for the timeline of storyboard migration. And we > can also provide a better one window concept (as you mentioned as > `centralizing user-centric feedback`) > > I suggest we move current SIGs/WGs storyboard to that new group too, > so can reuse some of the current sig storyboards. I believe some other > SIGs/WGs are more than willing to migrate to StoryBoard (the migration > process is very quick) if we ask. > > > The entire point is a first step (maybe final) in centralizing > user-centric feedback that does not require any extra overhead be it > cost, time, or otherwise. Just kicking off a discussion so others have > a chance to chime in before anyone pulls the plug or pushes the button > on anything and we settle as a community on what makes sense. > > > > -- > May The Force of OpenStack Be With You, > Rico Lin > irc: ricolin > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Fri Sep 21 14:41:11 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 21 Sep 2018 08:41:11 -0600 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: References: Message-ID: <1537540740-sup-4229@lrrr.local> Excerpts from Melvin Hillsman's message of 2018-09-20 17:30:32 -0500: > Hey everyone, > > During the TC meeting at the PTG we discussed the ideal way to capture > user-centric feedback; particular from our various groups like SIGs, WGs, > etc. > > Options that were mentioned ranged from a wiki page to a standalone > solution like discourse. > > While there is no perfect solution it was determined that Storyboard could > facilitate this. It would play out where there is a project group > openstack-uc? and each of the SIGs, WGs, etc would have a project under > this group; if I am wrong someone else in the room correct me. > > The entire point is a first step (maybe final) in centralizing user-centric > feedback that does not require any extra overhead be it cost, time, or > otherwise. Just kicking off a discussion so others have a chance to chime > in before anyone pulls the plug or pushes the button on anything and we > settle as a community on what makes sense. > I like the idea of tracking the information in storyboard. That said, one of the main purposes of creating SIGs was to separate those groups from the appearance that they were "managed" by the TC or UC. So, rather than creating a UC-focused project group, if we need a single project group at all, I would rather we call it "SIGs" or something similar. What do you think? Doug From mrhillsman at gmail.com Fri Sep 21 15:18:26 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Fri, 21 Sep 2018 10:18:26 -0500 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: <1537540740-sup-4229@lrrr.local> References: <1537540740-sup-4229@lrrr.local> Message-ID: On Fri, Sep 21, 2018 at 9:41 AM Doug Hellmann wrote: > Excerpts from Melvin Hillsman's message of 2018-09-20 17:30:32 -0500: > > Hey everyone, > > > > During the TC meeting at the PTG we discussed the ideal way to capture > > user-centric feedback; particular from our various groups like SIGs, WGs, > > etc. > > > > Options that were mentioned ranged from a wiki page to a standalone > > solution like discourse. > > > > While there is no perfect solution it was determined that Storyboard > could > > facilitate this. It would play out where there is a project group > > openstack-uc? and each of the SIGs, WGs, etc would have a project under > > this group; if I am wrong someone else in the room correct me. > > > > The entire point is a first step (maybe final) in centralizing > user-centric > > feedback that does not require any extra overhead be it cost, time, or > > otherwise. Just kicking off a discussion so others have a chance to chime > > in before anyone pulls the plug or pushes the button on anything and we > > settle as a community on what makes sense. > > > > I like the idea of tracking the information in storyboard. That > said, one of the main purposes of creating SIGs was to separate > those groups from the appearance that they were "managed" by the > TC or UC. So, rather than creating a UC-focused project group, if > we need a single project group at all, I would rather we call it > "SIGs" or something similar. > What you bring up re appearances makes sense definitely. Maybe we call it openstack-feedback since the purpose is focused on that and I actually looked at -uc as user-centric rather than user-committee; but appearances :) I think limiting it to SIGs will well, limit it to SIGs, and again could appear to be specific to those groups rather than for example the Public Cloud WG or Financial Team. > > What do you think? > > Doug > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Fri Sep 21 16:16:17 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 21 Sep 2018 10:16:17 -0600 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: References: <1537540740-sup-4229@lrrr.local> Message-ID: <1537546393-sup-9882@lrrr.local> Excerpts from Melvin Hillsman's message of 2018-09-21 10:18:26 -0500: > On Fri, Sep 21, 2018 at 9:41 AM Doug Hellmann wrote: > > > Excerpts from Melvin Hillsman's message of 2018-09-20 17:30:32 -0500: > > > Hey everyone, > > > > > > During the TC meeting at the PTG we discussed the ideal way to capture > > > user-centric feedback; particular from our various groups like SIGs, WGs, > > > etc. > > > > > > Options that were mentioned ranged from a wiki page to a standalone > > > solution like discourse. > > > > > > While there is no perfect solution it was determined that Storyboard > > could > > > facilitate this. It would play out where there is a project group > > > openstack-uc? and each of the SIGs, WGs, etc would have a project under > > > this group; if I am wrong someone else in the room correct me. > > > > > > The entire point is a first step (maybe final) in centralizing > > user-centric > > > feedback that does not require any extra overhead be it cost, time, or > > > otherwise. Just kicking off a discussion so others have a chance to chime > > > in before anyone pulls the plug or pushes the button on anything and we > > > settle as a community on what makes sense. > > > > > > > I like the idea of tracking the information in storyboard. That > > said, one of the main purposes of creating SIGs was to separate > > those groups from the appearance that they were "managed" by the > > TC or UC. So, rather than creating a UC-focused project group, if > > we need a single project group at all, I would rather we call it > > "SIGs" or something similar. > > > > What you bring up re appearances makes sense definitely. Maybe we call it > openstack-feedback since the purpose is focused on that and I actually > looked at -uc as user-centric rather than user-committee; but appearances :) Feedback implies that SIGs aren't engaged in creating OpenStack, though, and I think that's the perception we're trying to change. > I think limiting it to SIGs will well, limit it to SIGs, and again could > appear to be specific to those groups rather than for example the Public > Cloud WG or Financial Team. OK, I thought those groups were SIGs. Maybe we're overthinking the organization on this. What is special about the items that would be on this list compared to items opened directly against projects? Doug From rochelle.grober at huawei.com Fri Sep 21 17:44:09 2018 From: rochelle.grober at huawei.com (Rochelle Grober) Date: Fri, 21 Sep 2018 17:44:09 +0000 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: <1537546393-sup-9882@lrrr.local> References: <1537540740-sup-4229@lrrr.local> , <1537546393-sup-9882@lrrr.local> Message-ID: 95A3D28A-EFA1-40F0-A8D8-9ABB2DE0911D how about community input. or community discourse or something like that. community includes everyone. -------------------------------------------------- Rochelle Grober Rochelle Grober M: +1-6508889722(preferred) E: rochelle.grober at huawei.com 2012实验室-硅谷研究所技术规划及合作部 2012 Laboratories-Silicon Valley Technology Planning & Cooperation,Silicon Valley Research Center From:Doug Hellmann To:openstack-sigs, Date:2018-09-21 09:17:03 Subject:Re: [Openstack-sigs] Capturing Feedback/Input Excerpts from Melvin Hillsman's message of 2018-09-21 10:18:26 -0500: > On Fri, Sep 21, 2018 at 9:41 AM Doug Hellmann wrote: > > > Excerpts from Melvin Hillsman's message of 2018-09-20 17:30:32 -0500: > > > Hey everyone, > > > > > > During the TC meeting at the PTG we discussed the ideal way to capture > > > user-centric feedback; particular from our various groups like SIGs, WGs, > > > etc. > > > > > > Options that were mentioned ranged from a wiki page to a standalone > > > solution like discourse. > > > > > > While there is no perfect solution it was determined that Storyboard > > could > > > facilitate this. It would play out where there is a project group > > > openstack-uc? and each of the SIGs, WGs, etc would have a project under > > > this group; if I am wrong someone else in the room correct me. > > > > > > The entire point is a first step (maybe final) in centralizing > > user-centric > > > feedback that does not require any extra overhead be it cost, time, or > > > otherwise. Just kicking off a discussion so others have a chance to chime > > > in before anyone pulls the plug or pushes the button on anything and we > > > settle as a community on what makes sense. > > > > > > > I like the idea of tracking the information in storyboard. That > > said, one of the main purposes of creating SIGs was to separate > > those groups from the appearance that they were "managed" by the > > TC or UC. So, rather than creating a UC-focused project group, if > > we need a single project group at all, I would rather we call it > > "SIGs" or something similar. > > > > What you bring up re appearances makes sense definitely. Maybe we call it > openstack-feedback since the purpose is focused on that and I actually > looked at -uc as user-centric rather than user-committee; but appearances :) Feedback implies that SIGs aren't engaged in creating OpenStack, though, and I think that's the perception we're trying to change. > I think limiting it to SIGs will well, limit it to SIGs, and again could > appear to be specific to those groups rather than for example the Public > Cloud WG or Financial Team. OK, I thought those groups were SIGs. Maybe we're overthinking the organization on this. What is special about the items that would be on this list compared to items opened directly against projects? Doug _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrhillsman at gmail.com Fri Sep 21 17:55:09 2018 From: mrhillsman at gmail.com (Melvin Hillsman) Date: Fri, 21 Sep 2018 12:55:09 -0500 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: <1537546393-sup-9882@lrrr.local> References: <1537540740-sup-4229@lrrr.local> <1537546393-sup-9882@lrrr.local> Message-ID: On Fri, Sep 21, 2018 at 11:16 AM Doug Hellmann wrote: > Excerpts from Melvin Hillsman's message of 2018-09-21 10:18:26 -0500: > > On Fri, Sep 21, 2018 at 9:41 AM Doug Hellmann > wrote: > > > > > Excerpts from Melvin Hillsman's message of 2018-09-20 17:30:32 -0500: > > > > Hey everyone, > > > > > > > > During the TC meeting at the PTG we discussed the ideal way to > capture > > > > user-centric feedback; particular from our various groups like SIGs, > WGs, > > > > etc. > > > > > > > > Options that were mentioned ranged from a wiki page to a standalone > > > > solution like discourse. > > > > > > > > While there is no perfect solution it was determined that Storyboard > > > could > > > > facilitate this. It would play out where there is a project group > > > > openstack-uc? and each of the SIGs, WGs, etc would have a project > under > > > > this group; if I am wrong someone else in the room correct me. > > > > > > > > The entire point is a first step (maybe final) in centralizing > > > user-centric > > > > feedback that does not require any extra overhead be it cost, time, > or > > > > otherwise. Just kicking off a discussion so others have a chance to > chime > > > > in before anyone pulls the plug or pushes the button on anything and > we > > > > settle as a community on what makes sense. > > > > > > > > > > I like the idea of tracking the information in storyboard. That > > > said, one of the main purposes of creating SIGs was to separate > > > those groups from the appearance that they were "managed" by the > > > TC or UC. So, rather than creating a UC-focused project group, if > > > we need a single project group at all, I would rather we call it > > > "SIGs" or something similar. > > > > > > > What you bring up re appearances makes sense definitely. Maybe we call it > > openstack-feedback since the purpose is focused on that and I actually > > looked at -uc as user-centric rather than user-committee; but > appearances :) > > Feedback implies that SIGs aren't engaged in creating OpenStack, though, > and I think that's the perception we're trying to change. > > > I think limiting it to SIGs will well, limit it to SIGs, and again could > > appear to be specific to those groups rather than for example the Public > > Cloud WG or Financial Team. > > OK, I thought those groups were SIGs. > > Maybe we're overthinking the organization on this. What is special about > the items that would be on this list compared to items opened directly > against projects? > Yeah unfortunately we do have a tendency to overthink/complicate things. Not saying Storyboard is the right tool but suggested rather than having something extra to maintain was what I understood. There are at least 3 things that were to be addressed: - single pane so folks know where to provide/see updates - it is not a catchall/dumpsite - something still needs to be flushed out/prioritized (Public Cloud WG's missing features spreadsheet for example) - not specific to a single project (i thought this was a given since there is already a process/workflow for single project) I could very well be wrong so I am open to be corrected. From my perspective the idea in the room was to not circumvent anything internal but rather make it easy for external viewers, passerbys, etc. When feedback is gathered from Ops Meetup, OpenStack Days, Local meetups/events, we discussed putting that here as well. > > Doug > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Kind regards, Melvin Hillsman mrhillsman at gmail.com mobile: (832) 264-2646 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Sep 21 19:24:32 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 21 Sep 2018 19:24:32 +0000 Subject: [Openstack-sigs] Capturing Feedback/Input In-Reply-To: References: <1537540740-sup-4229@lrrr.local> <1537546393-sup-9882@lrrr.local> Message-ID: <20180921192432.k23x2u3w7626cder@yuggoth.org> On 2018-09-21 12:55:09 -0500 (-0500), Melvin Hillsman wrote: [...] > Yeah unfortunately we do have a tendency to overthink/complicate > things. Not saying Storyboard is the right tool but suggested > rather than having something extra to maintain was what I > understood. There are at least 3 things that were to be addressed: > > - single pane so folks know where to provide/see updates Not all OpenStack projects use the same task trackers currently and there's no guarantee that they ever will, so this is a best effort only. Odds are you may wind up duplicating some information also present in the Nova project on Launchpad, the Tripleo project on Trello and the Foobly project on Bugzilla (I made this last one up, in case it's not obvious). > - it is not a catchall/dumpsite If it looks generic enough, it will become that unless there are people actively devoted to triaging and pruning submissions to curate them... a tedious and thankless long-term commitment, to be sure. > - something still needs to be flushed out/prioritized (Public > Cloud WG's missing features spreadsheet for example) This is definitely a good source of input, but still needs someone to determine which various projects/services the tasks for them get slotted into and then help prioritizing and managing spec submissions on a per-team basis. > - not specific to a single project (i thought this was a given > since there is already a process/workflow for single project) The way to do that on storyboard.openstack.org is to give it a project of its own. Basically just couple it to a new, empty Git repository and then the people doing these tasks still have the option of also putting that repository to some use later (for example, to house their workflow documentation). > I could very well be wrong so I am open to be corrected. From my > perspective the idea in the room was to not circumvent anything > internal but rather make it easy for external viewers, passerbys, > etc. When feedback is gathered from Ops Meetup, OpenStack Days, > Local meetups/events, we discussed putting that here as well. It seems a fine plan, just keep in mind that documenting and publishing feedback doesn't magically translate into developers acting on any of it (and this is far from the first time it's been attempted). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From tony at bakeyournoodle.com Sat Sep 22 16:54:20 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Sat, 22 Sep 2018 11:54:20 -0500 Subject: [Openstack-sigs] [all] Nominations for the "T" Release name Message-ID: <20180922165419.GD5096@thor.bakeyournoodle.com> Hey everybody, Once again, it is time for us to pick a name for our "T" release. Since the associated Summit will be in Denver, the Geographic Location has been chosen as "Colorado" (State). Nominations are now open. Please add suitable names to https://wiki.openstack.org/wiki/Release_Naming/T_Proposals between now and 2018-10-15 23:59 UTC. In case you don't remember the rules: * Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again. * The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable. * The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process. * The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo". Names which do not meet these criteria but otherwise sound really cool should be added to a separate section of the wiki page and the TC may make an exception for one or more of them to be considered in the Condorcet poll. The naming official is responsible for presenting the list of exceptional names for consideration to the TC before the poll opens. Let the naming begin. Tony. Yours Tony. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From stig.openstack at telfer.org Wed Sep 26 07:32:53 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 26 Sep 2018 08:32:53 +0100 Subject: [Openstack-sigs] [scientific] IRC meeting today: Keycloak and federated authentication, SIG in Berlin Message-ID: <8312DC1E-3800-4E7B-820D-98FA30A63BDD@telfer.org> Hi All - We have an IRC meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. This week we are gathering requirements and sharing experiences on using Keycloak for simplifying federated authentication. We also have Berlin forum proposals to discuss. The full agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_September_26th_2018 Cheers, Stig -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at doughellmann.com Wed Sep 26 15:58:35 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 26 Sep 2018 11:58:35 -0400 Subject: [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series Message-ID: It's time to start thinking about community-wide goals for the T series. We use community-wide goals to achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become too high - across all OpenStack projects. Community input is important to ensure that the TC makes good decisions about the goals. We need to consider the timing, cycle length, priority, and feasibility of the suggested goals. If you are interested in proposing a goal, please make sure that before the summit it is described in the tracking etherpad [1] and that you have started a mailing list thread on the openstack-dev list about the proposal so that everyone in the forum session [2] has an opportunity to consider the details. The forum session is only one step in the selection process. See [3] for more details. Doug [1] https://etherpad.openstack.org/p/community-goals [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 [3] https://governance.openstack.org/tc/goals/index.html From Tim.Bell at cern.ch Wed Sep 26 18:55:49 2018 From: Tim.Bell at cern.ch (Tim Bell) Date: Wed, 26 Sep 2018 18:55:49 +0000 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: References: Message-ID: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> Doug, Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. To give it some context and the motivation: At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). In other cases, there are subsets of the function which require the native project client. I would strongly support a goal which targets - All new projects should have the end user facing functionality fully exposed via the unified client - Existing projects should aim to close the gap within 'N' cycles (N to be defined) - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. Tim -----Original Message----- From: Doug Hellmann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Wednesday, 26 September 2018 at 18:00 To: openstack-dev , openstack-operators , openstack-sigs Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series It's time to start thinking about community-wide goals for the T series. We use community-wide goals to achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become too high - across all OpenStack projects. Community input is important to ensure that the TC makes good decisions about the goals. We need to consider the timing, cycle length, priority, and feasibility of the suggested goals. If you are interested in proposing a goal, please make sure that before the summit it is described in the tracking etherpad [1] and that you have started a mailing list thread on the openstack-dev list about the proposal so that everyone in the forum session [2] has an opportunity to consider the details. The forum session is only one step in the selection process. See [3] for more details. Doug [1] https://etherpad.openstack.org/p/community-goals [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 [3] https://governance.openstack.org/tc/goals/index.html __________________________________________________________________________ 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 From Kevin.Fox at pnnl.gov Wed Sep 26 19:16:47 2018 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Wed, 26 Sep 2018 19:16:47 +0000 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> References: , <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> Message-ID: <1A3C52DFCD06494D8528644858247BF01C1AF6BB@EX10MBOX03.pnnl.gov> +1 :) ________________________________________ From: Tim Bell [Tim.Bell at cern.ch] Sent: Wednesday, September 26, 2018 11:55 AM To: OpenStack Development Mailing List (not for usage questions); openstack-operators; openstack-sigs Subject: Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series Doug, Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. To give it some context and the motivation: At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). In other cases, there are subsets of the function which require the native project client. I would strongly support a goal which targets - All new projects should have the end user facing functionality fully exposed via the unified client - Existing projects should aim to close the gap within 'N' cycles (N to be defined) - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. Tim -----Original Message----- From: Doug Hellmann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Wednesday, 26 September 2018 at 18:00 To: openstack-dev , openstack-operators , openstack-sigs Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series It's time to start thinking about community-wide goals for the T series. We use community-wide goals to achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become too high - across all OpenStack projects. Community input is important to ensure that the TC makes good decisions about the goals. We need to consider the timing, cycle length, priority, and feasibility of the suggested goals. If you are interested in proposing a goal, please make sure that before the summit it is described in the tracking etherpad [1] and that you have started a mailing list thread on the openstack-dev list about the proposal so that everyone in the forum session [2] has an opportunity to consider the details. The forum session is only one step in the selection process. See [3] for more details. Doug [1] https://etherpad.openstack.org/p/community-goals [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 [3] https://governance.openstack.org/tc/goals/index.html __________________________________________________________________________ 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-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From Arkady.Kanevsky at dell.com Wed Sep 26 19:22:21 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Wed, 26 Sep 2018 19:22:21 +0000 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> Message-ID: <0ec720bd34de4ff09ffad24b7887edfc@AUSX13MPS308.AMER.DELL.COM> +1 -----Original Message----- From: Tim Bell [mailto:Tim.Bell at cern.ch] Sent: Wednesday, September 26, 2018 1:56 PM To: OpenStack Development Mailing List (not for usage questions); openstack-operators; openstack-sigs Subject: Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series [EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information. Doug, Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. To give it some context and the motivation: At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). In other cases, there are subsets of the function which require the native project client. I would strongly support a goal which targets - All new projects should have the end user facing functionality fully exposed via the unified client - Existing projects should aim to close the gap within 'N' cycles (N to be defined) - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. Tim -----Original Message----- From: Doug Hellmann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Wednesday, 26 September 2018 at 18:00 To: openstack-dev , openstack-operators , openstack-sigs Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series It's time to start thinking about community-wide goals for the T series. We use community-wide goals to achieve visible common changes, push for basic levels of consistency and user experience, and efficiently improve certain areas where technical debt payments have become too high - across all OpenStack projects. Community input is important to ensure that the TC makes good decisions about the goals. We need to consider the timing, cycle length, priority, and feasibility of the suggested goals. If you are interested in proposing a goal, please make sure that before the summit it is described in the tracking etherpad [1] and that you have started a mailing list thread on the openstack-dev list about the proposal so that everyone in the forum session [2] has an opportunity to consider the details. The forum session is only one step in the selection process. See [3] for more details. Doug [1] https://etherpad.openstack.org/p/community-goals [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 [3] https://governance.openstack.org/tc/goals/index.html __________________________________________________________________________ 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-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From mgagne at calavera.ca Wed Sep 26 19:40:45 2018 From: mgagne at calavera.ca (=?UTF-8?Q?Mathieu_Gagn=C3=A9?=) Date: Wed, 26 Sep 2018 15:40:45 -0400 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> Message-ID: +1 Yes please! -- Mathieu On Wed, Sep 26, 2018 at 2:56 PM Tim Bell wrote: > > > Doug, > > Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. > > To give it some context and the motivation: > > At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). > > One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). In other cases, there are subsets of the function which require the native project client. > > I would strongly support a goal which targets > > - All new projects should have the end user facing functionality fully exposed via the unified client > - Existing projects should aim to close the gap within 'N' cycles (N to be defined) > - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) > - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) > > The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. > > It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. > > Tim > > -----Original Message----- > From: Doug Hellmann > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Wednesday, 26 September 2018 at 18:00 > To: openstack-dev , openstack-operators , openstack-sigs > Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series > > It's time to start thinking about community-wide goals for the T series. > > We use community-wide goals to achieve visible common changes, push for > basic levels of consistency and user experience, and efficiently improve > certain areas where technical debt payments have become too high - > across all OpenStack projects. Community input is important to ensure > that the TC makes good decisions about the goals. We need to consider > the timing, cycle length, priority, and feasibility of the suggested > goals. > > If you are interested in proposing a goal, please make sure that before > the summit it is described in the tracking etherpad [1] and that you > have started a mailing list thread on the openstack-dev list about the > proposal so that everyone in the forum session [2] has an opportunity to > consider the details. The forum session is only one step in the > selection process. See [3] for more details. > > Doug > > [1] https://etherpad.openstack.org/p/community-goals > [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 > [3] https://governance.openstack.org/tc/goals/index.html > > __________________________________________________________________________ > 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-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From tpb at dyncloud.net Wed Sep 26 20:27:52 2018 From: tpb at dyncloud.net (Tom Barron) Date: Wed, 26 Sep 2018 16:27:52 -0400 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> Message-ID: <20180926202752.j56dtfyahnw4triq@barron.net> On 26/09/18 18:55 +0000, Tim Bell wrote: > >Doug, > >Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. > >To give it some context and the motivation: > >At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). > >One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). Tim, First, I endorse this goal. That said, lack of coverage of Manila in the OpenStack client was articulated as a need (by CERN and others) during the Vancouver Forum. At the recent Manila PTG we set addressing this technical debt as a Stein cycle goal, as well as OpenStack SDK integration for Manila. -- Tom Barron (tbarron) > In other cases, there are subsets of the function which require the native project client. > >I would strongly support a goal which targets > >- All new projects should have the end user facing functionality fully exposed via the unified client >- Existing projects should aim to close the gap within 'N' cycles (N to be defined) >- Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) >- Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) > >The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. > >It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. > >Tim > >-----Original Message----- >From: Doug Hellmann >Reply-To: "OpenStack Development Mailing List (not for usage questions)" >Date: Wednesday, 26 September 2018 at 18:00 >To: openstack-dev , openstack-operators , openstack-sigs >Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series > > It's time to start thinking about community-wide goals for the T series. > > We use community-wide goals to achieve visible common changes, push for > basic levels of consistency and user experience, and efficiently improve > certain areas where technical debt payments have become too high - > across all OpenStack projects. Community input is important to ensure > that the TC makes good decisions about the goals. We need to consider > the timing, cycle length, priority, and feasibility of the suggested > goals. > > If you are interested in proposing a goal, please make sure that before > the summit it is described in the tracking etherpad [1] and that you > have started a mailing list thread on the openstack-dev list about the > proposal so that everyone in the forum session [2] has an opportunity to > consider the details. The forum session is only one step in the > selection process. See [3] for more details. > > Doug > > [1] https://etherpad.openstack.org/p/community-goals > [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 > [3] https://governance.openstack.org/tc/goals/index.html > > __________________________________________________________________________ > 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-sigs mailing list >openstack-sigs at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From mriedemos at gmail.com Wed Sep 26 20:44:53 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 26 Sep 2018 15:44:53 -0500 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> Message-ID: <9b25b688-8286-c34d-1fc2-386f5ab93ec4@gmail.com> On 9/26/2018 3:01 PM, Doug Hellmann wrote: > Monty Taylor writes: > >> On 09/26/2018 01:55 PM, Tim Bell wrote: >>> Doug, >>> >>> Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. I would personally like to thank the person that put that goal in the etherpad...they must have had amazing foresight and unparalleled modesty. >>> >>> To give it some context and the motivation: >>> >>> At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). >>> >>> One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). In other cases, there are subsets of the function which require the native project client. >>> >>> I would strongly support a goal which targets >>> >>> - All new projects should have the end user facing functionality fully exposed via the unified client >>> - Existing projects should aim to close the gap within 'N' cycles (N to be defined) >>> - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) >>> - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) >>> >>> The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. >>> >>> It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. >> ++ >> >> It's also worth noting that we're REALLY close to a 1.0 of openstacksdk >> (all the patches are in flight, we just need to land them) - and once >> we've got that we'll be in a position to start shifting >> python-openstackclient to using openstacksdk instead of python-*client. >> >> This will have the additional benefit that, once we've migrated CLIs to >> python-openstackclient as per this goal, and once we've migrated >> openstackclient itself to openstacksdk, the number of different >> libraries one needs to install to interact with openstack will be >> _dramatically_ lower. > Would it be useful to have the SDK work in OSC as a prerequisite to the > goal work? I would hate to have folks have to write a bunch of things > twice. > > Do we have any sort of list of which projects aren't currently being > handled by OSC? If we could get some help building such a list, that > would help us understand the scope of the work. I started documenting the compute API gaps in OSC last release [1]. It's a big gap and needs a lot of work, even for existing CLIs (the cold/live migration CLIs in OSC are a mess, and you can't even boot from volume where nova creates the volume for you). That's also why I put something into the etherpad about the OSC core team even being able to handle an onslaught of changes for a goal like this. > > As far as admin features, I think we've been hesitant to add those to > OSC in the past, but I can see the value. I wonder if having them in a > separate library makes sense? Or is it better to have commands in the > tool that regular users can't access, and just report the permission > error when they try to run the command? I thought the same, and we talked about this at the Austin summit, but OSC is inconsistent about this (you can live migrate a server but you can't evacuate it - there is no CLI for evacuation). It also came up at the Stein PTG with Dean in the nova room giving us some direction. [2] I believe the summary of that discussion was: a) to deal with the core team sprawl, we could move the compute stuff out of python-openstackclient and into an osc-compute plugin (like the osc-placement plugin for the placement service); then we could create a new core team which would have python-openstackclient-core as a superset b) Dean suggested that we close the compute API gaps in the SDK first, but that could take a long time as well...but it sounded like we could use the SDK for things that existed in the SDK and use novaclient for things that didn't yet exist in the SDK This might be a candidate for one of these multi-release goals that the TC started talking about at the Stein PTG. I could see something like this being a goal for Stein: "Each project owns its own osc- plugin for OSC CLIs" That deals with the core team and sprawl issue, especially with stevemar being gone and dtroyer being distracted by shiny x-men bird related things. That also seems relatively manageable for all projects to do in a single release. Having a single-release goal of "close all gaps across all service types" is going to be extremely tough for any older projects that had CLIs before OSC was created (nova/cinder/glance/keystone). For newer projects, like placement, it's not a problem because they never created any other CLI outside of OSC. [1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc [2] https://etherpad.openstack.org/p/nova-ptg-stein (~L721) -- Thanks, Matt From dtroyer at gmail.com Wed Sep 26 21:33:27 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Wed, 26 Sep 2018 16:33:27 -0500 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: <9b25b688-8286-c34d-1fc2-386f5ab93ec4@gmail.com> References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> <9b25b688-8286-c34d-1fc2-386f5ab93ec4@gmail.com> Message-ID: On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann wrote: > I started documenting the compute API gaps in OSC last release [1]. It's a > big gap and needs a lot of work, even for existing CLIs (the cold/live > migration CLIs in OSC are a mess, and you can't even boot from volume where > nova creates the volume for you). That's also why I put something into the > etherpad about the OSC core team even being able to handle an onslaught of > changes for a goal like this. The OSC core team is very thin, yes, it seems as though companies don't like to spend money on client-facing things...I'll be in the hall following this thread should anyone want to talk... The migration commands are a mess, mostly because I got them wrong to start with and we have only tried to patch it up, this is one area I think we need to wipe clean and fix properly. Yay! Major version release! > I thought the same, and we talked about this at the Austin summit, but OSC > is inconsistent about this (you can live migrate a server but you can't > evacuate it - there is no CLI for evacuation). It also came up at the Stein > PTG with Dean in the nova room giving us some direction. [2] I believe the > summary of that discussion was: > a) to deal with the core team sprawl, we could move the compute stuff out of > python-openstackclient and into an osc-compute plugin (like the > osc-placement plugin for the placement service); then we could create a new > core team which would have python-openstackclient-core as a superset This is not my first choice but is not terrible either... > b) Dean suggested that we close the compute API gaps in the SDK first, but > that could take a long time as well...but it sounded like we could use the > SDK for things that existed in the SDK and use novaclient for things that > didn't yet exist in the SDK Yup, this can be done in parallel. The unit of decision for use sdk vs use XXXclient lib is per-API call. If the client lib can use an SDK adapter/session it becomes even better. I think the priority for what to address first should be guided by complete gaps in coverage and the need for microversion-driven changes. > This might be a candidate for one of these multi-release goals that the TC > started talking about at the Stein PTG. I could see something like this > being a goal for Stein: > > "Each project owns its own osc- plugin for OSC CLIs" > > That deals with the core team and sprawl issue, especially with stevemar > being gone and dtroyer being distracted by shiny x-men bird related things. > That also seems relatively manageable for all projects to do in a single > release. Having a single-release goal of "close all gaps across all service > types" is going to be extremely tough for any older projects that had CLIs > before OSC was created (nova/cinder/glance/keystone). For newer projects, > like placement, it's not a problem because they never created any other CLI > outside of OSC. I think the major difficulty here is simply how to migrate users from today state to future state in a reasonable manner. If we could teach OSC how to handle the same command being defined in multiple plugins properly (hello entrypoints!) it could be much simpler as we could start creating the new plugins and switch as the new command implementations become available rather than having a hard cutover. Or maybe the definition of OSC v4 is as above and we just work at it until complete and cut over at the end. Note that the current APIs that are in-repo (Compute, Identity, Image, Network, Object, Volume) are all implemented using the plugin structure, OSC v4 could start as the breaking out of those without command changes (except new migration commands!) and then the plugins all re-write and update at their own tempo. Dang, did I just deconstruct my project? One thing I don't like about that is we just replace N client libs with N (or more) plugins now and the number of things a user must install doesn't go down. I would like to hear from anyone who deals with installing OSC if that is still a big deal or should I let go of that worry? dt -- Dean Troyer dtroyer at gmail.com From rochelle.grober at huawei.com Wed Sep 26 23:17:58 2018 From: rochelle.grober at huawei.com (Rochelle Grober) Date: Wed, 26 Sep 2018 23:17:58 +0000 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch>, Message-ID: 1B24E0FB-005A-4A86-AF27-6659D912A07F Oh, very definitely +1000 -------------------------------------------------- Rochelle Grober Rochelle Grober M: +1-6508889722(preferred) E: rochelle.grober at huawei.com 2012实验室-硅谷研究所技术规划及合作部 2012 Laboratories-Silicon Valley Technology Planning & Cooperation,Silicon Valley Research Center From:Mathieu Gagné To:openstack-sigs at lists.openstack.org, Cc:OpenStack Development Mailing List (not for usage questions),OpenStack Operators, Date:2018-09-26 12:41:24 Subject:Re: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series +1 Yes please! -- Mathieu On Wed, Sep 26, 2018 at 2:56 PM Tim Bell wrote: > > > Doug, > > Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. > > To give it some context and the motivation: > > At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). > > One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). In other cases, there are subsets of the function which require the native project client. > > I would strongly support a goal which targets > > - All new projects should have the end user facing functionality fully exposed via the unified client > - Existing projects should aim to close the gap within 'N' cycles (N to be defined) > - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) > - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) > > The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. > > It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. > > Tim > > -----Original Message----- > From: Doug Hellmann > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Wednesday, 26 September 2018 at 18:00 > To: openstack-dev , openstack-operators , openstack-sigs > Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series > > It's time to start thinking about community-wide goals for the T series. > > We use community-wide goals to achieve visible common changes, push for > basic levels of consistency and user experience, and efficiently improve > certain areas where technical debt payments have become too high - > across all OpenStack projects. Community input is important to ensure > that the TC makes good decisions about the goals. We need to consider > the timing, cycle length, priority, and feasibility of the suggested > goals. > > If you are interested in proposing a goal, please make sure that before > the summit it is described in the tracking etherpad [1] and that you > have started a mailing list thread on the openstack-dev list about the > proposal so that everyone in the forum session [2] has an opportunity to > consider the details. The forum session is only one step in the > selection process. See [3] for more details. > > Doug > > [1] https://etherpad.openstack.org/p/community-goals > [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 > [3] https://governance.openstack.org/tc/goals/index.html > > __________________________________________________________________________ > 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-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.rydberg at citynetwork.eu Thu Sep 27 06:32:57 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Thu, 27 Sep 2018 08:32:57 +0200 Subject: [Openstack-sigs] [publiccloud-wg] Reminder weekly meeting Public Cloud WG Message-ID: Hi everyone, Time for a new meeting for PCWG - today (27th) 1400 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg We will again have a short brief from the PTG for those of you that missed that last week. Also, time to start planning for the upcoming summit - forum sessions submitted etc. Another important item on the agenda is the prio/ranking of our "missing features" list. We have identified a few cross project goals already that we see as important, but we need more operators to engage in this ranking. Talk to you later today! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED From thierry at openstack.org Thu Sep 27 09:30:28 2018 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 27 Sep 2018 11:30:28 +0200 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> <9b25b688-8286-c34d-1fc2-386f5ab93ec4@gmail.com> Message-ID: <3b40375e-8970-35fc-5941-b331d5ecaf63@openstack.org> First I think that is a great goal, but I want to pick up on Dean's comment: Dean Troyer wrote: > [...] > The OSC core team is very thin, yes, it seems as though companies > don't like to spend money on client-facing things...I'll be in the > hall following this thread should anyone want to talk... I think OSC (and client-facing tooling in general) is a great place for OpenStack users (deployers of OpenStack clouds) to contribute. It's a smaller territory, it's less time-consuming than the service side, they are the most obvious interested party, and a small, 20% time investment would have a dramatic impact. It's arguably difficult for OpenStack users to get involved in "OpenStack development": keeping track of what's happening in a large team is already likely to consume most of the time you can dedicate to it. But OSC is a specific, smaller area which would be a good match for the expertise and time availability of anybody running an OpenStack cloud that wants to contribute back and make OpenStack better. Shameless plug: I proposed a Forum session in Berlin to discuss "Getting OpenStack users involved in the project" -- and we'll discuss such areas that are a particularly good match for users to get involved. -- Thierry Carrez (ttx) From doug at doughellmann.com Thu Sep 27 14:06:06 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 27 Sep 2018 10:06:06 -0400 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> <9b25b688-8286-c34d-1fc2-386f5ab93ec4@gmail.com> Message-ID: Dean Troyer writes: > On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann wrote: >> I started documenting the compute API gaps in OSC last release [1]. It's a >> big gap and needs a lot of work, even for existing CLIs (the cold/live >> migration CLIs in OSC are a mess, and you can't even boot from volume where >> nova creates the volume for you). That's also why I put something into the >> etherpad about the OSC core team even being able to handle an onslaught of >> changes for a goal like this. > > The OSC core team is very thin, yes, it seems as though companies > don't like to spend money on client-facing things...I'll be in the > hall following this thread should anyone want to talk... > > The migration commands are a mess, mostly because I got them wrong to > start with and we have only tried to patch it up, this is one area I > think we need to wipe clean and fix properly. Yay! Major version > release! I definitely think having details about the gaps would be a prerequisite for approving a goal, but I wonder if that's something 1 person could even do alone. Is this an area where a small team is needed? >> I thought the same, and we talked about this at the Austin summit, but OSC >> is inconsistent about this (you can live migrate a server but you can't >> evacuate it - there is no CLI for evacuation). It also came up at the Stein >> PTG with Dean in the nova room giving us some direction. [2] I believe the >> summary of that discussion was: > >> a) to deal with the core team sprawl, we could move the compute stuff out of >> python-openstackclient and into an osc-compute plugin (like the >> osc-placement plugin for the placement service); then we could create a new >> core team which would have python-openstackclient-core as a superset > > This is not my first choice but is not terrible either... We built cliff to be based on plugins to support this sort of work distribution, right? >> b) Dean suggested that we close the compute API gaps in the SDK first, but >> that could take a long time as well...but it sounded like we could use the >> SDK for things that existed in the SDK and use novaclient for things that >> didn't yet exist in the SDK > > Yup, this can be done in parallel. The unit of decision for use sdk > vs use XXXclient lib is per-API call. If the client lib can use an > SDK adapter/session it becomes even better. I think the priority for > what to address first should be guided by complete gaps in coverage > and the need for microversion-driven changes. > >> This might be a candidate for one of these multi-release goals that the TC >> started talking about at the Stein PTG. I could see something like this >> being a goal for Stein: >> >> "Each project owns its own osc- plugin for OSC CLIs" >> >> That deals with the core team and sprawl issue, especially with stevemar >> being gone and dtroyer being distracted by shiny x-men bird related things. >> That also seems relatively manageable for all projects to do in a single >> release. Having a single-release goal of "close all gaps across all service >> types" is going to be extremely tough for any older projects that had CLIs >> before OSC was created (nova/cinder/glance/keystone). For newer projects, >> like placement, it's not a problem because they never created any other CLI >> outside of OSC. Yeah, I agree this work is going to need to be split up. I'm still not sold on the idea of multi-cycle goals, personally. > I think the major difficulty here is simply how to migrate users from > today state to future state in a reasonable manner. If we could teach > OSC how to handle the same command being defined in multiple plugins > properly (hello entrypoints!) it could be much simpler as we could > start creating the new plugins and switch as the new command > implementations become available rather than having a hard cutover. > > Or maybe the definition of OSC v4 is as above and we just work at it > until complete and cut over at the end. Note that the current APIs > that are in-repo (Compute, Identity, Image, Network, Object, Volume) > are all implemented using the plugin structure, OSC v4 could start as > the breaking out of those without command changes (except new > migration commands!) and then the plugins all re-write and update at > their own tempo. Dang, did I just deconstruct my project? It sure sounds like it. Congratulations! I like the idea of moving the existing code into libraries, having python-openstackclient depend on them, and then asking project teams for more help with them. > One thing I don't like about that is we just replace N client libs > with N (or more) plugins now and the number of things a user must > install doesn't go down. I would like to hear from anyone who deals > with installing OSC if that is still a big deal or should I let go of > that worry? Don't package managers just deal with this? I can pip/yum/apt install something and get all of its dependencies, right? Doug From dtroyer at gmail.com Thu Sep 27 15:11:28 2018 From: dtroyer at gmail.com (Dean Troyer) Date: Thu, 27 Sep 2018 10:11:28 -0500 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> <9b25b688-8286-c34d-1fc2-386f5ab93ec4@gmail.com> Message-ID: On Thu, Sep 27, 2018 at 9:06 AM, Doug Hellmann wrote: > I definitely think having details about the gaps would be a prerequisite > for approving a goal, but I wonder if that's something 1 person could > even do alone. Is this an area where a small team is needed? Maybe, but it does break down along project/API lines for the most part, only crossing in places like Matt mentioned where compute+volume interact in server create, etc. For the purposes of a goal, I think we need to be thinking more about structural things than specific command changes. Things like Monty mentioned elsewhere in the thread about getting all of the exiting client libs to correctly use an SDK adapter then behaviours converge and the details of command changes become project-specific. > We built cliff to be based on plugins to support this sort of work > distribution, right? We did, my concerns about splitting the OSC in-repo plugins out is frankly more around losing control of things like command structure and consistency, not about the code. Looking at the loss of consistency in plugins shows that is a hard thing to maintain across a distributed set of groups. >> One thing I don't like about that is we just replace N client libs >> with N (or more) plugins now and the number of things a user must >> install doesn't go down. I would like to hear from anyone who deals >> with installing OSC if that is still a big deal or should I let go of >> that worry? > > Don't package managers just deal with this? I can pip/yum/apt install > something and get all of its dependencies, right? For those using that, yes. The set of folks interacting with OpenStack from a Windows desktop is not as large but their experience is sometimes a painful one...although wheels were just becoming a thing when I last tried to bundle OSC into a py2exe-style thing so the pains of things like OpenSSL may be fewer now. dt -- Dean Troyer dtroyer at gmail.com From msm at redhat.com Thu Sep 27 16:48:19 2018 From: msm at redhat.com (Michael McCune) Date: Thu, 27 Sep 2018 12:48:19 -0400 Subject: [Openstack-sigs] [all][api] POST /api-sig/news Message-ID: Greetings OpenStack community, This week's meeting was mostly ceremonial, with the main topic of discussion being the office hours for the SIG. If you have not heard the news about the API-SIG, we are converting from a regular weekly meeting time to a set of scheduled office hours. This change was discussed over the course of meeting leading up to the PTG and was finalized last week. The reasoning behind this decision was summarized nicely by edleafe in the last newsletter: We, as a SIG, have recognized that we have moved into a new phase. With most of the API guidelines that we needed to write having been written, there is not "new stuff" to make demands on our time. In recognition of this, we are changing how we will work. How can you find the API-SIG? We have 2 office hours that we will hold in the #openstack-sdks channel on freenode: * Thursdays 0900-1000 UTC * Thursdays 1600-1700 UTC Additionally, there is usually someone from the API-SIG hanging out in the #openstack-sdks channel. Please feel free to ping dtanstur, edleafe, or elmiko as direct contacts. Although this marks the end of our weekly meetings, the API-SIG will continue to be active in the community and we would like to extend a hearty "huzzah!" to all the OpenStack contributors, operators, and users who have helped to create the guidelines and guidance that we all share. Huzzah! If you're interested in helping out, here are some things to get you started: * The list of bugs [5] indicates several missing or incomplete guidelines. * The existing guidelines [2] always need refreshing to account for changes over time. If you find something that's not quite right, submit a patch [6] to fix it. * Have you done something for which you think guidance would have made things easier but couldn't find any? Submit a patch and help others [6]. # Newly Published Guidelines * None # API Guidelines Proposed for Freeze * None # Guidelines that are ready for wider review by the whole community. * None # Guidelines Currently Under Review [3] * Add an api-design doc with design advice https://review.openstack.org/592003 * Update parameter names in microversion sdk spec https://review.openstack.org/#/c/557773/ * Add API-schema guide (still being defined) https://review.openstack.org/#/c/524467/ * Version and service discovery series Start at https://review.openstack.org/#/c/459405/ * WIP: microversion architecture archival doc (very early; not yet ready for review) https://review.openstack.org/444892 # Highlighting your API impacting issues If you seek further review and insight from the API SIG about APIs that you are developing or changing, please address your concerns in an email to the OpenStack developer mailing list[1] with the tag "[api]" in the subject. In your email, you should include any relevant reviews, links, and comments to help guide the discussion of the specific challenge you are facing. To learn more about the API SIG mission and the work we do, see our wiki page [4] and guidelines [2]. Thanks for reading and see you next week! # References [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2] http://specs.openstack.org/openstack/api-wg/ [3] https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z [4] https://wiki.openstack.org/wiki/API_SIG [5] https://storyboard.openstack.org/#!/project/1039 [6] https://git.openstack.org/cgit/openstack/api-sig Past Meeting Records http://eavesdrop.openstack.org/meetings/api_sig/ Open Bugs https://bugs.launchpad.net/openstack-api-wg From mriedemos at gmail.com Thu Sep 27 19:23:13 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Thu, 27 Sep 2018 14:23:13 -0500 Subject: [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> <9b25b688-8286-c34d-1fc2-386f5ab93ec4@gmail.com> Message-ID: <7d6d98a9-7c0c-5143-64be-3b55ad02bb98@gmail.com> On 9/27/2018 10:11 AM, Dean Troyer wrote: > On Thu, Sep 27, 2018 at 9:06 AM, Doug Hellmann wrote: >> I definitely think having details about the gaps would be a prerequisite >> for approving a goal, but I wonder if that's something 1 person could >> even do alone. Is this an area where a small team is needed? > Maybe, but it does break down along project/API lines for the most > part, only crossing in places like Matt mentioned where compute+volume > interact in server create, etc. > > For the purposes of a goal, I think we need to be thinking more about > structural things than specific command changes. Things like Monty > mentioned elsewhere in the thread about getting all of the exiting > client libs to correctly use an SDK adapter then behaviours converge > and the details of command changes become project-specific. > Yeah I did the gap analysis for the compute API, you'd need each team doing that, for however they define "gaps". Not all projects use microversions, but they probably add new resources to the API so I'd consider that one way to identify gaps, e.g. can I list foo resources from service type bar? Another thought I had about breaking this down into more digestable chunks, at least from a nova perspective, is looking at closing gaps on a smaller scale. Looking at the latest user survey analytics [1] the majority of deployments are running mitaka or newton. The max compute API microversion in mitaka was 2.25. Considering the gaps between 2.1 and 2.25 [2] simply getting OSC compute API support up to mitaka levels would be an accomplishment. I don't know how well that would translate to other project teams, but it's an idea for how the nova team could help break down this work into a more realistic goal for a single release. [1] https://www.openstack.org/analytics [2] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc -- Thanks, Matt From gagehugo at gmail.com Fri Sep 28 14:54:51 2018 From: gagehugo at gmail.com (Gage Hugo) Date: Fri, 28 Sep 2018 09:54:51 -0500 Subject: [Openstack-sigs] [security] Security SIG Denver PTG Summary Message-ID: Apologies for not sending this out sooner. The Security SIG agenda[0] at the Denver PTG was fairly light, only one main topic was brought forward, which was unified trusts[1]. This presentation aimed on providing a potential service to interface various trust platforms with OpenStack. (Thanks to zhipeng for presenting!) [0] https://etherpad.openstack.org/p/security-stein-ptg [1] https://docs.google.com/presentation/d/1MOvkqdYgoMDcf3B8Sb6Bx3qR6ZrBz-kJT7gpKUxudRc/edit#slide=id.p -------------- next part -------------- An HTML attachment was scrubbed... URL: From jomlowe at iu.edu Wed Sep 26 19:30:18 2018 From: jomlowe at iu.edu (Mike Lowe) Date: Wed, 26 Sep 2018 19:30:18 -0000 Subject: [Openstack-sigs] [Openstack-operators] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series In-Reply-To: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> References: <51B94DEF-2279-43E7-844B-48408DE11F41@cern.ch> Message-ID: <58804C82-9E57-4A69-BB66-BCD1C6FFB441@iu.edu> +1 I encountered the negative effects of the disparity between the cinder cli and OpenStack cli just an hour before receiving Tim’s reply. The missing features of OpenStack client relative to individual project clients trip me up multiple times per week on average. Sent from my iPad > On Sep 26, 2018, at 2:55 PM, Tim Bell wrote: > > > Doug, > > Thanks for raising this. I'd like to highlight the goal "Finish moving legacy python-*client CLIs to python-openstackclient" from the etherpad and propose this for a T/U series goal. > > To give it some context and the motivation: > > At CERN, we have more than 3000 users of the OpenStack cloud. We write an extensive end user facing documentation which explains how to use the OpenStack along with CERN specific features (such as workflows for requesting projects/quotas/etc.). > > One regular problem we come across is that the end user experience is inconsistent. In some cases, we find projects which are not covered by the unified OpenStack client (e.g. Manila). In other cases, there are subsets of the function which require the native project client. > > I would strongly support a goal which targets > > - All new projects should have the end user facing functionality fully exposed via the unified client > - Existing projects should aim to close the gap within 'N' cycles (N to be defined) > - Many administrator actions would also benefit from integration (reader roles are end users too so list and show need to be covered too) > - Users should be able to use a single openrc for all interactions with the cloud (e.g. not switch between password for some CLIs and Kerberos for OSC) > > The end user perception of a solution will be greatly enhanced by a single command line tool with consistent syntax and authentication framework. > > It may be a multi-release goal but it would really benefit the cloud consumers and I feel that goals should include this audience also. > > Tim > > -----Original Message----- > From: Doug Hellmann > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Wednesday, 26 September 2018 at 18:00 > To: openstack-dev , openstack-operators , openstack-sigs > Subject: [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series > > It's time to start thinking about community-wide goals for the T series. > > We use community-wide goals to achieve visible common changes, push for > basic levels of consistency and user experience, and efficiently improve > certain areas where technical debt payments have become too high - > across all OpenStack projects. Community input is important to ensure > that the TC makes good decisions about the goals. We need to consider > the timing, cycle length, priority, and feasibility of the suggested > goals. > > If you are interested in proposing a goal, please make sure that before > the summit it is described in the tracking etherpad [1] and that you > have started a mailing list thread on the openstack-dev list about the > proposal so that everyone in the forum session [2] has an opportunity to > consider the details. The forum session is only one step in the > selection process. See [3] for more details. > > Doug > > [1] https://etherpad.openstack.org/p/community-goals > [2] https://www.openstack.org/summit/berlin-2018/vote-for-speakers#/22814 > [3] https://governance.openstack.org/tc/goals/index.html > > __________________________________________________________________________ > 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-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators