Re: [Openstack-operators] [openstack-dev] [all] Consistent policy names
In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post" which maps to the "os--api::" format. I selected it as it uses the service-type[1], references the API resource, and then the method. So it maps well to the API reference[2] for the service. [0] https://docs.openstack.org/octavia/latest/configuration/policy.html [1] https://service-types.openstack.org/ [2] https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer Michael On Wed, Sep 12, 2018 at 12:52 PM Tim Bell wrote: > > So +1 > > > > Tim > > > > From: Lance Bragstad > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Wednesday, 12 September 2018 at 20:43 > To: "OpenStack Development Mailing List (not for usage questions)" > , OpenStack Operators > > Subject: [openstack-dev] [all] Consistent policy names > > > > The topic of having consistent policy names has popped up a few times this > week. Ultimately, if we are to move forward with this, we'll need a > convention. To help with that a little bit I started an etherpad [0] that > includes links to policy references, basic conventions *within* that service, > and some examples of each. I got through quite a few projects this morning, > but there are still a couple left. > > > > The idea is to look at what we do today and see what conventions we can come > up with to move towards, which should also help us determine how much each > convention is going to impact services (e.g. picking a convention that will > cause 70% of services to rename policies). > > > > Please have a look and we can discuss conventions in this thread. If we come > to agreement, I'll start working on some documentation in oslo.policy so that > it's somewhat official because starting to renaming policies. > > > > [0] https://etherpad.openstack.org/p/consistent-policy-names > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)
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 signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials)
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 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials)
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: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Openstack-sigs] [openstack-dev] Open letter/request to TC candidates (and existing elected officials)
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 [mriede...@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-s...@lists.openstack.org; openstack-operators@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-s...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Open letter/request to TC candidates (and existing elected officials)
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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org
