15:00:17 <smcginnis> #startmeeting releaseteam
15:00:18 <openstack> Meeting started Fri Oct 13 15:00:17 2017 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'releaseteam'
15:00:31 <smcginnis> ping dhellmann, dims, fungi, tonyb, lbragstad, ttx
15:00:36 <ttx> o/
15:00:38 <fungi> yuppp
15:00:44 <lbragstad> o/
15:00:45 <dhellmann> o/
15:00:48 * dhellmann is wrapping up a call
15:00:51 <smcginnis> Happy Friday everyone.
15:01:09 <smcginnis> Agenda: https://etherpad.openstack.org/p/queens-relmgt-tracking
15:01:22 <smcginnis> Looks like we are at line 55.
15:01:48 <smcginnis> #topic Queens-1 Actions
15:02:12 <smcginnis> So six days out to q-1.
15:02:38 <smcginnis> I get the feeling we are in good shape. Anyone know of any issues we need to be paying attention to?
15:02:58 <ttx> nope
15:03:17 <dhellmann> how's the health of the ci system? releases seem to be working...
15:03:25 <smcginnis> Hopefully we have inodes and mirrors and all the good things we need next week. ;)
15:03:30 <fungi> yeah, we got everything back into working order late last night
15:03:31 <ttx> yep most issue fixed now
15:03:42 <ttx> just not on zuulv3
15:03:51 <fungi> if someone can get me a list of the release jobs which failed i can get them rerun right after this meeting
15:04:08 <ttx> inodes are good
15:04:08 <smcginnis> Ian sent out a post last night - looked like all known issues at least are resolved.
15:04:18 <dhellmann> fungi : excellent news
15:04:18 <fungi> unless you'd rather those not propagate out on a friday
15:04:36 <smcginnis> fungi: I'll do that. I think there were just the two the EmilienM mentioned, but I'll look through to see if there were any others that snuck in and let you know them all.
15:04:38 <dhellmann> it's not that much work to re-run by revert/revert either
15:04:48 <EmilienM> o/
15:04:56 <smcginnis> Or revert/revert/revert/revert as the case may be.
15:05:04 <EmilienM> and one from magnum I think
15:05:09 * EmilienM catchs the train
15:05:14 <smcginnis> EmilienM: Thanks!
15:05:36 <EmilienM> please let me know if I can help
15:05:50 <dhellmann> smcginnis : heh
15:05:54 <smcginnis> EmilienM: I hopefully got it covered, but will do. Thanks for offering!
15:06:23 <smcginnis> #action smcginnis to get list of failed releases from the past few days to fungi
15:06:34 <smcginnis> #topic Open discussion
15:06:36 <fungi> ttx: i dunno that i'd call the inode situation "good, but it's at 93% of our capacity when i looked a few minutes ago (so far better than 100%)
15:06:55 <EmilienM> smcginnis: https://review.openstack.org/511463 and https://review.openstack.org/511295 are the only ones AFIK
15:06:56 <smcginnis> 93% - that's still a little scary.
15:07:10 <fungi> we still have bulk deletes of stuff underway
15:07:18 <smcginnis> EmilienM: Awesome, thanks a lot.
15:07:22 <fungi> and are temporarily scaling log retention back from a month to two weeks
15:07:33 <fungi> in order to cope
15:07:39 <smcginnis> fungi: And that's the bit that will take several days to complete?
15:07:51 <fungi> yeah, likely, but everything should be working fine in the interim
15:08:11 <smcginnis> At least it's trending better and not worse. ;)
15:08:16 <fungi> (i don't know what ianw said on the ml yet, still catching up from overnight)
15:08:17 <lbragstad> ++
15:08:33 <smcginnis> OK, update on Kolla ACLs. Did you want to discuss this ttx?
15:08:47 <ttx> yes
15:08:51 <smcginnis> I think I was going to look into it at one point, but IIRC you picked it up?
15:09:20 <ttx> yeah, so the issue is that Kolla and TripleO are not using standard groups re: stable branch reviews
15:09:32 <ttx> which make it hard to apply aclmanager-style rules to them
15:09:52 <dhellmann> are those both cycle-trailing projects?
15:09:52 <ttx> I was about to change them to conform, but TripleO dropped the stable-maint tag
15:09:58 <ttx> dhellmann: yes
15:10:33 <dhellmann> maybe we should document that acl setup as part of having the stable-maint tag
15:10:39 <ttx> so the open question is, should Kolla also drop that tag (should we make that tag non-applicable to deployment things)?
15:10:41 <dhellmann> but I wonder if kolla wants to just drop the tag
15:10:59 <ttx> should we try to build a policy that would work for them
15:11:16 <dhellmann> I think tonyb and EmilienM had a good conversation about creating a separate policy before tripleo dropped the tag
15:11:17 <ttx> basically I don't know what the next step should be here
15:11:42 <dhellmann> and I think based on that it's relatively clear the tag is a bad fit for deployment projects, as it is written today
15:12:13 <EmilienM> afik kolla wants the tag
15:12:13 <dhellmann> so I'd say update the tag to document the acl thing (purely as documentation of an existing expectation) and suggest that kolla not keep the tag
15:12:20 <EmilienM> they recently apply for it
15:12:24 <smcginnis> I do think deployment projects really do need a different tag. The current one was definitely targeted at service projects.
15:12:26 <EmilienM> applied*
15:12:38 <smcginnis> dhellmann: ++
15:12:45 <smcginnis> EmilienM: Kolla recently applied for it?
15:12:46 <EmilienM> ++ for a different tag
15:12:59 <EmilienM> smcginnis: I'm might be wrong but I recall kolla applying for a tag
15:13:01 <EmilienM> let me find it
15:13:20 <EmilienM> https://review.openstack.org/#/c/346455/
15:13:24 <EmilienM> 8 weeks ago
15:13:33 <fungi> i believe kolla expressed a vested interest in adding any tags which would increase their maturity metric in visible places
15:13:34 <EmilienM> they have stable:follows-policy
15:13:45 <dhellmann> maybe update the tag definition to declare it not a good fit for deployment projects, too
15:13:46 <fungi> so as to help drive adoption
15:13:58 <smcginnis> So I still think coming up with a new tag and moving them to that would be the right approach.
15:14:03 <smcginnis> Them and TripleO.
15:14:05 <EmilienM> dhellmann: that and say this tag doesn't tell you a project is really mature, imho
15:14:24 <fungi> they will likely ask for an equivalent tag for deployment-type projects so they can be on equal footing with service projects, from a marketing perspective
15:14:25 <EmilienM> I agree some tags are clearly a sign a project is mature
15:14:26 <dhellmann> hmm, I'm not sure I agree with that, EmilienM. That was sort of the point of having the tag in the first place.
15:14:55 <smcginnis> dhellmann: So I think both of your suggestions are good.
15:14:59 <dhellmann> fungi : I hope they do help drive the definition of that tag (or even "exceptions" or modifications to the existing tag)
15:15:00 <smcginnis> I think the plan could be:
15:15:02 <EmilienM> but stable:follows-policy in the case of installers doesn't tell an installer isn't mature
15:15:15 <fungi> dhellmann: yes, it seems like it would be a good outcome
15:15:18 <smcginnis> 1) Update verbiage in stable-follows-policy to point out ACL requirements
15:15:52 <smcginnis> 2) Update the tag to be explicit it is targeted at service projects.
15:16:06 <EmilienM> dhellmann: I meant to say, this tag in particular. I agree most of other tags are good and define projects as mature
15:16:15 <smcginnis> 3) Create new tag for deployment projects that is roughly the equivalent with some tweaks.
15:16:15 <EmilienM> smcginnis: +1 on this plan
15:16:38 <dhellmann> EmilienM : right, that's what I understood you to be saying. I think this tag should indicate a level of maturity in the *process* used to create and manage the project
15:16:41 <fungi> yep, either that or alternate #3 is use a different maturity scaling metric for deployment projects
15:16:55 <EmilienM> I'll work on 3) and if you don't mind please give some feedback in my proposal
15:17:03 <fungi> thanks EmilienM!
15:17:11 <ttx> smcginnis: sounds good to me
15:17:13 <smcginnis> fungi: There were also some release process constraints that don't quite fit well with that, but yeah.
15:17:41 <dhellmann> EmilienM : maybe work with some of the other deployment project teams, to get some consensus on wording. more than kolla are likely to be interested.
15:17:45 <EmilienM> #action EmilienM to create a new tag for deployment projects that is roughly the equivalent of stable:follows-policy, with some tweaks
15:17:49 <dhellmann> smcginnis : ++
15:17:53 <EmilienM> dhellmann: for sure I will collaborate :D
15:18:07 <smcginnis> EmilienM: Cool, I was just going to ask if you minded taking an action on that. :)
15:18:12 * dhellmann knows he doesn't really need to remind EmilienM to collaborate
15:18:36 <EmilienM> :) thx
15:18:47 <smcginnis> Kind of implicit, but tonyb should be involved in the definition of that tag too.
15:18:56 <dhellmann> good point
15:19:46 <smcginnis> #action smcginnis to propose updates on wording of the stable tag
15:19:51 <smcginnis> I'll work on that part.
15:20:09 <smcginnis> Since you brought up the topic, this all sound good to you ttx?
15:20:27 <smcginnis> Or anything to add/change?
15:20:57 <ttx> nope, all good
15:21:08 <smcginnis> OK, next...
15:21:14 <smcginnis> Relase highlights and next steps
15:21:24 <smcginnis> Strike the "and" theere
15:21:26 <smcginnis> *there
15:21:34 <smcginnis> *release
15:21:38 * lbragstad hands smcginnis more coffee
15:21:39 * smcginnis shakes his head
15:21:51 <smcginnis> lbragstad: Thanks, obviously needed. Ran out of espresso beans this morning.
15:22:00 <lbragstad> ooof - that's rough
15:22:16 <ttx> yes so...
15:22:35 <ttx> About Anne's email this week about next steps there
15:23:03 * ttx loads up plan
15:24:47 <ttx> line 91 on https://etherpad.openstack.org/p/queens-relmgt-plan
15:26:05 <smcginnis> So the idea was a new section in the deliverables/$CYCLE/$PROJECT.yaml file that would get filled in, then we would automate pulling that out and publishing somewhere IIRC.
15:26:29 <dhellmann> yes
15:27:14 <dhellmann> I can advise on implementation, but this is an excellent opportunity for someone else to get their hands dirty on that code
15:27:21 <ttx> anyone wanting to take it ? Otherwise I'll add it to my plate, hoping I'll get to it
15:27:39 <smcginnis> Hate to change the plan at this stage, but would it actually be possible to add something to reno where PTLs could put some sort of tag on a release note item that would tell it "This is important, publish this in a release highlights page"?
15:27:48 <ttx> Won't probably have time for both the storyboard stuff and this
15:27:54 <smcginnis> Just thinking of reducing duplication of effort on the PTLs part.
15:28:16 <fungi> are release notes the same level of detail you'd want for highlights?
15:28:17 <dhellmann> smcginnis : reno already has a "prelude" feature for that. We decided in denver that the audience for these notes was different enough that it made sense to write something separately.
15:28:33 <smcginnis> dhellmann: Right, so that's why I'm thinking of a separate tag.
15:28:33 <ttx> I think the idea is that you can't tell if it's a release highlight before you are at release time
15:28:41 <dhellmann> release notes are for users/deployers; these things are for marketing and analysts
15:28:45 <ttx> right
15:28:52 <dhellmann> smcginnis : ah, I see
15:28:54 <fungi> yeah, i see ~3 levels of detail/kinds of audience... highlights, release notes, commit logs
15:29:08 <smcginnis> OK, just a brainstorm idea. Let's stick with what we already discussed.
15:29:13 <fungi> and commit logs are more targeted at the developers
15:29:21 <fungi> so there you have your three base audiences i guess
15:29:41 <dhellmann> I guess the other benefit of doing it here is as fungi pointed out you can do it at the end of the cycle. it also puts all of the items in one place for the consumer.
15:30:15 <smcginnis> And there's a better mental context for what you would want to say here vs just highlighting significant release notes.
15:30:26 <dhellmann> ++
15:30:29 <fungi> right, in much the same way that you may have several commits implementing something covered by a given release note, you may have several release note items which feed into a single highlight
15:30:43 <dhellmann> we should write down all of this reasoning for when we roll out the new thing and have to explain it to ptls :-)
15:30:48 <fungi> so summary of a summary
15:30:52 <smcginnis> :)
15:31:32 <smcginnis> ttx: I can take this if you want.
15:31:58 <smcginnis> I'll follow on to Anne's ML post with another one that explains the new process and the reasoning behind it.
15:32:06 <smcginnis> Once we have that new process in place.
15:32:29 <ttx> smcginnis: cool, thanks
15:33:00 <smcginnis> Do we have a place for these to be published already? A sub-page off of releases.o.o?
15:33:02 <ttx> added your name on it
15:33:10 <smcginnis> ttx: Thanks
15:33:11 <dhellmann> smcginnis : not yet, that will be part of the implementation work
15:33:34 <ttx> made it a HIGH TODO since we want to complete that before the end of the cycle
15:33:40 <dhellmann> I envision a new sphinx directive, but we might also be able to use a simple template if we only want one page at a time
15:34:03 <smcginnis> Probably be good to have in place by q-2 just to work out issues and help with communication, if at all possible.
15:34:14 <dhellmann> that deadline makes sense
15:34:51 <smcginnis> Alright, anything else to discuss?
15:34:53 <fungi> a one-pager would likely be best, with all the projects who provided highlights for that release combined somehow
15:35:08 <smcginnis> For a short initial agenda, we've certainly found plenty to talk about.
15:35:11 <dhellmann> fungi : yeah, I guess the question is 1 page per cycle or 1 page total
15:35:12 <smcginnis> fungi: ++
15:35:21 <fungi> market analysts aren't going to want to need to browse dozens of per-project pages some of which may even be blank
15:35:30 <smcginnis> I think 1 page per cycle would be most consumable.
15:35:31 <ttx> 1 page per cycle I'd say
15:35:39 <fungi> right
15:35:59 <dhellmann> ok. so that's either a new directive or a creative use of sphinxcontrib-datatemplates
15:36:00 <fungi> good point, some have multiple "releases" per cycle
15:36:14 <fungi> but i meant per release cycle of course
15:36:14 <ttx> EmilienM: are you interested in drafting a variant of the stable policy that would match TripleO needs ?
15:36:41 <smcginnis> Should we just do the release highlights for the cycle-with-milestone projects to start?
15:36:42 <ttx> I can work on tweaking the original one but that should probably happen at the same time
15:36:46 <dhellmann> ttx: I think he agreed to take that action?
15:36:58 <ttx> oh, missed it
15:37:01 <ttx> ok
15:37:08 <dhellmann> smcginnis : I think we want "service" projects regardless of release model
15:37:10 <fungi> it may also be useful to decide that highlights aren't relevant to stable point releases too
15:37:26 <EmilienM> ttx: yes, I think that's what I proposed to do
15:37:31 <smcginnis> fungi: Good point.
15:37:38 <dhellmann> fungi : yeah, the data model we agreed on was 1 set of highlights per deliverable file
15:37:44 <fungi> wfm
15:37:46 <dhellmann> so effectively 1 set for a deliverable for a cycle
15:37:57 <smcginnis> And what about the independent projects?
15:37:59 <dhellmann> which is not the current data model, but changing that was part of the work items for this
15:38:00 <fungi> yeah, that seems like a great fit
15:38:09 <dhellmann> independent projects are not technically considered to be "part of" the release
15:38:16 <ttx> EmilienM: ok, let me know when you have something, so that I coordinate the change to the other one. I'll push it as Workflow-1 in the meantime
15:38:16 <dhellmann> they are independent of the cycle, and the release
15:38:32 <smcginnis> OK, just making sure we didn't want to try to do something there as well.
15:38:53 <dhellmann> smcginnis : although limiting it to service projects would eliminate the deployment tools, so maybe that's not the right criteria either
15:39:07 <dhellmann> and if we add a major new thing to a library, I think we'd want to mention that because it applies to all projects
15:39:11 <smcginnis> Just anything under deliverable/*
15:39:28 <dhellmann> so maybe we just want all projects that have the cycle-based models to be allowed to have these and require it for service projects?
15:39:42 <smcginnis> dhellmann: But library changes in some cases are more relevant in release notes for library consumers I think.
15:39:56 <smcginnis> Guess it depends on the lib though.
15:40:09 <dhellmann> if I add the ability to have secret stores in oslo.config, that may be something analysts would want to know about
15:40:14 <dhellmann> s/I/someone else/
15:40:44 <dhellmann> it's a difference of where we want to *require* content and where we want to *allow* it
15:40:53 <smcginnis> Or would they just care about the consuming projects being able to add functionality because of that.
15:40:56 <dhellmann> let's be flexible for the latter, and minimalist for the former
15:41:11 <dhellmann> that specific feature is transparent to the application -- that's the point of most of those libraries
15:41:43 <dhellmann> when castellan adds support for vault, all applications can use it immediately *without the application developer knowing*
15:42:08 <smcginnis> OK, well we can get started with something and then tweak it from there once we have something in place I suppose.
15:42:11 <dhellmann> ++
15:42:36 <smcginnis> Anything else we should discuss in the meeting?
15:43:44 <smcginnis> I guess that's a no.
15:43:51 * dhellmann has nothing
15:43:56 <fungi> infra has decided to roll back to zuul v3 late on sunday
15:43:57 <smcginnis> OK, thanks everyone.
15:44:05 <fungi> that's really the only infra update i have though
15:44:12 <smcginnis> fungi: OK, good.
15:44:25 <smcginnis> And Monday morning everything will be working perfectly, right? :)
15:44:33 <fungi> that's the expectation
15:44:58 <smcginnis> OK, thanks all.
15:45:06 <smcginnis> #endmeeting