Re: [Openstack-operators] [sean.mcgin...@gmx.com: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables]
Sean McGinnis writes: [snip] > The only problem we've seen is without the milestone releases during the > cycle, > there is quite a gap before the version numbers get incremented for anyone > doing more frequent testing. We wanted to reach out the operator community > since I know there are at least a few of you that do "roll your own" for > deploying upstream code. [snip] This specifically affects folks doing *upgrade* testing from the stable branch to pre-release versions on master, since during this period of time the version on master appears lower than the version on the stable branch. Doug ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [sean.mcgin...@gmx.com: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables]
Hello operators! I'm trying to reach out to more folks that this might impact. There are nitty gritty details below, but to summarize - the release team is looking at changing the way we currently do releases for the main service projects. So far, we have been doing three milestone releases throughout a development cycle, one or more release candidates, then the final release for the cycle. From what we could tell, these milestone releases were really not being used by anyone (mostly) so to a degree, they were just busy work that we were imposing on the project teams. We are thinking of changing the release model to get rid of the milestones and just do the release candidates as we finalize the release. Those can be considered close to done for the purposes of those wanting to get an early start on testing deployments and doing any kind of packaging. The only problem we've seen is without the milestone releases during the cycle, there is quite a gap before the version numbers get incremented for anyone doing more frequent testing. We wanted to reach out the operator community since I know there are at least a few of you that do "roll your own" for deploying upstream code. If anyone knows this change would have a negative impact for you, please do let us know so we can take that into consideration or can make any tweaks to our plans. We want to reduce work put on the teams, but we don't want to do that at the expense of preventing others from being able to get their work done. Thanks! Sean - Forwarded message from Sean McGinnis - Date: Wed, 26 Sep 2018 09:22:30 -0500 From: Sean McGinnis To: openstack-...@lists.openstack.org Subject: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables Reply-To: "OpenStack Development Mailing List (not for usage questions)" User-Agent: Mutt/1.10.1 (2018-07-13) During the Stein PTG in Denver, the release management team talked about ways we can make things simpler and reduce the "paper pushing" work that all teams need to do right now. One topic that came up was the usefulness of pushing tags around milestones during the cycle. There were a couple of needs identified for doing such "milestone releases": 1) It tests the release automation machinery to identify problems before the RC and final release crunch time. 2) It creates a nice cadence throughout the cycle to help teams stay on track and focus on the right things for each phase of the cycle. 3) It gives us an indication that teams are healthy, active, and planning to include their components in the final release. One of the big motivators in the past was also to have output that downstream distros and users could pick up for testing and early packaging. Based on our admittedly anecdotal small sample, it doesn't appear this is actually a big need, so we propose to stop tagging milestone releases for the cycle-with-milestone projects. We would still have "milestones" during the cycle to facilitate work organization and create a cadence: teams should still be aware of them, and we will continue to communicate those dates in the schedule and in the release countdown emails. But you would no longer be required to request a release for each milestone. Beta releases would be optional: if teams do want to have some beta version tags before the final release they can still request them - whether on one of the milestone dates, or whenever there is the need for the project. Release candidates would still require a tag. To facilitate that step and guarantee we have a release candidate for every deliverable, the release team proposes to automatically generate a release request early in the week of the RC deadline. That patch would be used as a base to communicate with the team: if a team wants to wait for a specific patch to make it to the RC, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA. If there are no issues, ideally we would want a +1 from the PTL and/or release liaison to indicate approval, but we would also consider no negative feedback as an indicator that the automatically proposed patches without a -1 can all be approved at the end of the RC deadline week. To cover point (3) above, and clearly know that a project is healthy and should be included in the coordinated release, we are thinking of requiring a person for each team to add their name to a "manifest" of sorts for the release cycle. That "final release liaison" person would be the designated person to follow through on finishing out the releases for that team, and would be designated ahead of the final release phases. With all these changes, we would rename the cycle-with-milestones release model to something like cycle-with-rc. FAQ: Q: Does this mean I don't need to pay attention to releases any more and the release team will just take care of everything? A: No. We still want teams engaged in the release
Re: [Openstack-operators] [openstack-dev] [all] Consistent policy names
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 > 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 > > > 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
