[Openstack-operators] [goals][upgrade-checkers] Week R-26 Update
The big update this week is version 0.1.0 of oslo.upgradecheck was released. The documentation along with usage examples can be found here [1]. A big thanks to Ben Nemec for getting that done since a few projects were waiting for it. In other updates, some changes were proposed in other projects [2]. And finally, Lance Bragstad and I had a discussion this week [3] about the validity of upgrade checks looking for deleted configuration options. The main scenario I'm thinking about here is FFU where someone is going from Mitaka to Pike. Let's say a config option was deprecated in Newton and then removed in Ocata. As the operator is rolling through from Mitaka to Pike, they might have missed the deprecation signal in Newton and removal in Ocata. Does that mean we should have upgrade checks that look at the configuration for deleted options, or options where the deprecated alias is removed? My thought is that if things will not work once they get to the target release and restart the service code, which would definitely impact the upgrade, then checking for those scenarios is probably OK. If on the other hand the removed options were just tied to functionality that was removed and are otherwise not causing any harm then I don't think we need a check for that. It was noted that oslo.config has a new validation tool [4] so that would take care of some of this same work if run during upgrades. So I think whether or not an upgrade check should be looking for config option removal ultimately depends on the severity of what happens if the manual intervention to handle that removed option is not performed. That's pretty broad, but these upgrade checks aren't really set in stone for what is applied to them. I'd like to get input from others on this, especially operators and if they would find these types of checks useful. [1] https://docs.openstack.org/oslo.upgradecheck/latest/ [2] https://storyboard.openstack.org/#!/story/2003657 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17 [4] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html -- Thanks, Matt ___ 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
Sending a follow up here quick. The reviewers actively participating in [0] are nearing a conclusion. Ultimately, the convention is going to be: :[:][:]:[:] Details about what that actually means can be found in the review [0]. Each piece is denoted as being required or optional, along with examples. I think this gives us a pretty good starting place, and the syntax is flexible enough to support almost every policy naming convention we've stumbled across. Now is the time if you have any final input or feedback. Thanks for sticking with the discussion. Lance [0] https://review.openstack.org/#/c/606214/ On Mon, Oct 8, 2018 at 8:49 AM Lance Bragstad wrote: > > On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann > wrote: > >> On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad < >> lbrags...@gmail.com> 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 >> > > I agree. I simplified this in the current version up for review. > > >> >> -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 < >> lbrags...@gmail.com> wrote: >> > >>> >> > >>> >> > >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann < >> gm...@ghanshyammann.com> wrote: >> > >> > On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt < >> j...@johngarbutt.com> wrote >> > > tl;dr+1 consistent names >> > >
Re: [Openstack-operators] [openstack-dev] [SIGS] Ops Tools SIG
On Fri, Oct 12, 2018 at 11:25:20AM +0200, Martin Magr wrote: > Greetings guys, > > On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo < > majop...@redhat.com> wrote: > > > Adding the mailing lists back to your reply, thank you :) > > > > I guess that +melvin.hills...@huawei.com can > > help us a little bit organizing the SIG, > > but I guess the first thing would be collecting a list of tools which > > could be published > > under the umbrella of the SIG, starting by the ones already in Osops. > > > > Publishing documentation for those tools, and the catalog under > > docs.openstack.org > > is possibly the next step (or a parallel step). > > > > > > On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister > > wrote: > > > >> Hi Miguel, > >> > >> I would love to join this. What do I need to do? > >> > >> Sent from my iPhone > >> > >> On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo > >> wrote: > >> > >> Hello > >> > >> Yesterday, during the Oslo meeting we discussed [6] the possibility > >> of creating a new Special Interest Group [1][2] to provide home and release > >> means for operator related tools [3] [4] [5] > >> > >> > all of those tools have python dependencies related to openstack such as > python-openstackclient or python-pbr. Which is exactly the reason why we > moved osops-tools-monitoring-oschecks packaging away from OpsTools SIG to > Cloud SIG. AFAIR we had some issues of having opstools SIG being dependent > on openstack SIG. I believe that Cloud SIG is proper home for tools like > [3][4][5] as they are related to OpenStack anyway. OpsTools SIG contains > general tools like fluentd, sensu, collectd. > > > Hope this helps, > Martin > Hey Martin, I'm not sure I understand the issue with these tools have dependencies on other packages and the relationship to SIG ownership. Is your concern (or the history of a concern you are pointing out) that the tools would have a more difficult time if they required updates to dependencies if they are owned by a different group? Thanks! Sean ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [kayobe][kolla] Announcing the release of Kayobe 4.0.0
Hi, Announcing the release of Kayobe 4.0.0. This release includes support for the Queens release of OpenStack, and is the first release of Kayobe built using the OpenStack infrastructure. Release notes: https://kayobe-release-notes.readthedocs.io/en/latest/queens.html#relnotes-4-0-0-stable-queens Documentation: https://kayobe.readthedocs.io Thanks to everyone who contributed to this release! Looking forward, we intend to catch up with the OpenStack release cycle, by making a smaller release with support for OpenStack Rocky, then moving straight onto Stein. Cheers, Mark ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
