Re: [Openstack-operators] [openstack-dev] [all] Consistent policy names
On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt
wrote
> tl;dr+1 consistent names
> I would make the names mirror the API... because the Operator setting them
> knows the API, not the codeIgnore the crazy names in Nova, I certainly hate
> them
Big +1 on consistent naming which will help operator as well as developer to
maintain those.
>
> Lance Bragstad wrote:
> > I'm curious if anyone has context on the "os-" part of the format?
>
> My memory of the Nova policy mess...* Nova's policy rules traditionally
> followed the patterns of the code
> ** Yes, horrible, but it happened.* The code used to have the OpenStack API
> and the EC2 API, hence the "os"* API used to expand with extensions, so the
> policy name is often based on extensions** note most of the extension code
> has now gone, including lots of related policies* Policy in code was focused
> on getting us to a place where we could rename policy** Whoop whoop by the
> way, it feels like we are really close to something sensible now!
> Lance Bragstad wrote:
> Thoughts on using create, list, update, and delete as opposed to post, get,
> put, patch, and delete in the naming convention?
> I could go either way as I think about "list servers" in the API.But my
> preference is for the URL stub and POST, GET, etc.
> On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad
> wrote: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").
> +1The API is known as "compute" in api-ref, so the policy should be for
> "compute", etc.
Agree on mapping the policy name with api-ref as much as possible. Other than
policy name having 'os-', we have 'os-' in resource name also in nova API url
like /os-agents, /os-aggregates etc (almost every resource except servers ,
flavors). As we cannot get rid of those from API url, we need to keep the same
in policy naming too? or we can have policy name like
compute:agents:create/post but that mismatch from api-ref where agents resource
url is os-agents.
Also we have action API (i know from nova not sure from other services) like
POST /servers/{server_id}/action {addSecurityGroup} and their current policy
name is all inconsistent. few have policy name including their resource name
like "os_compute_api:os-flavor-access:add_tenant_access", few has 'action' in
policy name like "os_compute_api:os-admin-actions:reset_state" and few has
direct action name like "os_compute_api:os-console-output"
May be we can make them consistent with
:: or any better opinion.
> From: Lance Bragstad > The topic of having consistent
> policy names has popped up a few times this week.
>
> I would love to have this nailed down before we go through all the policy
> rules again. In my head I hope in Nova we can go through each policy rule
> and do the following:
> * move to new consistent policy name, deprecate existing name* hardcode
> scope check to project, system or user** (user, yes... keypairs, yuck, but
> its how they work)** deprecate in rule scope checks, which are largely bogus
> in Nova anyway* make read/write/admin distinction** therefore adding the
> "noop" role, amount other things
+ policy granularity.
It is good idea to make the policy improvement all together and for all rules
as you mentioned. But my worries is how much load it will be on operator side
to migrate all policy rules at same time? What will be the deprecation period
etc which i think we can discuss on proposed spec -
https://review.openstack.org/#/c/547850
-gmann
> Thanks,John
> __
> 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
Re: [Openstack-operators] [Openstack-sigs] Capturing Feedback/Input
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-s...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Kind regards, Melvin Hillsman mrhills...@gmail.com mobile: (832) 264-2646 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Openstack-sigs] Capturing Feedback/Input
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 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-dev] [neutron] heads up to long time ovs users...
The important point of this notice is that packet drops will happen when switching of_interface option from ovs-ofctl (which was the default value in the old releases) to native (which is the current default ). Once neutron drops the option, if deployers use the legacy value "ovs-ofctl", they will hit some packet losses when upgrading neutron to Stein. We have no actual data on large deployments so far and don't know how this change impacts real deployments. Your feedback would be really appreciated. Best regards, Akihiro Motoki (irc: amotoki) 2018年9月21日(金) 10:37 IWAMOTO Toshihiro : > The neutron team is finally removing the ovs-ofctl option. > > https://review.openstack.org/#/c/599496/ > > The ovs-ofctl of_interface option wasn't default since Newton and was > deprecated in Pike. > > So, if you are a long time ovs-agent user and upgrading to a new > coming release, you must switch from the ovs-ofctl implementation to > the native implementation and are affected by the following issue. > > https://bugs.launchpad.net/neutron/+bug/1793354 > > The loss of communication mentioned in this bug report would be a few > seconds to a few minutes depending on the number of network > interfaces. It happens when an ovs-agent is restarted with the new > of_interface (so only once during the upgrade) and persists until the > network interfaces are set up. > > Please speak up if you cannot tolerate this during upgrades. > > IIUC, this bug is unfixable and I'd like to move forward as > maintaining two of_interface implementation is a burden for the > neutron team. > > -- > IWAMOTO Toshihiro > > > __ > 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
