Wednesday, 2018-01-31

*** kumarmn has quit IRC00:00
*** hongbin has quit IRC00:18
*** zhurong has joined #openstack-release00:21
*** kmalloc has quit IRC00:29
*** ianychoi has joined #openstack-release00:31
*** pbandark has quit IRC00:33
*** zhurong has quit IRC00:37
*** zhurong has joined #openstack-release00:50
*** dave-mccowan has joined #openstack-release01:13
*** ricolin has joined #openstack-release01:19
*** kumarmn has joined #openstack-release01:19
*** ricolin has quit IRC01:21
*** kumarmn has quit IRC01:24
*** zhongjun has joined #openstack-release01:34
*** mriedem_afk is now known as mriedem01:37
*** harlowja has quit IRC02:15
*** mriedem has quit IRC02:17
*** d0ugal has quit IRC02:50
*** armax has joined #openstack-release03:05
*** ykarel|away has joined #openstack-release03:07
*** armax has quit IRC03:10
*** armax has joined #openstack-release03:16
*** ricolin has joined #openstack-release03:16
*** hongbin has joined #openstack-release03:19
*** melwitt has quit IRC03:23
*** ykarel|away has quit IRC03:23
*** ykarel|away has joined #openstack-release03:24
*** melwitt has joined #openstack-release03:25
*** ykarel|away has quit IRC03:34
*** sree has joined #openstack-release03:45
*** zhurong has quit IRC03:46
*** coolsvap has joined #openstack-release04:00
*** yamahata has joined #openstack-release04:06
*** iyamahat has joined #openstack-release04:08
*** ykarel|away has joined #openstack-release04:31
*** dave-mccowan has quit IRC04:32
*** armax has quit IRC04:37
*** rosmaita has quit IRC04:39
*** harlowja has joined #openstack-release04:51
*** iyamahat has quit IRC05:00
*** kumarmn has joined #openstack-release05:01
*** kumarmn has quit IRC05:06
*** hongbin has quit IRC05:26
*** zhurong has joined #openstack-release05:47
*** armax has joined #openstack-release05:52
*** armax has quit IRC06:40
*** iyamahat has joined #openstack-release06:43
*** sree_ has joined #openstack-release06:43
*** sree_ is now known as Guest3658506:44
*** sree has quit IRC06:45
*** zhurong has quit IRC06:49
*** harlowja has quit IRC07:01
*** zhenguo has joined #openstack-release07:05
*** kumarmn has joined #openstack-release07:17
*** iyamahat_ has joined #openstack-release07:17
*** iyamahat has quit IRC07:21
*** kumarmn has quit IRC07:22
*** zhurong has joined #openstack-release07:38
*** ykarel|away is now known as ykarel|lunch07:44
*** pcaruana has joined #openstack-release07:51
*** amoralej|off is now known as amoralej08:02
*** alexchadin has joined #openstack-release08:05
*** jtomasek has joined #openstack-release08:05
*** sree has joined #openstack-release08:08
*** Guest36585 has quit IRC08:11
*** ykarel|lunch is now known as ykarel08:44
*** zhurong_ has joined #openstack-release08:45
*** edmondsw has joined #openstack-release08:50
*** edmondsw has quit IRC08:54
*** iyamahat_ has quit IRC09:02
*** d0ugal has joined #openstack-release09:05
*** yamahata has quit IRC09:06
*** lvdombrkr has joined #openstack-release09:09
*** pbandark has joined #openstack-release09:13
*** shardy has joined #openstack-release09:13
*** zhenguo has quit IRC09:53
ttxwoohoo, list almost empty09:58
*** ykarel is now known as ykarel|away10:06
*** pkovar has joined #openstack-release10:10
*** ykarel|away has quit IRC10:11
*** zhurong has quit IRC10:19
openstackgerritMerged openstack/reno master: support scanning closed stable branches  https://review.openstack.org/53900910:25
*** armstrong has joined #openstack-release10:36
*** dtantsur|afk is now known as dtantsur10:36
openstackgerritMerged openstack/releases master: Fix PTL nomination week  https://review.openstack.org/53791810:37
openstackgerritJakub Libosvar proposed openstack/releases master: Release ovsdbapp version 0.9.1  https://review.openstack.org/53948910:42
*** zhurong_ has quit IRC10:48
*** lucas-afk is now known as lucasagomes10:48
*** alexchadin has quit IRC11:09
*** alexchadin has joined #openstack-release11:29
*** alexchadin has quit IRC11:32
*** kumarmn has joined #openstack-release11:33
*** alexchadin has joined #openstack-release11:39
*** kumarmn has quit IRC11:40
*** alexchadin has quit IRC11:44
*** lvdombrkr89 has joined #openstack-release11:45
*** lvdombrkr has quit IRC11:47
*** yamamoto_ has quit IRC11:48
*** alexchadin has joined #openstack-release11:49
*** alexchadin has quit IRC11:52
*** alexchadin has joined #openstack-release11:53
*** ykarel has joined #openstack-release11:55
*** alexchadin has quit IRC11:56
*** alexchadin has joined #openstack-release11:58
*** alexchadin has quit IRC12:05
*** alexchadin has joined #openstack-release12:06
*** dave-mccowan has joined #openstack-release12:08
*** alexchadin has quit IRC12:09
*** alexchadin has joined #openstack-release12:10
*** yamamoto has joined #openstack-release12:22
*** yamamoto has quit IRC12:22
*** yamamoto has joined #openstack-release12:23
ttxFor the masakari fail, I think they should set release = '' and version = '' in https://git.openstack.org/cgit/openstack/masakari/tree/releasenotes/source/conf.py#n6112:38
ttxHappy to propose a change for that if y'all confirm that's probably the case for the http://logs.openstack.org/6b/6b10645d92e7560efc088f7f09991d332af7096f/tag/publish-openstack-releasenotes/de4278d/job-output.txt.gz#_2018-01-31_09_56_17_577374 fail12:40
*** alexchadin has quit IRC12:41
ttxarh, duplication of effort it seems12:42
*** alexchadin has joined #openstack-release12:42
smcginnisttx: Oh, didn't see this until now.12:50
smcginnisttx: Yeah, they already had a patch out there from November to take care of this.12:50
*** rosmaita has joined #openstack-release12:51
*** rosmaita has quit IRC12:57
openstackgerritMerged openstack/releases master: allow list-deliverables to support multiple types  https://review.openstack.org/53762112:58
ttxsmcginnis: looks like q3 is now past us... What's next ? general library branching ?12:58
openstackgerritMerged openstack/releases master: constrain the valid values for the --type option to list-deliverables  https://review.openstack.org/53762213:02
openstackgerritMerged openstack/releases master: add client-library deliverable type  https://review.openstack.org/53762313:02
*** rosmaita has joined #openstack-release13:08
openstackgerritMerged openstack/releases master: change propose-library-branches to use yamlutils  https://review.openstack.org/53762413:10
openstackgerritMerged openstack/releases master: add --dry-run to propose-library-branches  https://review.openstack.org/53762513:10
openstackgerritMerged openstack/releases master: update list_library_unreleased_changes.sh to include client libraries  https://review.openstack.org/53763113:11
openstackgerritMerged openstack/releases master: show all release notes in list-changes  https://review.openstack.org/53834813:13
openstackgerritMerged openstack/releases master: extend missing-releases to look at pypi  https://review.openstack.org/53894313:14
openstackgerritMerged openstack/releases master: set up local variable 'version'  https://review.openstack.org/53894413:14
openstackgerritMerged openstack/releases master: extend missing-releases to look for specific package types on PyPI  https://review.openstack.org/53894513:14
*** edmondsw has joined #openstack-release13:22
*** pkovar has quit IRC13:27
*** coolsvap has quit IRC13:29
*** pkovar has joined #openstack-release13:30
smcginnisttx: I think so.13:32
smcginnisttx: Do we create a release for those libs that did not do anything in queens?13:33
*** pkovar has quit IRC13:36
smcginnishttp://paste.openstack.org/show/658145/13:37
smcginnisThe only ones not branched are the ones that did not do any queens releases.13:39
*** tobberydberg has quit IRC13:41
*** alexchadin has quit IRC13:41
ttxhmm13:42
smcginnisNeeded to --include-clients: http://paste.openstack.org/show/658146/13:42
ttxgood question. I think historically we'd create a new branch from same version13:42
smcginnisBranches needed for freezer, heat, manila, senlin, and trove clients.13:42
ttxbut I wonder if that would work with our current format13:43
smcginnisWas just going to ask that. :)13:43
smcginnisSince they are not part of queens, maybe just no stable/queens for those? That could cause problems down the line though.13:44
ttxIt's probably a question that dhellmann can answer from the top of his head so let's wait a bit13:44
smcginnisAlmost always a good plan. ;)13:44
ttxsmcginnis: yes I can see how that would trigger issues not having the branch13:44
ttxso I'd rather re-branch from current tag13:44
ttxI think we need to bump release number though to do that... otherwise we can't release anything for  that lib in stable/pike13:45
smcginnisYep13:45
smcginnisSeems kind of incorrect to bump that too much though.13:46
*** yamamoto has quit IRC14:04
*** kumarmn has joined #openstack-release14:05
*** pcaruana has quit IRC14:05
smcginnisIt would look really odd, but I suppose we could create the stable/queens branch for some of these in the pike deliverable file to just use the same commit.14:06
smcginnisNot sure if that would be a terrible idea or not.14:06
*** yamamoto has joined #openstack-release14:06
ttxIt certainly /sounds/ terrible14:06
*** mriedem has joined #openstack-release14:06
*** yamamoto has quit IRC14:11
*** amoralej is now known as amoralej|lunch14:18
*** pcaruana has joined #openstack-release14:21
smcginnisOn the other hand... it would make it clear that their stable/queens branch really is the same as stable/pike, and it would also make it clear that nothing was done when looking at the queens deliverable file. ¯\_(ツ)_/¯14:21
*** jtomasek_ has joined #openstack-release14:22
*** jtomasek has quit IRC14:24
dhellmannttx, smcginnis : o/14:24
dhellmanntechnically we can create stable/queens from the same point as stable/pike and it will just make another branch14:26
dhellmannremember we propose a .gitreview update on that branch immediately14:26
*** pkovar has joined #openstack-release14:26
dhellmannalthough ttx is right that if we don't have a new version number to start we could potentially shoot ourselves in the foot by releasing a patch on queens and then not being able to release it for pike14:27
dhellmannwere there really no heatclient releases this cycle?14:27
dhellmannthe others I can see, those are low-volume projects14:27
dhellmannanother option is to do nothing for them for queens, since there was no release, although it's going to be hard to remember what happened later14:28
dhellmannso we would at least want to document that decision with a comment in the deliverable files14:29
*** tellesnobrega has quit IRC14:30
*** tellesnobrega has joined #openstack-release14:30
*** lucasagomes is now known as lucas-hungry14:30
*** pkovar has quit IRC14:31
dhellmannsmcginnis , ttx: this list of what needs branches shows the versions they're at now http://paste.openstack.org/show/658160/14:32
*** pkovar has joined #openstack-release14:32
dhellmannso at least some of those did release14:32
openstackgerritDoug Hellmann proposed openstack/releases master: show type in list-deliverables output when more than one option  https://review.openstack.org/53955014:34
*** rosmaita has quit IRC14:34
dhellmannalternate view with the type column: http://paste.openstack.org/show/658162/14:34
*** rosmaita has joined #openstack-release14:35
ttxdhellmann: so that means that heatclient did a pike point release and no queens release ?14:36
*** rosmaita has quit IRC14:36
dhellmannttx: no, those version numbers come from the deliverable files in the queens directory14:37
dhellmannhttp://paste.openstack.org/show/658163/ shows the unreleased changes for the repos for those deliverables14:37
ttxoh, 16 hours ago14:37
dhellmannalthough that gets cut off, hrm14:37
dhellmannoh, without releases for some of those things we don't know what repos are involved14:38
*** yamamoto has joined #openstack-release14:38
dhellmannI really need to fix the data model to add a separate list of repos14:38
ttxhmm14:40
dhellmannlet's see if I can hack this some other way for now14:40
dhellmannhttp://paste.openstack.org/show/658165/ should have more info14:40
dhellmannlots of requirements updates14:41
*** wolverineav has joined #openstack-release14:41
dhellmannand CI config changes14:41
dhellmanntroveclient has tons of changes14:41
ttxSome of them really look like deadline misses14:41
dhellmannI'm sure the telemetry team just ignored the process for their clients, that's typical14:42
ttxlike openstack/pycadf14:42
ttxfeels weird to re-release them with a .Y bump based on previous tag14:43
dhellmannrequestsexceptions used the wrong prefix but there are no changes for it14:43
dhellmannyeah, at this point nothing has been tested with these unreleased changes14:43
*** rosmaita has joined #openstack-release14:43
dhellmannso we should probably not release them at all14:43
dhellmannand not create queens branches for them14:43
ttxand now basically it's a bit late to start14:43
dhellmannright14:44
dhellmannwe need a step in our process to check the libs at milestone 214:44
ttxno queens branches... I fear that will break us later14:44
dhellmannreally at every milestone14:44
ttxlike things getting tested with master due to lack of stable/foo14:44
dhellmannthat doesn't apply for libraries, though14:44
ttxsure, but I think that's an assumption we've made14:45
dhellmannlibraries are always installed from packages for tests, except when testing the library14:45
dhellmannno, that's how devstack-gate works14:45
dhellmannor devstack rather14:45
*** yamahata has joined #openstack-release14:45
ttxso the branch is only used for release purposes ?14:45
dhellmannthat's managed by the LIBS_FROM_GIT list14:45
dhellmannsay there's a patch to stable/queens for trove14:46
dhellmannthat patch will be tested with source for the services from stable/queens, or master if a needed service doesn't have stable/queens14:46
dhellmannthe constraints for the libraries will come from the requirements repo stable/queens branch14:46
dhellmannand that constraints list will be limited to things released before stable/queens was cut or off of the stable/queens branch14:47
dhellmannwe don't do automatic batch updates to stable requirements branches, we only update it when we release something of our own14:47
ttxAnother hypothetical: we end up having to release a point release for openstack/pycadf due to a security issue. We can do a stable/pike but not a stable/queens release14:47
*** samP has joined #openstack-release14:47
ttx(does that matter?)14:47
*** yamamoto has quit IRC14:47
dhellmannwe would have to release the queens version as a minor version bump14:47
dhellmannbut we branch from the same point as stable/pike, apply the patches, then release from stable/queens14:48
*** yamamoto has joined #openstack-release14:48
ttxso pycadf is 2.6.0 in stable/pike. We'd need to issue 2.6.1 and 2.7.0 ?14:48
dhellmannright14:48
ttxThat means we need to do the next release in master as Y+214:48
ttx2.8.014:48
*** yamamoto has quit IRC14:48
*** pcaruana has quit IRC14:48
*** iyamahat has joined #openstack-release14:48
* smcginnis catching up...14:49
*** yamamoto has joined #openstack-release14:49
ttxotherwise 2.7.0 might just be used already14:49
dhellmannthat's a good point14:49
*** samP has quit IRC14:49
dhellmannwe should document that14:49
dhellmanncomments in the deliverable file14:49
ttxI'm not sure how we can easily catch that one14:49
ttxthe rocky deliverable file ?14:50
dhellmannI could also update the validation rules to say that if there is no stable branch for the previous series the number has to increment by 214:50
dhellmannwe already check that they increment the minor number14:50
ttxor increment by 3 if multiple missing14:50
dhellmannyes, the rocky file14:50
dhellmannsure, we'd just count14:50
dhellmannand if we find no previous deliverable file we don't worry about it14:51
ttxok14:51
ttxLast point -- the library would be missing from the release page14:51
dhellmannyes, that's true14:51
ttxwhich makes it look like you don't have to package it anymore14:51
dhellmannI think that's an accurate reflection of the fact that there was no release.14:51
dhellmanndistros look at the dependencies of the things they do package, so I don't think that's a problem14:51
*** wolverineav has quit IRC14:52
dhellmannand if distros start raising a fuss, we can send them to the teams that aren't doing releases so those teams understand why they need to :-)14:52
ttxSo I guess my question becomes... if we have no strict adherence to stable/foo existing... why are we forcing libs to be cycle-bound?14:52
dhellmannBUT we need to consider, for the future, that some of our more stable libraries may not have releases in all cycles14:52
dhellmannthat will be especially true after we stop syncing dependencies14:53
*** wolverineav has joined #openstack-release14:53
dhellmannthat's a fair point14:53
ttxI feel like I'm missing something14:53
ttxbecause it looks a hell lot like independent releasing to me14:53
dhellmanncycle-with-intemediary is already very close to independent, but we said "independent" means "not part of openstack"14:53
ttxwe also said "at least one release"14:54
dhellmannwe did, yes14:54
dhellmannand the script that opens up the next release cycle in the releases repo will drop these deliverables from rocky automatically14:54
*** samP has joined #openstack-release14:54
dhellmannwe could take the step of suggesting to the TC that those things be dropped as official project deliverables14:54
ttxexcept things that are not dropped depend on them14:55
smcginnisGood point.14:55
dhellmannopenstack depends on lots of things that are not part of openstack14:55
dhellmannI'm going to have to step out for a bit; I should be back in about an hour.14:55
ttxbut for which we have set no expectation of one release per cycle14:55
dhellmannright. and these things aren't meeting expectations, so...14:56
dhellmannI'm not sure I think it's a good idea. I just think it's something to talk about as a way to make clear to those teams why we keep asking them to do releases.14:56
ttxI feel like we have set mixed expectations14:56
ttxlike what should you do if you had no change merged in the cycle14:57
*** wolverineav has quit IRC14:57
dhellmannthat's an important question for us to answer before we take any action14:57
ttxI'm not sure we have clearly said that you should do a null release bump in that case14:57
dhellmannbecause some of these changes are pretty trivial (including the g-r bumps)14:57
dhellmannand I'm not sure we should be doing null releases14:57
dhellmannI have to run; bbiab14:57
smcginnisI know we missed a python-cinderclient release one cycle several back, and that ended up being a pain going forward.14:58
ttxI think we should have caught those missing things earlier and encouraged owners to fix those14:58
smcginnisI like the idea of adding a checkpoint to milestone 2.14:58
*** armax has joined #openstack-release14:59
ttxbut between late library freezes and gate fires that did nt really happen14:59
smcginnisIt's been an... exceptional?... cycle I think.14:59
ttxand now we can either force a release from previous tag, or skip them. Feels like skipping them is more the first step in considering them abandoned though15:00
*** samP has quit IRC15:00
ttxwhile most of them are in a stable state and their owners are probably unaware that they should /still/ request a release for tehm15:01
smcginnisThis came up a little in Denver, but I think we need some more thought around what is an abandoned project and what is a "feature complete, stable" project.15:01
*** amoralej|lunch is now known as amoralej15:01
ttxWe also said in the past that if a project we can't really drop fails to hit the deadline, we'd force a release for it15:01
smcginnisThat does sound like the safer approach.15:02
ttxI remember saying that in release emails. "If you don't do it, we'll force a re-release from the latest tag"15:02
smcginnisYes, I think we have that published in multiple places too.15:03
smcginnisNot doing something with that troveclient seems like a bad idea. They have a lot out there.15:03
ttx"python-designateclient, python-searchlightclient and python-swiftclient15:03
ttxhaven't made a Pike release yet: if nothing is done by July 27, one15:03
ttxrelease will be forced (on master HEAD) so that we have something to cut15:03
ttxa stable branch from.15:03
ttx"15:03
ttxso that was the standing rule, and I'm not sure we have changed it (yet).15:04
*** samP has joined #openstack-release15:04
smcginnisI guess I'm leaning towards just forcing a release for those. Just wish I would have made a statement like that in one of the countdown emails a few weeks back.15:04
ttxSame for libraries at library release freeze15:04
smcginnisOne unfortunate thing now is we are past requirements freeze, so even releasing these will not actually make them available. But they can always ask for a FFE.15:05
ttxYes, that's really something that should have happened in the past 2 weeks15:06
ttxlet's wait for dhellmann to come back and make a call15:07
ttxFor this cycle we could just retag latest tag instead of HEAD to limit the risks and avoid the reqs freeze issue15:09
*** claudiub|3 has joined #openstack-release15:10
smcginnisSo options are 1) retag last tag and branch stable/queens from there, 2) force a release to get out changes and bump version to branch from.15:11
smcginnisProblem with 1 is some have changes that probably are actually needed for queens (in some cases).15:11
ttx3) not tag and skip stable/queens for those15:12
smcginnisOr that.15:12
ttxProblem with (2) is the reqs freeze15:12
ttxProblem with (3) is that it's pretty far from what we said we'd do in such situations in the past, and a bit of an unknown territory15:13
ttx+ the problems with (1)15:13
*** pcaruana has joined #openstack-release15:14
ttxI prefer 1, then 2 (with bunch of FFEs), then 315:14
smcginnisI'm on the fence between 1 and 2, then 3.15:15
ttxChoice between 1 and 2 should really include prometheanfire15:15
smcginnis++15:15
ttxI'm fine with it if he is + we do it ASAP15:16
ttxbbiab15:16
*** samP has quit IRC15:18
smcginnisML post from Masakari.15:23
*** samP has joined #openstack-release15:23
*** samP has quit IRC15:24
*** samP has joined #openstack-release15:28
*** lucas-hungry is now known as lucasagomes15:30
smcginnisResponded. Please let me know if I am off base there.15:31
*** tobberydberg has joined #openstack-release15:34
samPHi smcginnis15:34
smcginnissamP: Hey!15:35
samPsmcginnis: Thanks for advice15:35
smcginnissamP: Does that sound reasonable?15:35
*** samP has quit IRC15:36
*** yamamoto has quit IRC15:38
*** wolverineav has joined #openstack-release15:38
*** samP has joined #openstack-release15:40
*** samP_ has joined #openstack-release15:41
samPsmcginnis: sorry, disconnected15:43
smcginnissamP: No worries.15:44
samPMake perfect sense. I will proceed masakari release as independent for Queens. And will get on the normal cycle in Rocky.15:46
*** coolsvap has joined #openstack-release15:46
*** yamamoto has joined #openstack-release15:48
smcginnissamP: OK, great. I think that will be the best path forward at this point.15:48
smcginnissamP: If you need any help getting things going for Rocky, just let us know.15:49
samPsmcginnis: sure I will. Thanks again for the help..15:49
*** samP has quit IRC15:50
smcginnissamP_: No problem, thanks for checking with us!15:50
*** wolverineav has quit IRC15:53
*** yamamoto has quit IRC15:53
*** wolverineav has joined #openstack-release15:53
*** wolverineav has quit IRC15:57
*** lvdombrkr89 has quit IRC15:59
prometheanfirettx: one ffe is fine, as long as the reason for it is the same for all in the request16:01
prometheanfiremriedem: mordred: do we need openstacksdk-0.11.0 in queens? because it seems like it's not passing grenade still16:04
mriedemi don't know anything about openstacksdk 0.11.016:05
mriedemlink?16:06
prometheanfirehttps://review.openstack.org/53842516:06
prometheanfiremriedem: I thought you needed a new version for something16:07
prometheanfirehttps://review.openstack.org/53869516:07
prometheanfirewrong link...16:07
mriedemnova doesn't use the sdk16:07
*** samP_ has quit IRC16:07
mriedemprometheanfire: it's likely grenade is failing because https://review.openstack.org/#/c/538951/ isn't in stable/pike16:09
mriedemi don't know why this is failing http://logs.openstack.org/95/538695/3/check/neutron-grenade/53ae8b8/logs/grenade.sh.txt.gz#_2018-01-30_23_36_23_20316:10
mriedem"Could not find requested endpoint in Service Catalog."16:10
mriedemit should be looking up the network service16:10
mriedems/service/endpoint/16:11
prometheanfiremriedem: I assume you mean stable/queens? but ok, thanks16:11
mriedemno, stable/pike16:11
mriedemgrenade master is queens16:11
mriedemso that job is upgrading from pike to master16:11
prometheanfireoh, right16:12
*** samP has joined #openstack-release16:12
mriedemleft some comments in there16:14
prometheanfirethanks16:14
prometheanfiredansmith: mind looking at https://review.openstack.org/#/c/538951/16:18
openstackgerritTerry Wilson proposed openstack/releases master: Release ovsdbapp 0.4.2  https://review.openstack.org/53958716:18
prometheanfiremtreinish: ^ you too, please look at https://review.openstack.org/#/c/538951/ as it seems needed for https://review.openstack.org/53869516:19
* dhellmann catches up on scrollback16:21
*** samP has quit IRC16:21
prometheanfiredhellmann: you don't happen to have access to grenade do you? https://review.openstack.org/#/c/538951/16:23
dhellmannprometheanfire : no. the -qa folks, I think?16:24
*** wolverineav has joined #openstack-release16:24
dhellmannttx, smcginnis : I'm uncomfortable releasing from HEAD of master because who knows what sort of instability that's going to introduce16:25
*** ykarel is now known as ykarel|away16:25
*** samP has joined #openstack-release16:27
mordredprometheanfire: yes - we do - and yes, fixing coming16:29
dhellmannttx, smcginnis : I'm adding some thoughts to https://etherpad.openstack.org/p/queens-relmgt-tracking about each of the unreleased things16:29
prometheanfiremordred: ok16:29
* smcginnis is in cinder meeting at the moment, will catch up shortly.16:29
*** ykarel|away has quit IRC16:29
mordredprometheanfire: I'm aout to propose a 0.11.1 for sdk that should fix the grenade issue16:30
prometheanfiremordred: ah, nice16:32
mordred(and added the neutron-grenade job to sdk to verify that is the case)16:32
prometheanfiremordred: will that require a != in gr for 0.11.0?16:32
*** ricolin has quit IRC16:32
mordredI don't think so - the issue is an edge case with stable/pike of openstackclient + openstacksdk - we missed something in our compaat layer16:33
dhellmannmordred : what's up with os-client-config these days?16:33
prometheanfiremordred: ok, I just have to bring it up is all16:33
mordredand also learned that grenade does not upgrade python-openstackclient16:33
mordredprometheanfire: oh - totally - it's been a fun little adventure tracking this one down :)16:33
mordreddhellmann: that's a good question - I should submit a release request for it - there's a few things in master that should get released16:34
dhellmannmordred : yeah, I mean the extended deadline was yesterday :-/16:34
mordredwe didn't quite make it to making it in to a thin wrapper around sdk this cycle - will get that done early next cycle16:34
mordreddhellmann: oh - well, we can also skip it- there's nothing urgent16:34
dhellmannwell, it means we're sort of stuck without a good way to make a stable/queens branch16:34
dhellmannso we're trying to figure out what to do16:35
prometheanfiredhellmann: do we need FFEs for the clients?16:35
dhellmannif you *want* a release and prometheanfire is ok, I think we should go for it, but *lots* of things depend on that library now so...16:35
prometheanfirettx brought up16:35
prometheanfiredhellmann: ya, unless there's a reason we need it I say we skip16:35
dhellmannprometheanfire : I think, given all that has happened in the last week, we should just expect 1 more release from anything that hasn't had a release yet. I'm going through the list of those things now16:35
prometheanfiredhellmann: sgtm16:36
prometheanfiregating *seems* smoother...16:36
dhellmannbecause if we don't release them, then managing stable/queens becomes a real question -- where do we branch from and what ends up being backported16:36
prometheanfireyep16:36
dhellmannttx pointed out that last cycle we said we were going to force releases of anything that hadn't released16:36
dhellmannI'm not 100% comfortable with just doing that, though16:36
*** samP has quit IRC16:36
prometheanfireit seems like everything is basically shifted a release16:36
prometheanfires/release/week16:37
mordreddhellmann, prometheanfire: well - we could release it - it shares a gate with osc so I'm not concerned with it brekaing the gate16:37
dhellmannmordred : ok, good to know16:37
mordreddhellmann: lemme land the outstanding sync-with-global-reuqirements real quick16:38
dhellmannmordred : ack16:39
*** pcaruana has quit IRC16:39
*** samP has joined #openstack-release16:43
dhellmannkumarmn : are you going to do a trove client release for queens?16:45
mordreddhellmann: k. https://review.openstack.org/#/c/533991 is up, which is stacked on https://review.openstack.org/#/c/539594 which should fix the doc building job - as soon as they pass I'll get them landed and then get you a release request16:45
dhellmannmordred : ok. would you go ahead and file a preliminary patch in openstack/releases so we can track things that way?16:46
mordreddhellmann: yup!16:46
dhellmannthanks16:46
openstackgerritMonty Taylor proposed openstack/releases master: Release 1.29.0 of os-client-config for queens  https://review.openstack.org/53959516:48
openstackgerritMonty Taylor proposed openstack/releases master: Release 1.29.0 of os-client-config for queens  https://review.openstack.org/53959516:48
*** samP has quit IRC16:52
dhellmannlbragstad : what's going on with ldappool and pycadf? we have unreleased changes for both (see http://paste.openstack.org/show/658165/)16:56
*** samP has joined #openstack-release16:57
lbragstadi'd have to follow up with gordc on pycadf16:58
lbragstadbut ldappool is pretty minimum maintenance from the keystone team16:58
dhellmannlbragstad : can you do that today? we're either going to force releases, branch stable/queens from the previous release, or drop things from the official project list16:58
dhellmannI guess ldappool only has doc and requirements updates, so it should be safe to release that one16:59
dhellmanncould you propose that release, please?16:59
dhellmannrakhmerov : mistral-lib also has several unreleased changes. do you need a release? http://paste.openstack.org/show/658165/17:00
openstackgerritLance Bragstad proposed openstack/releases master: Release ldappool 2.2.0  https://review.openstack.org/53959917:00
dhellmannlbragstad : thanks17:00
dhellmannstrigazi : magnum client has quite a few unreleased bug fixes. do you need a release? http://paste.openstack.org/show/658165/17:01
*** harlowja has joined #openstack-release17:02
kumarmndhellman: I did tag queens-3 for trove-client: https://review.openstack.org/#/c/536893/17:02
openstackgerritMonty Taylor proposed openstack/releases master: Release 0.11.1 of python-openstacksdk for queens  https://review.openstack.org/53960217:02
*** yamamoto has joined #openstack-release17:03
dhellmannhmm17:03
kumarmnWere you asking about RC1?17:03
mordreddhellmann, prometheanfire: that ^^ should do it ... is that the right way to make a stable point release?17:03
dhellmannkumarmn : if I look at the list of patches in the openstack/python-troveclient repo on master since the 2.14.0 tag I see 9 changes. Do you need to release those for queens?17:04
dhellmannkumarmn : start at line 360 of http://paste.openstack.org/show/658165/17:04
dhellmannoh, that's old, hang on17:04
openstackgerritLance Bragstad proposed openstack/releases master: release pycadf 2.7.0 for stable/queens  https://review.openstack.org/53960417:05
dhellmannhmm, my script is producing weird results17:05
smcginnisHmm, yeah. Not sure why troveclient is showing up there.17:05
lbragstaddhellmann: ^ and pinged gordc17:06
dhellmannsmcginnis : yeah, and the list_unreleased_changes script starts at 2.13.0 instead of 2.14.017:06
dhellmannkumarmn : nevermind, the trove client changes on master don't need a release17:07
smcginnisFWIW, when I run the script to propose lib branches, it does pick up that troveclient had a release and needs a branch.17:07
dhellmannit does need a branch, but we can do that17:07
dhellmannstrigazi: python-magnumclient has a long list of unreleased changes. Do you want a queens release? http://paste.openstack.org/show/658165/17:08
dhellmannoops, duplicate ping, lost my place17:09
strigazidhellmann yes17:09
strigazistrigazi: I'm trying to add some more17:09
smcginnisdhellmann: Thinking we can get late releases done for all of these?17:09
dhellmannstrigazi : please propose it. the deadline was yesterday and we're trying to clean up stragglers17:09
smcginnisstrigazi: It's a little late to add more.17:09
dhellmannstrigazi : yeah, do not wait for more patches17:09
strigazidhellmann: smcginnis ack17:10
dhellmannsmcginnis : some of them are pretty trivial so I think so17:10
dhellmannthough I don't know what the check queue length looks like17:10
smcginnisGood, that would eleviate a lot of issues.17:10
dhellmannhave a look through my notes in https://etherpad.openstack.org/p/queens-relmgt-tracking and let me know what you think17:10
smcginnis118 in check, 65 in gate, right now.17:10
*** wolverineav has quit IRC17:11
dhellmannso many ptls are not in this channel this week :-/17:11
*** wolverineav has joined #openstack-release17:12
*** ekcs has joined #openstack-release17:13
smcginnisI should add that to the countdown notes that it is expected during milestone 3 until final release that PTLs or liaisons are present here.17:14
*** samP has quit IRC17:14
kumarmnas smcginnis said 2.14 was the version for queens-3, dhellmann. There should be only one changed that merged after that.17:14
dhellmannunfortunately I think a lot of them are in timezones that make synchronous communication impractical17:14
smcginnisTrue17:14
dhellmannkumarmn : http://paste.openstack.org/show/658202/ shows more than 1, but most of them are global requirements so it's not a big deal17:16
*** wolverineav has quit IRC17:16
*** armstrong has quit IRC17:16
*** yamamoto has quit IRC17:16
dhellmannsmcginnis : how about if we go ahead and do the "no harm done" releases as 1 set?17:17
dhellmannthe send email to the -dev list about the ones that need PTL input17:17
dhellmannmaybe we want to get ttx's input, too17:17
smcginnisdhellmann: So get all releases in one batch and try to get the ack from the affected PTLs.17:18
*** samP has joined #openstack-release17:18
dhellmannfor the ones that are just doc or build changes I was going to just do them17:18
dhellmannthe ones that are less obviously safe we would want to do one at a time17:18
dhellmannI mean none of these are new this cycle, so we could also just propose a patch to remove them from governance and be done with it17:19
dhellmannbut meh17:19
smcginnisYeah17:19
*** iyamahat has quit IRC17:19
*** pbandark has quit IRC17:20
dhellmannmaybe next cycle we should automatically propose releases for all libraries with unreleased changes at each milestone17:20
smcginnisI like that. If we do it at each milestone, then there is less risk we are going to force-release something that will cause problems for the final release.17:22
* ttx is back from meeting17:22
*** sree has quit IRC17:22
*** yamahata has quit IRC17:22
dhellmannttx, I made some notes in https://etherpad.openstack.org/p/queens-relmgt-tracking about what to do with the unreleased things17:23
*** samP has quit IRC17:23
*** sree has joined #openstack-release17:23
ttxlooking17:23
dhellmanna couple actually did have releases or were retired, so I removed them from the list17:23
openstackgerritgordon chung proposed openstack/releases master: aodhclient 1.0.0  https://review.openstack.org/53960817:25
ttxdhellmann: ok... I like that case-by-case approach, and agree that we could more aggressively release at milestones if nothing happened since previous milestone.... My only fear is that it will take time to ping people and process the list, potentially introducing issues late in the process17:25
ttxSo if we can't get people to answer I would just re-release from latest tag17:25
ttx(for the non-trivial ones)17:25
ttxideally we'd be done with pre-branch lib releases by tomorrow :)17:26
openstackgerritDoug Hellmann proposed openstack/releases master: fix get_last_tag function  https://review.openstack.org/53961017:26
dhellmannttx: why do we need to re-tag?17:27
dhellmannwhy not just branch?17:27
smcginnisOr we could not ping people. We could change our release policy so that unless they need a lib release sooner, it's just policy that we do a release every milestone.17:27
dhellmannsmcginnis : I do like that for next cycle17:27
ttxdhellmann: to avoid special casing the .Y skip?17:27
smcginnisMore work on our end as far as choosing release version, but then it would at least be consistent.17:27
dhellmannI'm less sure of doing it today, with no warning17:27
smcginnisdhellmann: ++17:27
dhellmannttx : ok, good point17:28
ttxdhellmann: It's also more... consistent17:28
ttxto me, more of a by-product of being cycle-with-milestones17:28
*** samP has joined #openstack-release17:28
dhellmannso do we want to go ahead with doing the least invasive thing in all cases without consulting them? or do we want to try to ping some more folks?17:29
ttxI'm ok to ping people, but with a short deadline17:29
dhellmannI think the people we haven't already reached are not going to be online for several hours17:29
ttxi.e. if we can't get answers by tomorrow US Eastern morning, proceed17:29
dhellmannok17:29
dhellmannso who wants to write the emails to the -dev list?17:30
ttxthat gives some time to people from China/Europe to pick the news17:30
dhellmannI'll take the task of preparing the patch with the preliminary plan for each of them17:30
ttxI'd gladly do it but the end of my day is just too near :)17:30
ttxas in now17:30
dhellmannwe can get them to vote on the patch if they want something different17:30
dhellmannack17:30
dhellmannsmcginnis : perhaps our fearless leader will write that email?17:31
smcginnisSo we're going to propose patches to do releases for things that are sitting out there. And we're going to try to get the PTLs to ack that those releases are OK?17:31
dhellmannit's going to vary17:31
smcginnisNot entirely sure I got the whole plan/proposal, but I can definitely send the email.17:31
dhellmannin cases where we anticipate little harm, we will release from HEAD of master17:31
dhellmannin cases where we can't tell, we are going to be conservative and re-tag the previous release and branch from there17:32
dhellmannthat will mean they have to backport bug fixes to get them into a later queens release, and they will not have their features because of the backport policy17:32
dhellmannsmcginnis : I have updated the tracking notes with the plan for each lib17:33
smcginnisAnd we'll hold thos re-tag branch patches until tomorrow to give non-US folks time to respond. And if they do have feature work they need to get out, they can propose a different patch overnight to get a new release out?17:33
*** gordc has joined #openstack-release17:33
smcginnis*those17:34
dhellmannsmcginnis , ttx: we need to think about what we're going to do when we stop syncing requirements and some of these libs don't have any changes in a cycle.17:34
dhellmannsmcginnis : good idea, they should propose an alternative patch for their repo17:34
dhellmannthen we can remove the changes from our megapatch17:34
openstackgerritSpyros Trigazis (strigazi) proposed openstack/releases master: Release python-magnumclient 2.8.0  https://review.openstack.org/53961317:34
*** sree has quit IRC17:34
dhellmannthanks strigazi17:35
smcginnisSo either way, by tomorrow we will cut and branch everything and that will be it.17:35
dhellmannright17:35
dhellmannwell, all the libs17:35
dhellmannservices don't branch until rc117:35
dhellmannsmcginnis : oh, except heat-translator17:35
dhellmannI think that's not a library17:36
gordcsmcginnis: re:pankoclient, we haven't done anything to it this cycle... it's probably going to be same commit-id as pike17:36
dhellmannI will propose changing its type in a separate patch17:36
smcginnisRight, non-services.17:36
dhellmanngordc : we can tag master, or we can re-tag that previous release with a new version to start the new branch17:36
gordcdhellmann: either works.17:37
dhellmanngordc : here's the list of changes: http://paste.openstack.org/show/65820617:37
dhellmannit looked like there were a couple of bug fixes17:37
dhellmannand I'm not sure what "* 6bd0c25 2017-06-09 17:30:51 +0000 add panko shell" is17:37
dhellmanngordc : how about aodh client?17:38
dhellmanngordc : and pycadf?17:38
gordchmm... i guess pike tagged on something other than i thought17:38
gordcdhellmann: just sent a patch for aodhclient17:38
dhellmannok17:38
smcginnisHmm, yeah. python-pankoclient shows only one that should have been after pike was cut.17:39
gordctalked with lbragstad, i'm ok with pycadf (not following it much personally)17:39
* ttx has got to run17:40
smcginniso/ ttx17:40
ttxkeep me posted if I need to do some cat herding tomorrow morning17:40
gordcbare with me, my internet sucks so i'm slowing moving to check what the last release was.17:40
dhellmannttx: ack, have a good evening17:40
ttxlike people on EU/CN TZs that you missed17:40
dhellmanngordc : np, I'm trying to share the same output I'm seeing17:40
smcginnis0.3.0 was APril 13. No pike release?17:40
dhellmanngordc : has everything: http://paste.openstack.org/show/658165/17:41
dhellmannsmcginnis : that was early in pike and we used it as the branch point17:41
smcginnisAH, ok.17:42
gordcoh... i'll just tag master then.17:43
dhellmannI'm going to get some food and then come back and prepare the megapatch with all of these updates in it17:43
*** iyamahat has joined #openstack-release17:43
smcginnisdhellmann: Think I better too while I have a meeting window.17:44
smcginnisgordc: If we could get release patches for those things, that would be better than us trying to figure out what to branch from where.17:44
smcginnisAaah, just got a 15 minute meeting reminder. Looks like it will be a quick one.17:45
openstackgerritgordon chung proposed openstack/releases master: pankoclient 0.4.0  https://review.openstack.org/53961817:45
gordcsmcginnis: release patches == https://review.openstack.org/#/q/owner:gord%2540live.ca+status:open+project:openstack/releases ?17:46
prometheanfiresmcginnis: is there a megaffe coming for reqs?17:48
*** gordc has quit IRC17:53
smcginnisprometheanfire: Yeah, I think there will be.17:54
*** sree has joined #openstack-release17:56
prometheanfirek, just wanted to be prepared :D17:58
*** samP has quit IRC18:00
*** sree has quit IRC18:01
*** ekcs has quit IRC18:02
*** yamahata has joined #openstack-release18:03
*** samP has joined #openstack-release18:05
*** hongbin has joined #openstack-release18:12
*** pkovar has quit IRC18:24
*** sree has joined #openstack-release18:28
*** sree has quit IRC18:36
*** dtantsur is now known as dtantsur|afk18:37
smcginnismordred: Should that python-openstacksdk release actually be a 0.12.0 release?18:38
*** iyamahat has quit IRC18:38
smcginnismordred: There are a couple things in there that don't look like bugfixes from my uneducated take on the commit messages.18:39
*** iyamahat has joined #openstack-release18:39
*** pbandark has joined #openstack-release18:39
*** iyamahat has quit IRC18:40
*** iyamahat has joined #openstack-release18:40
*** ekcs has joined #openstack-release18:40
*** iyamahat has quit IRC18:43
*** iyamahat has joined #openstack-release18:43
*** harlowja has quit IRC18:52
*** sree has joined #openstack-release18:52
*** shardy has quit IRC18:53
*** sree has quit IRC18:57
mordredsmcginnis: I could go either way - whichever you think is the right choice. there's a patch where the argument could be made for an 0.12 - but it feels to me it's a fix to a thing that was added in 0.1118:58
mordredsmcginnis: want me to update it?18:58
*** iyamahat has quit IRC19:02
*** iyamahat_ has joined #openstack-release19:02
smcginnismordred: OK, if it is indeed just a fix to something, then it is fine.19:03
smcginnismordred: I couldn't really tell from the quick read of the commit messages and wanted to make sure it was semver correct.19:03
smcginnismordred: Approved19:04
*** lucasagomes is now known as lucas-afk19:04
mordredsmcginnis: I tend to ramble19:06
*** freerunner has quit IRC19:06
*** SergeyLukjanov has quit IRC19:06
smcginnismordred: Really? I hadn't noticed.19:06
smcginnis:)19:06
*** freerunner has joined #openstack-release19:08
*** SergeyLukjanov has joined #openstack-release19:08
*** samP has quit IRC19:22
openstackgerritMerged openstack/releases master: aodhclient 1.0.0  https://review.openstack.org/53960819:24
*** amoralej is now known as amoralej|off19:25
*** coolsvap has quit IRC19:25
openstackgerritMerged openstack/releases master: pankoclient 0.4.0  https://review.openstack.org/53961819:26
*** samP has joined #openstack-release19:28
*** freerunner has quit IRC19:29
*** SergeyLukjanov has quit IRC19:29
openstackgerritgordon chung proposed openstack/releases master: aodh 4.0.3 (ocata)  https://review.openstack.org/53964319:29
openstackgerritgordon chung proposed openstack/releases master: ceilometer 8.1.3 (ocata)  https://review.openstack.org/53964419:31
openstackgerritMerged openstack/releases master: Release python-magnumclient 2.8.0  https://review.openstack.org/53961319:34
openstackgerritMerged openstack/releases master: Release ldappool 2.2.0  https://review.openstack.org/53959919:34
*** samP has quit IRC19:34
openstackgerritgordon chung proposed openstack/releases master: aodh 5.0.1 (pike)  https://review.openstack.org/53964519:35
*** harlowja has joined #openstack-release19:37
*** sree has joined #openstack-release19:39
openstackgerritgordon chung proposed openstack/releases master: ceilometermiddleware 1.2.0  https://review.openstack.org/53964619:39
openstackgerritMerged openstack/releases master: release pycadf 2.7.0 for stable/queens  https://review.openstack.org/53960419:39
openstackgerritMerged openstack/releases master: Release 0.11.1 of python-openstacksdk for queens  https://review.openstack.org/53960219:39
*** mriedem1 has joined #openstack-release19:41
*** samP has joined #openstack-release19:42
*** mriedem has quit IRC19:42
*** sree has quit IRC19:43
*** freerunner has joined #openstack-release19:43
*** SergeyLukjanov has joined #openstack-release19:44
dhellmannsmcginnis , ttx: in the course of working up the code changes to tag those libraries I realized a logical error in what we said we would do :-(19:47
dhellmannif we tag master again at the point where the previous branch was created, then the new release won't include any fixes that have already been backported to that stable branch19:48
dhellmannso functionality will regress19:48
dhellmannwhich may be an impetus to trigger a new release on master and to backport more fixes, I guess19:48
dhellmannbut it seems like it has the potential to trigger more work19:48
dhellmannand now that I've worked that out, I think that's why we said last cycle we would just tag the tip of master and branch from there19:49
smcginnisShoot.19:50
dhellmannso I'm going to just do that19:50
dhellmanndid you already send that email?19:50
smcginnisNot yet, I was just working in an etherpad to get your review before I sent anything.19:50
dhellmannok19:50
smcginnisdhellmann: I think there were only a few that you noted branched from the previous spot in the list in the tracking etherpad.19:52
smcginnisdhellmann: We could check on those and see if they even do have any backported fixes to stable/pike.19:53
smcginnisBased on the inactivity in queens, it might be a low number.19:53
dhellmannyeah, at least one that I was going to do that with did which is how I ended up rewriting my the logic I had added to new-release and that's when I realized the error19:53
dhellmannlet me see if I can make the tool tell me19:54
dhellmannsmcginnis : look for "WARNING" in http://paste.openstack.org/show/658222/19:57
smcginnisSo that's just the ones that have done stable releases, not necessarily ones that have backported changes that are still sitting out there, right?19:58
*** samP has quit IRC20:00
dhellmannlet me post the code I'm running20:01
dhellmannthat is the changes being made for the projects we said needed to have new releases and branches created20:02
openstackgerritDoug Hellmann proposed openstack/releases master: change deliverable type for heat-translator to "other"  https://review.openstack.org/53965520:03
openstackgerritDoug Hellmann proposed openstack/releases master: update new-release to support forced procedural tags  https://review.openstack.org/53965620:03
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:03
dhellmannsmcginnis : there's the code change to new-release and the set of deliverable file changes20:03
dhellmannthat last patch also includes a script queens.sh showing which commands I ran to generate the patch20:03
dhellmannvalidation failed for me locally so the deliverable file changes aren't going to work anyway20:04
prometheanfirethose releases (and others) are required reqs bumps?20:04
smcginnisdhellmann: While I look at that, want to take a look at what I've written here so far? https://etherpad.openstack.org/p/queens-post-freeze-email20:04
dhellmannprometheanfire : at this point we are not incrementing lower bounds, only constraints.20:04
dhellmannsmcginnis : the intro looks ok, but I think the conclusions are all going to need to change20:05
dhellmannI don't think we have a choice except to release from master20:06
dhellmannor to not release at all, i guess, but that's a very very distant 2nd choice20:06
smcginnisYeah, some of those I had written before you pointed out the above issues.20:06
smcginnisI think we'll have to iterate on that.20:06
dhellmannyeah, of course20:06
*** sree has joined #openstack-release20:07
*** samP has joined #openstack-release20:08
*** mriedem1 is now known as mriedem20:09
*** sree has quit IRC20:11
dhellmannsmcginnis , prometheanfire : i'm not sure it makes sense for us to release anything if we don't agree in advance that we'll at least try to take the constraint update20:14
dhellmannso can we say that we will do that?20:14
dhellmannI'm looking at the comments about senlin client, for example20:14
dhellmannhttps://etherpad.openstack.org/p/queens-post-freeze-email20:14
prometheanfireI'm fine with that, we just need a list before I can remove the -2-W20:14
dhellmannsure, that etherpad has the list (and it will go out as an email as soon as we agree on the actual plan)20:15
smcginnisWould there be an OpenStack Proposal Bot patches that would not be on that list?20:15
dhellmannand there will be 1 patch with all of the tag requests so you can verify version numbers20:15
dhellmannsmcginnis : good point, there should not be20:15
prometheanfirewhat I'd like to see us try is a group'd update so gate doesn't get stuffed20:15
*** samP has quit IRC20:15
dhellmannyeah, we did talk about squashing them after the check jobs pass20:15
prometheanfiresmcginnis: ya, I've been -2-W'ing them20:16
smcginnisprometheanfire: So squash any separate proposal bot patches into one that does it all in one shot?20:16
prometheanfiresquash is valid too, don't care much which way it goes, I can remove the commits that go all the way20:16
smcginnisI guess the only problem there is if we need to revert a specific library, but that could be addressed by an individual patch rolling back the one version.20:16
prometheanfireya, I'm not worried about that20:17
*** SergeyLukjanov has quit IRC20:17
*** freerunner has quit IRC20:17
smcginnisOK, I can take care of merging all of the proposals into one once these have gone through.20:17
prometheanfirek20:18
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:18
smcginnisdhellmann: Thoughts on mistral-lib (line 29)?20:18
dhellmannlet's look at that patch20:19
smcginnispython-tackerclient is another unknown. We can look at that one next.20:20
*** samP has joined #openstack-release20:20
dhellmannyeah, that does look like it breaks the mistral-lib API20:20
dhellmannwho is the mistral ptl20:21
prometheanfirebot should be able to answer these questions20:21
prometheanfire#ptl mistral20:21
prometheanfirethat should work :P20:21
smcginnisRenat Akhmerovrakhmerov20:22
smcginnisrakhmerov: You around?20:22
smcginnisprometheanfire: We must not have the bot for that here. That would be handy though.20:23
*** freerunner has joined #openstack-release20:23
*** SergeyLukjanov has joined #openstack-release20:23
prometheanfireya, I just want it because we have something like that for gentoo20:23
dhellmannwe could teach the openstack bot to do that20:24
prometheanfire#cores PROJECT would be nice too20:24
prometheanfiremore important things for now though20:24
dhellmannmaybe we should just leave mistral-lib out of this patch for now and raise that as a separate thread on the mailing list20:25
smcginnisdhellmann: What would plan B be then?20:26
dhellmanndo the ones we can and deal with mistral-lib tomorrow20:26
dhellmannI guess we're looking for feedback for all of them20:27
dhellmannbut we want mistral-lib separated out so we can skip it, right?20:27
dhellmannbecause at this point we're not going to release something that isn't compatible20:27
dhellmannthey're clearly not using it20:27
smcginnisThey do have a check for the old value, so maybe not too dangerous?20:27
dhellmannwhere?20:27
smcginnishttps://github.com/openstack/mistral-lib/commit/40e593bd2016b623ce509a3db24965997422eed220:28
smcginnisLine 92.20:28
dhellmannoh, I didn't notice they moved task_id to the end of the args list20:28
dhellmannthat looks like it would do the wrong thing if the caller passed both values, but that seems unlikely20:29
dhellmannin any case, they've tried to make it compatible so I think it's safe to go ahead20:29
smcginnis++20:29
dhellmannsmcginnis : what was the other one you wanted to talk about?20:30
smcginnispython-tackerclient20:30
*** samP has quit IRC20:30
*** sree has joined #openstack-release20:31
dhellmannthat's a lot of changes20:31
dhellmannmostly bug fixes, but some requirements updates20:31
smcginnisI was concerned with the number of changes, but looking through it now, nothing stands out as a particularly troubling commit. It's just the volume of change.20:32
smcginnisProbably fine then.20:32
dhellmannyeah20:32
dhellmann20 that are not g-r updates20:32
smcginnisOK, I think we should propose it and let folks comment on the ML or the patch.20:33
smcginnisRereading what we have now in the draft.20:33
smcginnisMoved that line down to make sure it's more visible.20:34
dhellmann++20:34
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:35
openstackgerritDoug Hellmann proposed openstack/releases master: update new-release to support forced procedural tags  https://review.openstack.org/53965620:35
openstackgerritDoug Hellmann proposed openstack/releases master: remove temporary script queens.sh  https://review.openstack.org/53967320:35
dhellmannrebased and reordered to put the code change after the releases since we might not want it20:36
*** sree has quit IRC20:36
smcginnisDid we want queens.sh included in there?20:38
dhellmannI removed it in a follow up20:38
dhellmannI guess I could just remove it since it's the same command over and over now20:38
dhellmannbefore it actually varied based on what we said we would do20:39
*** samP has joined #openstack-release20:39
smcginnisOh, I see what you're saying. Eh, either way.20:39
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:39
openstackgerritDoug Hellmann proposed openstack/releases master: update new-release to support forced procedural tags  https://review.openstack.org/53965620:39
dhellmannsquashed in the removal patch20:39
smcginnisDid we want to include switching heat-translator to "other" in this set?20:39
dhellmannoh, we should link to that separately20:39
*** SergeyLukjanov has quit IRC20:39
*** freerunner has quit IRC20:39
smcginnisWhat about requestsexception20:40
smcginnisAnd python-freezerclient.20:40
smcginnisOK, those are the only two I see in the email that are not in that patch.20:40
dhellmannah, right, hang on20:41
*** freerunner has joined #openstack-release20:41
*** SergeyLukjanov has joined #openstack-release20:42
openstackgerritDoug Hellmann proposed openstack/releases master: update new-release to support forced procedural tags  https://review.openstack.org/53965620:42
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:42
dhellmannsmcginnis : that means reordering again to take the schema change with the code changes before we take the deliverable file updates20:43
dhellmannbut that's done now20:43
dhellmannlooks like that is going to have a validation error :-(20:44
dhellmannoh, nevermind, maybe that's not what I'm seeing20:44
dhellmannstandby20:44
dhellmannone error: deliverables/queens/python-freezerclient.yaml: openstack/python-freezerclient 1974aeadae1da9cff5420c7dba032045a75a9696 receiving 1.7.0 is not a descendant of 1.6.020:44
smcginnisThat was the one that was showing up as unreleased even though it was, right? Looks like we need to figure out what happened there.20:45
dhellmannfreezer client had a release20:45
dhellmannwe should branch from that20:45
dhellmannI don't know why something though there was no release20:45
*** samP has quit IRC20:45
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:46
dhellmanndropped freezer client20:47
smcginnisDid they do their own release? I'm still confused.20:47
dhellmannthere are releases listed in the queens deliverable file20:47
dhellmannI think I queried for updates to projects without branches rather than projects without releases20:48
dhellmannso it included some extras20:48
smcginnisAh, OK. I'm seeing it now.20:49
dhellmann$ .tox/venv/bin/list-deliverables --unreleased --type library --type client-library20:49
dhellmannldappool20:49
dhellmannos-client-config20:49
dhellmannpycadf20:49
dhellmannpython-aodhclient20:49
dhellmannpython-ceilometerclient20:49
dhellmannpython-magnumclient20:49
dhellmannpython-pankoclient20:49
dhellmannI probably need to repull, I know we have some of those20:50
smcginnisOK, so I can approve the first two, then we hold on the final queens library releases patch until tomorrow when they have a chance to respond to it, right?20:50
smcginnisYeah, a couple of those have gone through now.20:50
smcginnisActually, I think all of those.20:50
dhellmannos-client-config20:50
dhellmannpython-ceilometerclient20:50
dhellmannocc isn't ready but is proposed and ceilomterclient is retired20:51
openstackgerritDoug Hellmann proposed openstack/releases master: change deliverable type for heat-translator to "other"  https://review.openstack.org/53965520:51
openstackgerritDoug Hellmann proposed openstack/releases master: update new-release to support forced procedural tags  https://review.openstack.org/53965620:51
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:51
openstackgerritDoug Hellmann proposed openstack/releases master: retire python-ceilometerclient  https://review.openstack.org/53967720:51
smcginnismordred: Did you see my note on the occ release patch?20:51
*** samP has joined #openstack-release20:51
openstackgerritDoug Hellmann proposed openstack/releases master: retire python-ceilometerclient  https://review.openstack.org/53967720:53
openstackgerritDoug Hellmann proposed openstack/releases master: update new-release to support forced procedural tags  https://review.openstack.org/53965620:53
openstackgerritDoug Hellmann proposed openstack/releases master: final queens library releases  https://review.openstack.org/53965720:53
openstackgerritDoug Hellmann proposed openstack/releases master: final queens branches for libraries  https://review.openstack.org/53968120:53
smcginnisReorder?20:53
dhellmannsmcginnis : I think you can approve the first 3 patches in the series now and wait for the others20:53
smcginnisk20:54
dhellmannyeah, I added the ceilometerclient retirement earlier so you can approve it, then I added a branch patch at the end20:54
smcginnisOK good20:54
dhellmannthat should give us everything20:54
mordredsmcginnis: oh- I did not20:55
smcginnismordred: Just wondering if we really need to wait for a test-requirements update to do that release.20:55
smcginnisdhellmann: OK, I did a quick read through of the draft email. Look good enough to you for me to send that out?20:57
mordredsmcginnis: oh - now that you mention, no - we don't. otoh - those two are in the gate and running their last test job so it shouldn't be lon either way20:58
mordredsmcginnis: want me to respin anyway?20:58
dhellmannsmcginnis : let me scan it one more time20:58
smcginnismordred: Nope, that's fine then. Last I looked it was still pending. We might as well wait now.20:58
mordredsmcginnis: sorry I missed the note earlier20:58
smcginnismordred: No worries, was just curious mostly.20:59
dhellmannsmcginnis : the email looks good21:01
smcginnisOK, sending out momentarily.21:01
*** sree has joined #openstack-release21:02
*** sree has quit IRC21:06
*** samP has quit IRC21:13
*** samP has joined #openstack-release21:18
dhellmannsmcginnis , fungi, pabelanger: the rsync errors from this publish job are odd. http://logs.openstack.org/ea/ea013a8151dfba0ef82d3a4e7cca84f538834aae/release-post/publish-static/8a1b6a3/job-output.txt.gz21:19
pabelangerdhellmann: I want to say fungi might have just been looking into it? Something about multiple jobs are trying to maybe write to that folder at same time21:20
pabelangerbut haven't really looked myself21:20
dhellmannah, yeah, that would happen if we release several things at once21:20
pabelangerwe likely need to add semaphore for those jobs21:21
dhellmannhow does that work?21:21
dhellmannwell, not just a semaphore21:21
pabelangerdhellmann: seeing in zuul, where we only allow 1 jobs to run at a time21:21
pabelangersetting*21:21
dhellmannwe need the post jobs to run in order (or at least ensure they always pull HEAD)21:21
pabelangerah21:21
dhellmannbecause we're publishing updates to the website there21:22
pabelangerright21:22
dhellmannthough I guess at a semaphore is better than nothing21:22
dhellmannwe can always land a trivial patch to fix things if they go in the wrong order21:22
smcginnisdhellmann, fungi, pabelanger: I have not had a chance to take a look at the results to see if they ended up OK.21:22
fungii think clarkb and smcginnis were discussing it in #-infra a few minutes ago21:22
dhellmannsmcginnis : we'll have other patches going in, so that should fix itself eventually21:23
smcginnisYeah21:24
dhellmannpabelanger : can you point me to an example of a semaphore? I can set one  up21:24
mordredsmcginnis: ok. the os-client-config patches landed21:26
pabelangerdhellmann: http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/jobs.yaml#n1171 was for propose-update-requirements21:26
dhellmannpabelanger : ok. This job http://git.openstack.org/cgit/openstack/releases/tree/.zuul.yaml#n3121:27
pabelangerdhellmann: thanks, I was looking for it21:27
dhellmanncan I just add the semaphore there where we add it to the release-post queue or do I have to do something special?21:27
pabelangerdhellmann: Hmm, I _think_ should could add the semaphore into the pipeline, then updating publish-static job21:28
pabelangerlet me find that21:28
pabelangerhttp://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/jobs.yaml#n58221:30
dhellmannpabelanger : it's almost as though we want a separate semaphore for the static publish job for each destination21:30
pabelangerin fact, that job is not like safe to be run at same time by 2 or more jobs21:31
dhellmannthat job is reused several places, right?21:31
pabelangerdhellmann: unsure21:31
dhellmannhttp://codesearch.openstack.org/?q=publish-static&i=nope&files=&repos=21:31
pabelangeryah, it is21:31
*** sree has joined #openstack-release21:31
dhellmannI could subclass it I guess?21:32
dhellmannoh, no, it's marked final21:32
pabelangerwe should maybe confirm with AJaeger in the morning, I think he wrote it21:33
pabelangerbut you should be able to add the semaphore to pipeline now to test21:33
pabelangerthen see if we wan to move directly into job21:33
dhellmannI wonder if we could add a semaphore name based on {{ zuul.project.short_name }}21:33
dhellmannthough then we'd have to add those semaphores somewhere, too21:33
dhellmannI don't know what you mean "add the semaphore to pipeline"21:33
pabelanger1 sec21:34
dhellmannadd it where publish-static is included in the list of jobs for the releases repo?21:34
openstackgerritDoug Hellmann proposed openstack/releases master: add semaphore for publishing to the releases website  https://review.openstack.org/53969221:35
dhellmannpabelanger : like that? ^^21:35
*** sree has quit IRC21:35
mordredsmcginnis: also - the release process is working well - I've got 2 more bug reports for issues in the stable/queens release of sdk ... it's almost like people are trying things and reporting when they fail!21:36
pabelangerdhellmann: yah, was going to say: http://paste.openstack.org/show/658242/21:36
pabelangerdhellmann: but that also should work21:36
smcginnismordred: Haha, excellent!21:36
openstackgerritgordon chung proposed openstack/releases master: aodh 4.0.3 (ocata)  https://review.openstack.org/53964321:36
openstackgerritDoug Hellmann proposed openstack/releases master: add semaphore for publishing to the releases website  https://review.openstack.org/53969221:37
mordredsmcginnis: requestsexceptions - we could shift that to being independent release ...21:39
mordredsmcginnis: it's ... it's a TINY library that hasn't changed much21:39
smcginnismordred: I was wondering if that would make more sense. It does seem more of an "independent" kind of thing.21:39
mordredit has 14 commits in its lifetime :)21:39
smcginnismordred: Any reason to have stable branches on it too?21:40
mordrednope.21:40
mordredit's basically a lib to share a chunk of code that's needed to shut requests up with warnings it emits that are unactionable21:41
dhellmannthere are 2 reasons we have stable branches21:41
dhellmannone is for us, and the other is for downstream consumption21:41
dhellmannso even if we don't consider requestsexceptions to need stable/queens, at some point someone may want to patch the queens version after we've made some other change to master that should not go into queens21:42
dhellmannwe can say, on a case-by-case basis, that that may not be true for library X21:42
dhellmannbut if we have a separate policy for every library then no one is going to be able to keep the processes straight21:42
dhellmannso even if we shift it to an independent library we need to figure out how to be able to have a stable/queens branch when it's needed21:42
*** samP has quit IRC21:43
mordrednod. and agree - and honestly if it's easier to just make a stable/queens - it certainly won't bother me21:43
mordredmostly just saying that it's oneof those libs that almost never changes, so if it makes life easier on y'all to treat it differently, cool21:44
smcginnisYeah, no changes since last July.21:44
mordredhonestly, we could also un-openstack it and let it just be a library that happens to be in openstack's gerrit rather than something we consider 'part' of openstack ... all the same to me either way21:44
dhellmannyeah, we're going to have more and more of those so my point is we need to think about that not as a one-off case but as a new class of thing21:44
smcginnisAnd doesn't really look like it will need to change unless requests introduces something else.21:45
mordreddhellmann: ++21:45
dhellmannand making it "not openstack" works for requestsexceptions and stevedore but less well for oslo.context21:45
smcginnisWe'd have to rename it to lo.context then. :)21:45
mordredhahahahahahaha21:45
mordredsmcginnis wins for best in-joke of the week21:46
smcginnisin-joke, or is that bordering on dad-joke?21:46
dhellmannsome of both21:46
smcginnis;)21:46
*** samP has joined #openstack-release21:49
*** pbandark has quit IRC21:58
*** iyamahat_ has quit IRC22:04
*** yamahata has quit IRC22:04
openstackgerritDoug Hellmann proposed openstack/releases master: reno 2.7.0  https://review.openstack.org/53970122:05
*** samP has quit IRC22:06
*** samP has joined #openstack-release22:10
*** samP has quit IRC22:13
*** sree has joined #openstack-release22:15
*** samP has joined #openstack-release22:18
*** sree has quit IRC22:20
openstackgerritMerged openstack/releases master: change deliverable type for heat-translator to "other"  https://review.openstack.org/53965522:27
openstackgerritMerged openstack/releases master: retire python-ceilometerclient  https://review.openstack.org/53967722:27
openstackgerritMerged openstack/releases master: update new-release to support forced procedural tags  https://review.openstack.org/53965622:32
*** edmondsw has quit IRC22:32
*** edmondsw has joined #openstack-release22:33
openstackgerritMerged openstack/releases master: ceilometermiddleware 1.2.0  https://review.openstack.org/53964622:33
*** edmondsw has quit IRC22:37
*** samP has quit IRC22:41
*** samP has joined #openstack-release22:44
*** sree has joined #openstack-release22:46
*** sree has quit IRC22:50
*** sree has joined #openstack-release22:53
*** sree has quit IRC22:58
*** samP has quit IRC23:01
*** rosmaita has quit IRC23:04
*** samP has joined #openstack-release23:07
*** rosmaita has joined #openstack-release23:08
openstackgerritMerged openstack/releases master: reno 2.7.0  https://review.openstack.org/53970123:18
*** sree has joined #openstack-release23:19
*** d0ugal has quit IRC23:20
*** kumarmn has quit IRC23:20
*** iyamahat has joined #openstack-release23:20
*** sree has quit IRC23:23
*** yamahata has joined #openstack-release23:35
*** kumarmn has joined #openstack-release23:43
*** sree has joined #openstack-release23:44
*** kumarmn has quit IRC23:47
*** armax has quit IRC23:49
*** sree has quit IRC23:49

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!