16:02:13 #startmeeting OpenStack-Ansible 16:02:13 Meeting started Thu Mar 24 16:02:13 2016 UTC and is due to finish in 60 minutes. The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:17 The meeting name has been set to 'openstack_ansible' 16:02:51 o/ 16:02:54 #topic Agenda & roll call 16:02:57 o/ 16:02:57 o/ 16:03:07 #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 16:03:12 o/ 16:03:12 sorry, always pre-roll call raise my hand 16:03:13 o/ 16:03:16 \o/ 16:03:38 o/ 16:03:48 o/ 16:04:29 The only action item from last week was for me to release Liberty 12.0.8 and Kilo 11.2.11, which was done - so we're good. 16:05:05 \o/ 16:05:07 one of our topics from last week slipped the agenda as it was stuck on the bottom - I only noticed it this week 16:05:16 #topic Release notes in IRRs 16:05:22 o/ 16:05:26 palendae ping? 16:05:33 o/ 16:05:46 * odyssey4me hands the mic to palendae 16:05:59 o/ 16:06:14 o/ 16:06:20 That one's been a while. So I had a question regarding release notes in repositories. I think the current state is to make a change in the repositories then put the release note in openstack-ansible 16:06:55 However, I think putting the release note in just one of the repositories potentially misses communication for either of the audiences - those who consume it as a whole, and those who take just a role 16:07:07 Currently, there isn't tooling to "roll up" role release notes, though 16:07:37 So I'm not sure what would be best, but I think both people using OSA as a whole and people using individual roles should be able to see their relevant release notes close to the changes 16:08:26 I think I'm done laying out my thoughts there :) 16:08:31 +1 on release notes being visible in the individual roles for those who are using them 16:09:00 A related topic is how tags/releases are going to be handled on the IRRs 16:09:05 yeah, I would prefer for release notes to be coupled with the patch as intended - so I'd like to see that trend continue, and I'd be happy to instrument all the roles for release note publishing 16:09:06 I do also agree that there should ideally be some sort of roll-up mechanism 16:09:10 +1 and I think it's on the agenda for summit 16:10:14 Ok. We may have to engage with reno to work on the roll up 16:10:14 our basic agreement thus far is for all roles to br branched using the openstack branch name - eg: stable/mitaka - and to be tagged when we release mitaka 16:11:07 The tag numbers, I can't recall whether we got to an agreement at the mid-cycle on that. 16:11:23 think it was tag on commit 16:11:40 is OSA following the mitaka branch of projects that have that yet? 16:11:57 We should perhaps have a focused discussion on that next week. I'd rather not tangent on the release note topic this week. 16:12:05 Fair enough 16:12:18 palendae would you like to engage in #openstack-release regarding a release note roll-up? 16:12:25 or would you prefer me to? 16:12:32 I can 16:12:50 ok, it's not urgent - but I think it's be best to raise it as a desired intent prior to the summit 16:13:02 I'll follow up at the summit in the cross-project/releases sessions. 16:13:04 Yeah. It may be a bug/blueprint for reno 16:13:13 Probably blueprint 16:13:20 initially just have a chat with dhellmann and take it from there 16:14:15 #action palendae to discuss the possibility of cross-repository release note roll-ups (in publishing) for the roll-up of release notes from the roles into the OSA integrated releases 16:14:23 I'd rather we have roll up before we scatter release notes to the wind. The primary case is to collect them in OSA and we should still try to serve that first IMO. 16:15:03 stevelle right, for the moment I'd prefer that we have the reno with the patch - and then ask for a reno patch in the integrated repo 16:15:16 this covers us while we figure out whether roll-up is an option 16:15:51 any objections to that strategy? 16:16:03 nope 16:16:08 I think we've largely been doing that in the last few weeks anyway. 16:16:09 it if means submitting two renos, it's additional work but I can accept that 16:16:48 Would they get different SHAs? 16:16:51 And does that matter? 16:17:11 By SHAs I mean the IDs on the reno filename 16:17:13 palendae very possibly, and we'll have to cross that bridge when we get there I guess 16:17:23 Ok. I can see if that matters 16:17:28 Or the file can be copied 16:17:34 ah, that all depends on the submitter - personally I just copy the same file over 16:17:54 I would prefer that to be done as it may help reduce duplication if we get to the point of rollingup 16:17:59 Yeah 16:18:24 core reviewers, please bear these things in mind when doing reviews 16:18:56 #info core reviewers to expect release notes with patches (where appropriate), and the same reno should be submitted to the main repo 16:19:12 happy to move on to the next topic? 16:19:24 I am, yes 16:19:40 yep 16:20:30 #topic Early tag of Liberty 16:20:35 * odyssey4me hands the mic to d34dh0r53 16:20:50 tys 16:20:54 hi d34dh0r53 :) 16:21:02 mornings :) 16:21:33 #link https://review.openstack.org/#/c/291810 16:22:16 The RPC-O project has identified the issue that odyssey4me just linked to as a blocker in our current release candidate and would like to petition an early SHA bump in OSA so that we can cleanly consume that fix 16:22:59 +1 16:23:03 Many thanks to logan- for identifying the bug and triaging it with cloudnull - I'm not sure of who else was involved. 16:23:39 logan-, cloudnull yes thank you both 16:23:56 Personally, I think due to https://bugs.launchpad.net/openstack-ansible/+bug/1559380 we should do an early tag of both Kilo and Liberty. 16:23:56 Launchpad bug 1559380 in openstack-ansible trunk "repo build broken due to pywbem 0.8.1" [High,Fix committed] - Assigned to Kevin Carter (kevin-carter) 16:24:02 A SHA bump will naturally follow. 16:24:13 odyssey4me: that would be nice 16:24:17 +1 16:24:18 +1 16:24:30 I'd agree for the pywbem issue, not familiar with the other 16:24:44 Oh, yeah... +1 to both 16:24:52 +1 for both 16:25:01 yeah +1 for pywbem alone haha 16:25:08 +1 for both 16:25:17 while I added a reno this morning to identify the known issue, we need to tag for people to consume it: https://review.openstack.org/297060 16:25:46 another issue identified after the last tag for liberty was https://review.openstack.org/297037 which affects minor upgrades 16:26:14 so yeah, I definitely think that we're due to tag 16:26:18 any objections? 16:26:21 +1 lot of good reasons 16:26:30 no objections, good justifications 16:27:00 ok, good - I'll request releases after this meeting and submit the SHA bump patches immediately after the request has submitted 16:27:27 * d34dh0r53 drops mic 16:27:31 #action odyssey4me to release next tags for Kilo/Liberty and submit reviews to SHA bump in both 16:27:58 #topic Newton Summit Planning 16:28:19 Nothing specific to say here - the etherpads are still up and available to make notes, comments, etc on. 16:28:46 Please do so especially in the brainstorm one, as I'd like to reference that for the community day and the housekeeping session. 16:29:07 Any questions or comments before we shift to discussing the Mitaka release status? 16:29:31 odyssey4me on that last one real quick, liberty will need a SHA bump ahead of tagging to pick up the neutron fix. it was only merged yesterday 16:30:00 for sooth 16:30:12 jmccrory we SHA bump after the tag 16:30:26 downstreams can consume the sha bump directly 16:30:35 I know we do (for liberty+) 16:30:41 the tag releases the pywbem fix, the sha bump can be consumed directly by RPC so it achieves the goal 16:30:47 ah ok gotcha 16:30:58 logan- do you rely on tags or are you happy to run from the head of liberty? 16:31:28 i run from head 16:31:32 I'd like us to run on the updated SHA's for at least a week before we tag again - there may be gremlins. :) 16:31:53 s/may be/are/ 16:31:57 ok awesome, so it covers the needs of both stakeholders who are specifically interested 16:32:17 It's just the known gremlins are quelled for now :) 16:32:27 You say that like gremlins are bad odyssey4me:) 16:32:37 tyvm 16:32:41 only after midnight 16:32:58 nothing a power hose can't solve :p 16:33:18 #topic Mitaka release 16:33:40 alright, so we've updated carried files/templates 16:33:55 the integrated SHA bump is failing - mattt's been looking into some issues 16:34:29 it seems like there's an issue with glance using swift as a store - we're not sure if it's a config change needed, or a regression in the glance_store lib yet 16:35:17 odyssey4me: new feature introduced is buggy from what i can tell, and there is no option to turn it off 16:35:32 so we're stuck between a rock and a hard place 16:35:40 for anyone that has a gap to try it out, please spend some time looking into failures when applying https://review.openstack.org/296799 16:35:57 also look for deprecated config notices, etc 16:36:37 mattt if it is a bug, then we should raise that as a critical one for Mitaka - a lot of people use swift as a store for glance 16:36:59 odyssey4me: sigmavirus24 has asked that i hold off until he has had a chance to properly evaluate 16:37:17 cool, thanks for the support sigmavirus24 - and thanks to mattt for digging into it 16:38:11 jmccrory automagically cloudnull d34dh0r53 stevelle mattt hughsaunders andymccr if you're looking into anything related to the Mitaka release, can you give us an update. I'd like to make sure we all know where we're at and where we need help. 16:38:27 Anyone else looking into anything, please also chime in. 16:38:33 not yet, still testing the repo_build changes 16:38:35 * d34dh0r53 has been focused primarily on liberty, sorry 16:38:46 still need to get this: https://review.openstack.org/#/c/293911/ 16:38:47 not looking into anything specific, wanted to get going on nova functional test today but got distracted tracking down the glance failure to a specific SHA 16:38:59 otherwise the state between liberty --> mitaka will change due to the swift_sync --> swift merge 16:39:21 most of my testing how to make things go faster. 16:39:32 andymccr yep, https://review.openstack.org/#/c/293911/ needs https://review.openstack.org/296799 to merge - so perhaps you can help figure things out? 16:39:36 geared at mitaka 16:40:37 andymccr an alternative may be to figure out which SHA bumps are required at minimum to make the integrated build work - then we can bump in two stages to get your patch in 16:41:03 so we need that patch to merge to fix gating, but its failing gating atm? 16:41:05 We haven't had any progress with https://review.openstack.org/#/c/290834 at this point. I might be able to revisit it this week but it seems like additional communication is needed 16:41:14 one way may be to pin glance_store temporarily - mattt? 16:41:31 andymccr yeah, nothing gets through the integrated gate right now 16:41:56 odyssey4me: don't think that will work ? https://github.com/openstack/glance/blob/master/requirements.txt#L51 16:44:09 mattt I thought that master may have moved on, but https://github.com/openstack/glance/blob/stable/mitaka/requirements.txt#L51 :( 16:44:22 yep so we're pretty much screwed at the moment 16:44:26 stevelle gerrit appears to be broken 16:44:35 what was that review regarding? 16:44:44 "Resolve oslo_config deprecations in nova.conf" 16:45:07 ah yes 16:45:33 ok, so considering the time we have available to us - when do we think we should target to release? 16:45:59 it seems like we need at least this week and next to sort out some issues and prep 16:46:13 easter weekend for us too 16:46:27 projected mitaka release date is 2016-04-07 16:47:03 so no new features should be going into osa master right now right :) 16:47:38 once we do an RC, nothing but major bug fixes 16:47:42 but the RC will mean we branch 16:48:30 good 16:48:38 feels like we're still going a 100 mph 16:48:52 never slow down 16:48:56 I propose that we target an RC for 5 April. Perhaps 7 April (same as upstream release date). 16:49:22 once we branch, that means that we can dive into Newton stuff and prep reviews for consideration and discussion at the summit. 16:49:25 Odyssey4me if we have low bugs hold off? 16:50:18 my only concern right now would be to merge anything that's a bug change and may introduce regressions 16:50:43 I'm just docs 16:51:00 I'd rather see us hold off on those until we've branched, and let those sort of changes bake for a while before we backport. 16:51:00 Thoughts? 16:51:24 Doc updates are always good. Keep 'em coming! 16:51:26 I'm good with that 16:51:37 Bake then backport seems reasonable 16:51:58 +1 16:54:03 agree 16:56:31 lol, got netsplit :/ 16:56:42 hah 16:56:59 You were just ditching us we know 16:57:33 ok, we're out of time - we'll discuss this again next week - I think we'll be in a better position to confidently set a date then 16:57:37 Thank you all for your time! 16:57:57 #endmeeting