Re: [Openstack-operators] Berlin Community Contributor Awards
Hello :) I wanted to bring this to the top of people's inboxes as we have three weeks left to submit community members[1]. I can think of a dozen people right now that deserve an award and I am sure you all could do the same. It only takes a few minutes and its an easy way to make sure they get the recognition they deserve. Show your appreciation and nominate one person. -Kendall (diablo_rojo) [1] https://openstackfoundation.formstack.com/forms/berlin_stein_ccas On Fri, Aug 24, 2018 at 11:15 AM Kendall Nelson wrote: > Hello Everyone! > > As we approach the Summit (still a ways away thankfully), I thought I > would kick off the Community Contributor Award nominations early this > round. > > For those of you that already know what they are, here is the form[1]. > > For those of you that have never heard of the CCA, I'll briefly explain > what they are :) We all know people in the community that do the dirty > jobs, we all know people that will bend over backwards trying to help > someone new, we all know someone that is a savant in some area of the code > we could never hope to understand. These people rarely get the thanks they > deserve and the Community Contributor Awards are a chance to make sure they > know that they are appreciated for the amazing work they do and skills they > have. > > So go forth and nominate these amazing community members[1]! Nominations > will close on October 21st at 7:00 UTC and winners will be announced at the > OpenStack Summit in Berlin. > > -Kendall (diablo_rojo) > > [1] https://openstackfoundation.formstack.com/forms/berlin_stein_ccas > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [all] Consistent policy names
On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad wrote > > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote: > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg > wrote: > > > > Ideally I would like to see it in the form of least specific to most > specific. But more importantly in a way that there is no additional > delimiters between the service type and the resource. Finally, I do not like > the change of plurality depending on action type. > > > > I propose we consider > > > > ::[:] > > > > Example for keystone (note, action names below are strictly examples I am > fine with whatever form those actions take): > > identity:projects:create > > identity:projects:delete > > identity:projects:list > > identity:projects:get > > > > It keeps things simple and consistent when you're looking through > overrides / defaults. > > --Morgan > +1 -- I think the ordering if `resource` comes before > `action|subaction` will be more clean. > > ++ > These are excellent points. I especially like being able to omit the > convention about plurality. Furthermore, I'd like to add that I think we > should make the resource singular (e.g., project instead or projects). For > example: > compute:server:list > compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize > (or confirm-resize) Do we need "action" word there? I think action name itself should convey the operation. IMO below notation without "äction" word looks clear enough. what you say? compute:server:reboot compute:server:confirm_resize -gmann > > Otherwise, someone might mistake compute:servers:get, as "list". This is > ultra-nick-picky, but something I thought of when seeing the usage of > "get_all" in policy names in favor of "list." > In summary, the new convention based on the most recent feedback should be: > ::[:] > Rules:service-type is always defined in the service types authority > resources are always singular > Thanks to all for sticking through this tedious discussion. I appreciate it. > > /R > > Harry > > > > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad > wrote: > >> > >> Bumping this thread again and proposing two conventions based on the > discussion here. I propose we decide on one of the two following conventions: > >> > >> :: > >> > >> or > >> > >> :_ > >> > >> Where is the corresponding service type of the project > [0], and is either create, get, list, update, or delete. I think > decoupling the method from the policy name should aid in consistency, > regardless of the underlying implementation. The HTTP method specifics can > still be relayed using oslo.policy's DocumentedRuleDefault object [1]. > >> > >> I think the plurality of the resource should default to what makes sense > for the operation being carried out (e.g., list:foobars, create:foobar). > >> > >> I don't mind the first one because it's clear about what the delimiter > is and it doesn't look weird when projects have something like: > >> > >> ::: > >> > >> If folks are ok with this, I can start working on some documentation > that explains the motivation for this. Afterward, we can figure out how we > want to track this work. > >> > >> What color do you want the shed to be? > >> > >> [0] https://service-types.openstack.org/service-types.json > >> [1] > https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule > >> > >> On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad > wrote: > >>> > >>> > >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann > wrote: > > 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,
Re: [Openstack-operators] [openstack-dev] [all] Consistent policy names
On Sat, 29 Sep 2018 07:23:30 +0900 Lance Bragstad wrote > Alright - I've worked up the majority of what we have in this thread and > proposed a documentation patch for oslo.policy [0]. > I think we're at the point where we can finish the rest of this discussion > in gerrit if folks are ok with that. > [0] https://review.openstack.org/#/c/606214/ +1, thanks for that. let's start the discussion there. -gmann > On Fri, Sep 28, 2018 at 3:33 PM Sean McGinnis wrote: > On Fri, Sep 28, 2018 at 01:54:01PM -0500, Lance Bragstad wrote: > > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki wrote: > > > > > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg > > > wrote: > > > > > > > > Ideally I would like to see it in the form of least specific to most > > > specific. But more importantly in a way that there is no additional > > > delimiters between the service type and the resource. Finally, I do not > > > like the change of plurality depending on action type. > > > > > > > > I propose we consider > > > > > > > > ::[:] > > > > > > > > Example for keystone (note, action names below are strictly examples I > > > am fine with whatever form those actions take): > > > > identity:projects:create > > > > identity:projects:delete > > > > identity:projects:list > > > > identity:projects:get > > > > > > > > It keeps things simple and consistent when you're looking through > > > overrides / defaults. > > > > --Morgan > > > +1 -- I think the ordering if `resource` comes before > > > `action|subaction` will be more clean. > > > > > > > Great idea. This is looking better and better. > __ > 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-operators] [nova] nova-xvpvncproxy CLI options
tl;dr: Is anyone calling 'nova-novncproxy' or 'nova-serialproxy' with CLI arguments instead of a configuration file? I've been doing some untangling of the console proxy services that nova provides and trying to clean up the documentation for same [1]. As part of these fixes, I noted a couple of inconsistencies in how we manage the CLI options for these services. Firstly, the 'nova-novncproxy' and 'nova-serialproxy' services accept CLI configuration options while the 'nova-xvpvncproxy' service does not. $ nova-novncproxy --help usage: nova-novncproxy [-h] [--vnc-auth_schemes VNC_AUTH_SCHEMES] [--vnc-novncproxy_host VNC_NOVNCPROXY_HOST] [--vnc-novncproxy_port VNC_NOVNCPROXY_PORT] [--vnc-vencrypt_ca_certs VNC_VENCRYPT_CA_CERTS] [--vnc-vencrypt_client_cert VNC_VENCRYPT_CLIENT_CERT] [--vnc-vencrypt_client_key VNC_VENCRYPT_CLIENT_KEY] [--cert CERT] [--config-dir DIR] [--config-file PATH] ... [--remote_debug-port REMOTE_DEBUG_PORT] $ nova-xvpvncproxy --help usage: nova-xvpvncproxy [-h] [--remote_debug-host REMOTE_DEBUG_HOST] [--remote_debug-port REMOTE_DEBUG_PORT] ... [--version] [--watch-log-file] This means that you could, conceivably, run 'nova-novncproxy' without a configuration file but the same would not be possible with the 'nova- xvpvncproxy' service. Secondly, the 'nova-novncproxy' CLI options are added to a 'vnc' group, meaning they appear with an unnecessary 'vnc-' prefix (e.g. '--vnc-novncproxy_host'), and the 'nova-serialproxy' CLI options are prefixed with 'serial-' for the same reason. Finally, none of these options are documented anywhere. My initial plan [2] to resolve all of the above had been to add the CLI options to the 'nova-xvpvncproxy' service and then go figure out how to get oslo.config autodocumenting these for us in our man pages. However, a quick search through GitHub, codesearch.o.o and Google turned up no hits so I wonder if anyone is configuring these things by CLI? If not, maybe we should just go and remove this code and insist on configuration via config file? Cheers, Stephen [1] https://review.openstack.org/606148 [2] https://review.openstack.org/606929 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
