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