Re: [Openstack-operators] [openstack-dev] [all] Consistent policy names
If we consider dropping "os", should we entertain dropping "api", too? Do we have a good reason to keep "api"? I wouldn't be opposed to simple service types (e.g "compute" or "loadbalancer"). On Sat, Sep 15, 2018 at 9:01 AM Morgan Fainberg wrote: > I am generally opposed to needlessly prefixing things with "os". > > I would advocate to drop it. > > > On Fri, Sep 14, 2018, 20:17 Lance Bragstad wrote: > >> Ok - yeah, I'm not sure what the history behind that is either... >> >> I'm mainly curious if that's something we can/should keep or if we are >> opposed to dropping 'os' and 'api' from the convention (e.g. >> load-balancer:loadbalancer:post as opposed to >> os_load-balancer_api:loadbalancer:post) and just sticking with the >> service-type? >> >> On Fri, Sep 14, 2018 at 2:16 PM Michael Johnson >> wrote: >> >>> I don't know for sure, but I assume it is short for "OpenStack" and >>> prefixing OpenStack policies vs. third party plugin policies for >>> documentation purposes. >>> >>> I am guilty of borrowing this from existing code examples[0]. >>> >>> [0] >>> http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html >>> >>> Michael >>> On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad >>> wrote: >>> > >>> > >>> > >>> > On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson >>> wrote: >>> >> >>> >> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post" >>> >> which maps to the "os--api::" format. >>> > >>> > >>> > Thanks for explaining the justification, Michael. >>> > >>> > I'm curious if anyone has context on the "os-" part of the format? >>> I've seen that pattern in a couple different projects. Does anyone know >>> about its origin? Was it something we converted to our policy names because >>> of API names/paths? >>> > >>> >> >>> >> >>> >> 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-...@lists.openstack.org>, OpenStack Operators < >>> openstack-operators@lists.openstack.org> >>> >> > 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 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 >>> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>
Re: [Openstack-operators] [tc][uc]Community Wide Long Term Goals
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: 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] Open letter/request to TC candidates (and existing elected officials)
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]. As the TC is currently vouching for the goals of a cycle, I strongly agree that there is need for the TC to be in-line with the what our users are asking, and those converting business requirements to technical decisions. I strongly agree the TC should be in contact with the UC and SIGs, as both are representing user focuses (the former one is more global, while the latter is more contextual). 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. Multiple points in that. 1) I agree with the "I want my elected TC members to be pushing tangible technical deliverables forward.". 2) I acknowledge the fact that not all the TC members are in a position like Ildikos or Doug. I am glad I am in an employer that believe in contributing upstream and lets me enough room to do so, being given a good incentive to do so. 3) "Necessity" + "sufficiency" vs expectations. I'd like TC members to give their times to push technical changes forward. But I would also hope non TC members would doing so. So, I am fine with Dan's opinion: _expected_ to work on improving technically OpenStack, and therefore helping PTLs (and other people) to focus on their work/"other side of the pond". 4) If you are to think TC as companies' project managers, I would think this view is incomplete. At best it would be program managers and/or product owners that can/should take a project manager role. The problem with that notion is that project managers have 3 axis to play with (time, scope, and cost), where TC members only have one with community goals (scope, as time is constrained to a cycle, and cost is unclear/outside PM hands). If you've been to that position for a long time, you know this cannot be healthy and very demoralizing. For me, there is a small link that can _wrongly_ be done: as the TC is an official "organism" of OpenStack, it could as some point be expected to deliver these projects intact in a timely fashion without having the resources to do so. So, for me, the best way to think the goals should be a 'best effort' work, and everyone championing is expected to do their best. I think we are good at that for now, and doesn't need change. If you change the mindset into being expected to deliver (as this could become a very strong force for openstack), I'd say there are two risks: - More time involved in PM duties to gather resources upfront - Less deliverables proposed, as some could be higher risk and therefore not tried. - Possible finger pointing to "this champion didn't manage to achieve its goals" or diluted goals when no resource available. I am therefore not sure we'll able to go to that mindset in the current way OpenStack and companies are organized. I don't find any value in the TC debating ad nauseam about visions and constellations and "what is openstack?". Agree. I have an opinion of what OpenStack is, but I don't believe discussing it over the mailing list in this message would be helpful in any way. We can have this chat over drinks to see if we are aligned, but I am not sure it matters :p 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. Agreed. 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. Your question is unclear to me. If users want x, this is a good feedback for TC, and therefore should be passed to projects. If x is 'how things are done technically in a project', I do not believe TC have to deal with that: maybe some tc members would deal with it, but not as tc members, more said projects contributors. if x is a governance of OpenStack topic, I would hope tc would get involved the earliest possible. 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?"
