Thursday, 2016-01-07

*** dims_ has quit IRC00:07
*** doug-fish has quit IRC00:26
*** LouisF has quit IRC00:49
openstackgerritMatt Riedemann proposed openstack/releases: Release python-novaclient 3.2.0  https://review.openstack.org/26449500:52
openstackgerritMatt Riedemann proposed openstack/releases: Release python-novaclient 3.2.0  https://review.openstack.org/26449500:53
mriedemjroll: ^00:53
jrollthanks :)00:54
*** dims has joined #openstack-release00:56
*** mriedem has quit IRC02:13
*** dims has quit IRC02:58
*** bdemers_ has joined #openstack-release05:29
*** bdemers has quit IRC05:29
*** bdemers has joined #openstack-release05:39
*** bdemers_ has quit IRC05:40
*** bdemers has quit IRC05:44
*** bdemers has joined #openstack-release05:45
*** bdemers has quit IRC05:48
*** bdemers has joined #openstack-release05:49
*** bdemers has quit IRC05:54
*** bdemers has joined #openstack-release05:55
*** bdemers has quit IRC06:26
*** bdemers has joined #openstack-release06:27
*** bdemers has quit IRC06:30
*** bdemers has joined #openstack-release06:30
*** bdemers has quit IRC06:35
*** bdemers has joined #openstack-release06:36
*** bdemers has quit IRC07:02
*** bdemers has joined #openstack-release07:03
*** ifat_afek has joined #openstack-release08:00
*** bdemers has quit IRC08:39
*** bdemers has joined #openstack-release08:39
*** dtantsur|afk is now known as dtantsur10:03
*** bdemers has quit IRC10:53
*** bdemers has joined #openstack-release10:55
*** dims has joined #openstack-release11:10
*** ifat_afek has quit IRC11:24
dimsttx : i fixed up https://review.openstack.org/#/c/220268/ (mimic), let's get it in please11:30
*** ifat_afek has joined #openstack-release11:37
*** bdemers has quit IRC11:38
*** bdemers has joined #openstack-release11:38
*** bdemers has quit IRC11:49
*** bdemers has joined #openstack-release11:49
*** devananda has quit IRC11:54
*** devananda has joined #openstack-release11:55
*** bdemers has quit IRC12:00
*** bdemers has joined #openstack-release12:00
*** gordc has joined #openstack-release12:31
*** bdemers_ has joined #openstack-release12:31
*** bdemers has quit IRC12:32
ttxdims: done12:33
dimsthanks ttx12:38
*** doug-fish has joined #openstack-release12:38
*** bdemers has joined #openstack-release12:47
*** bdemers_ has quit IRC12:48
ttxdims: while you're at it, you may want to have a look at https://review.openstack.org/26475412:54
dimsttx : whoa! how did you generate it? :)12:55
*** doug-fish has quit IRC13:05
*** bdemers has quit IRC13:09
*** ifat_afek has quit IRC13:10
ttxdims: PyPI data extraction using yolk, then a few manual checks where non-obvious13:22
ttxI'd advise that we require the data to be present from now on :)13:23
dimsttx : yep +1 on that13:23
*** doug-fish has joined #openstack-release13:24
*** ifat_afek has joined #openstack-release13:44
*** doug-fis_ has joined #openstack-release13:53
*** doug-fish has quit IRC13:55
*** mriedem has joined #openstack-release14:17
*** bdemers has joined #openstack-release14:35
*** bdemers_ has joined #openstack-release14:36
jrollttx: dims: you removed more than necessary here https://review.openstack.org/#/c/220268/1214:40
jrollall of the u-c additions should have been included14:40
dimsjroll : next rev of the bot will add those14:40
dimsjroll : see dhellmann 's comments - "@Jay - You should not regenerate the upper-constraints file just to add a new dependency. Simply add the line for your new thing. The bot will regenerate the file to pull in other changes as appropriate, under a separate patch, where it will be clear that the changes are not related to adding mimic."14:41
jrolldims: oh neat, good point14:42
dimsjroll : the README.rst says otherwise and we should fix it14:42
dimsJay followed the README.rst properly :)14:42
jrollright14:43
*** ifat_afek_ has joined #openstack-release14:43
*** ifat_afek has quit IRC14:44
*** tristanC has joined #openstack-release14:45
tristanCmriedem: Greeting sir, we are about to push security fixes to kilo and liberty. Just to make sure, the Nova stable/liberty point release number would be 12.0.1 right ?15:00
mriedemtristanC: we have a regression patch proposed to stable/liberty in nova that we have to get in before 12.0.1 can happen15:02
mriedemhttps://review.openstack.org/#/c/264793/15:03
mriedemi should have that done today15:03
dhellmannjroll , dims: I'll workon an update to the readme this week15:03
mriedemlifeless: dhellmann: sdague: dims: dansmith: btw, i just laid out the details on that regression and why https://review.openstack.org/#/c/226157/ doesn't prevent it like caps would15:03
mriedemdetails are in that spec15:03
dhellmannmriedem : it sounds like that would have been fixed if the unit test jobs used the constraints?15:04
mriedemdhellmann: nope15:04
tristanCmriedem: alright, so can 12.0.1 also include https://review.openstack.org/264815  (and the 2 depends-on patch) ?15:04
mriedemdhellmann: details are in my comment, i cover that15:04
dhellmannok, still reading15:04
mriedemtristanC: probably - i'm in a meeting for the next hour15:05
mriedemand dealing with this regression first15:05
dhellmannmriedem : ok, *proper* constraints?15:05
dhellmannmriedem: we all agree we have bad constraints settings in liberty right now and we need to figure out how to fix that. lifeless' plans assume we've fixed it.15:05
tristanCmriedem: ok thanks!15:05
mriedemdhellmann: i also commented on that15:06
mriedemdhellmann: just by pure luck oslo.serialization in upper-constraints at liberty GA was 1.9.015:06
mriedemand the new method was in 1.10.015:06
mriedemso yes a release-constraints file being used on that nova backport would have failed15:06
mriedemhowever, let's assume the method being used was in 1.8.015:06
mriedembut you were using oslo.serialization 1.4.0 b/c that's the min in g-r15:07
mriedemyou'd fail15:07
mriedemplus we've said that release-constraints will be updated by humans as needed15:07
dhellmannright, so we need a test job to prove that the minimum version range actually works right. I can't remember if that's in the spec or not, but it's definitely something we've talked about adding15:07
dhellmannthat's right, new releases of stable libs will require a manual update of release-constraints15:08
mriedembut if we have no lower bounds testing, things are still going to break15:08
mriedemif we would have simply capped oslo.serialization<1.5 at liberty GA in g-r, this wouldn't have happened15:09
mriedemanyway, meeting for the next hour, i should pay attention15:10
dhellmannmriedem : if we have lower bounds tests, upper bounds tests, and release-constraints tests, we'll be *better* but not perfect, and I think that's an improvement over what we have now15:10
*** mriedem is now known as mriedem_meeting15:10
*** doug-fis_ is now known as doug-fish15:11
mriedem_meetingdhellmann: i think that's a ton of complexity for something that (1) sane caps and (2) following semver when releasing clients and libs would resolve in most cases15:11
sdaguemriedem_meeting: I thought we were talking about release-constraints on unit tests though, in which case this wouldn't have been an issue, right?15:11
* dims nods to sdague's observation15:12
mriedem_meetingsdague: like i said above, in this specific case, assuming we had unit tests using -constraints and assuming we didn't screw up and update u-c on stable/liberty, then in this specific case yes it would have failed the backport proposed to nova15:12
mriedem_meetingHOWEVER15:12
mriedem_meetingif that new method in oslo.serialization being used here were in 1.9.0 rather than 1.10.0, we would have passed tests but been broken for anyone using oslo.serialization 1.4.015:13
mriedem_meetingwhich is the min bound in g-r for stable/liberty15:13
mriedem_meetingso it's a matter of missing 1 week of oslo lib releases15:13
*** gmurphy has joined #openstack-release15:13
mriedem_meetingeven if the new method were added right after 1.4.0 were released, it's a new API so it'd be a 1.5.0 release at least15:14
sdaguemriedem_meeting: right, so minimum testing is still a thing that's all fubared15:14
mriedem_meetingand stable/liberyt would be capped at 1.5 in my mind15:14
sdaguemriedem_meeting: what is the stable/liberty branch for oslo.serialization?15:14
mriedem_meetingwhat is the version?15:15
sdagueyeh15:15
mriedem_meetingidk? we post-version15:15
mriedem_meetinghttps://github.com/openstack/oslo.serialization/commit/03f34312d437a1419ebd1f90da6b9a96aa7bcb3615:15
mriedem_meeting2.2.0?15:16
mriedem_meetingthat doens't make sense, it must be 1.9.015:16
mriedem_meetingb/c dump_as_bytes isn't in here https://github.com/openstack/oslo.serialization/blob/stable/liberty/oslo_serialization/jsonutils.py15:16
mriedem_meetingdhellmann: aren't we supposed to revert these? https://review.openstack.org/#/c/246211/ and https://review.openstack.org/#/c/232918/15:17
sdagueso, honestly, lets ignore min bounds, because that never breaks *us*15:18
sdagueif we tested with a constraints file which was the libraries at release time for stable/liberty + stable/liberty oslo updates, on both tempest and unit tests, would we have broken ourselves?15:19
mriedem_meetingin this specific case i think so15:21
mriedem_meetingb/c liberty GA oslo.serialization was 1.9.015:21
mriedem_meetingand the new method was in 1.10.015:21
mriedem_meetingb/c we bumped u-c on stable (probably erroneously), it's using new enough oslo.serialization for dsvm jobs to pass15:21
dhellmannmriedem_meeting : yes, probably we need to revert those, but maybe not entirely? I haven't studied the details yet15:24
mriedem_meetingi have a feeling that reverting those would fail tempest badly15:24
mriedem_meetingbut idk15:25
dhellmannmriedem_meeting : let's see: https://review.openstack.org/#/c/264831/15:25
mriedem_meetingyou should probably revert in order?15:25
dhellmannyeah, here's the other: https://review.openstack.org/#/c/264832/115:26
*** dims_ has joined #openstack-release15:35
*** bdemers_ has quit IRC15:35
*** dims has quit IRC15:36
*** sigmavirus24_awa is now known as sigmavirus2415:42
*** mriedem_meeting is now known as mriedem15:42
*** bdemers has quit IRC15:45
dhellmannmriedem : after giving it more thought, I'm going to prepare one patch to restore us to where we ought to be -- all of the constraints reset for liberty except our own releases15:45
dansmithdhellmann: does that mean rolling back o.vo or not?15:55
*** bdemers has joined #openstack-release15:57
mriedemthis is probably something we can all agree on https://review.openstack.org/#/c/264495/16:15
mriedemthere was a regression for py27 in novaclient 3.0.016:16
mriedembreaking extensions that apparently ironic uses16:16
jrollmriedem: nah, rackspace uses them16:18
jrollsurprise~~16:18
dhellmanndansmith : I haven't gotten so far as to look at specific things. Did you want it rolled back, or is that going to break things?16:19
mriedemjroll: ah ok16:20
dansmithdhellmann: I think rolling back is going to require more change at this point, and our people have already started on updating our oslo liberty packages, since all of them have drifted away from those branches16:21
dhellmanndansmith : ok, noted.16:21
dansmithdhellmann: I mostly just want to know what you're thinking so we can stop doing that if you think that that's the plan16:21
dansmiththere's no real great path out of the current box, that I know of16:21
dansmithso less change starting now is probably the least impactful16:22
dhellmanndansmith : I was going to experiment with rolling everything back to the stable branch versions, but if that's an issue for any libs I'm ok with living with that if we somehow note that we're not doing backports to those libs any more or something16:22
dhellmannat least until we get better testing in place, I suppose16:22
dansmithI think we also need to decide what to do with the existing wrong stable branches16:23
dhellmannmriedem : do you have a constraints update for that novaclient release?16:23
dansmithi.e. do we do a semver-breaking sync so that they match what we have in constraints now? or delete them to avoid confusion? or sync every change?16:23
mriedemdhellmann: forgot about that, sec16:24
dhellmanndansmith : if we get the release-constraints stuff implemented, then we can live with the difference in the constraints, right?16:24
dansmithdhellmann: I don't understand what you mean. IMHO, the stable/foo branches *have* to match what is tested, and what is in the lower constraints file16:24
dansmithdhellmann: have to match, or have to not exist (for confusion sake)16:25
dhellmanndansmith : I'm thinking about the end state, where we test both release-constraints and upper-constraints. If we have both sets of tests in place, then the constraints could differ as long as both tests pass.16:25
dansmithdhellmann: could differ from what is actually in the stable branch?16:26
dhellmanndansmith : release-constraints would be required to match the stable branch, upper-constraints would not.16:26
dansmithwell, right, they can't *both* match :)16:26
mriedemdhellmann: https://review.openstack.org/#/c/264855/16:27
dhellmannmriedem : ok, I'll work on that release now16:27
mriedemdanka16:28
openstackgerritMerged openstack/releases: Release python-novaclient 3.2.0  https://review.openstack.org/26449516:29
dhellmannmriedem : done16:30
mriedemnice, thanks again16:31
dhellmanndansmith : is the minimum version for o.vo in liberty correct?16:33
dansmithdhellmann: it's not what o.vo was at when liberty released, no16:34
dansmithdhellmann: and what is in the upper-constraints is not what is on stable/liberty for o.vo16:34
dhellmanndansmith : does the minimum accurately reflect the version needed to work with liberty?16:34
dansmithand since there is no release-constraints yet, that one is wrong by default :)16:34
dansmithdhellmann: we have no minimum right?16:35
dhellmannglobal-requirements.txt:oslo.versionedobjects>=0.9.016:35
dhellmannupper-constraints.txt:oslo.versionedobjects===0.10.016:35
dhellmannoh, wait, that's probably my reverted version, hang on16:35
dansmithyeah, that's not current16:35
dhellmannupper-constraints.txt:oslo.versionedobjects===1.1.016:35
dansmithI guess I don't know what was in g-r, if that's a lower bound16:36
dhellmannok, so does version 0.9.0 work?16:36
dhellmannyeah, that's the lower bound from g-r16:36
dansmithdhellmann: I don't know, I'd have to go look, but 0.10 is what is in the stable/liberty branch (I think), so I expect 0.10 is what g-r should say16:36
dansmithactually,16:36
dhellmannwell, no16:37
dansmithwe had to patch stable/liberty nova to make it work with 1.1.0 I think16:37
dansmithso I don't know that 0.10 will even still work with stable/liberty to be honest16:37
dansmithwe probably need a test run to see16:37
dhellmannthe minimum value doesn't need to reflect the branch at all, as long as it works16:37
dhellmannyeah16:37
dansmithdhellmann: well, it depends on what lower bound we're testing with16:37
dhellmannI'm worried that we need to set the minimum to 1.1.016:37
dansmithdhellmann: if we're testing 0.10 because that's in the branch, but requirements say 0.9 then I think that's a problem, but...16:38
dansmithdhellmann: right, I think that might be the case now.. we're definitely in a weird spot at the moment16:38
dhellmannwe have to keep these separate types of tests distinct16:38
dhellmannwe need to establish the earliest version that works, the current version from the branch that works, and then the newest overall version that works16:38
dhellmannthose are 3 separate questions16:39
dansmithright, which is my primary complaint about the complexity here. I'd like to just offer one version that works :)16:39
dansmithI'm not sure how we get testing to show that the version in g-r works, unless we're really going to test that, the release-constraints version, and the upper-constraints version in each stack16:39
dhellmannthe goal of the constraints file is to do that. but we can't pin versions in the dependency list of projects because it makes it impossible to upgrade anything16:39
dhellmanndansmith : submitting a job to change the constraint to match the minimum would tell us if it works16:40
dansmithdhellmann: I mean how we get automatic testing of those three points in peacetime. I know we can submit a bunch of canary patches to get runs for this now, but longer term we'll still have three points we need to care about at all times, it sounds like16:41
dhellmanndansmith : right, we need to add more test jobs so we're testing all 3 cases all the time. but for now, I'm just trying to work out how to get the data back to a good state, and I don't want to wait for those jobs to do it16:42
dansmithdo we get multinode/partial nova results on changes to the requirements repo/16:43
dhellmannI don't know off the top of my head. What job is that?16:44
dansmiththat was rhetorical, I'm checking, just a sec :)16:44
dansmithI think we do16:46
dansmithdhellmann: are you going to submit those canaries16:46
dansmith?16:46
dhellmanndansmith : I'm working on the hard reset patch, do you want to do that one for o.vo?16:46
dhellmannI'm assuming that's the only one we have a major issue with, but maybe I'm wrong16:47
dansmithmy packaging guys say that all the oslo libs in upper-constraints don't match the corresponding stable branches16:47
dansmithso I'm not sure why o.vo would be unique here, but.. I don't follow those16:47
dhellmannyeah, we just updated them all, I expect the others to be easier to roll babck16:49
mriedemdansmith: dhellmann: requirements changes test with grenade but not partial n-cpu16:49
mriedemhttps://review.openstack.org/#/c/246564/16:49
mriedemunless that's the multinode job?16:49
dansmithmriedem: yeah, multinode job does it I think16:50
mriedemok, new name for the old partial ncpu job then16:50
dansmiththe example I looked at was failing, so I didn't check that it's actually doing the right thing, but I will on this one16:50
dansmithhttps://review.openstack.org/26486016:50
dhellmanndansmith, mriedem : we should start an etherpad to track this work, can one of you do that?16:54
mriedemi'm unclear on what we're doing, except trying to get stable/liberty u-c back to near liberty GA form16:55
dhellmannmriedem : that's right, but we're likely to have several experiments and so I thought keeping track of the patches involved and the attempts we made to get there would help16:56
dansmithso people that have already moved up to what u-c says will _now_ be running untested stuff, right?16:56
mriedemdhellmann: https://etherpad.openstack.org/p/stable-liberty-constraints-sanity16:56
dansmithmeaning if they pick up a new nova backport, that backport won't be getting tested against what they've rolled to right?16:56
openstackgerritDoug Hellmann proposed openstack/releases: add list-constraints command  https://review.openstack.org/26486616:57
dhellmanndansmith : I don't necessarily expect us to be able to roll everything back. And when we get the separate jobs set up, we'll have tests for both versions. Right now I'm trying to figure out what the plan to get to that state *is* I'm not proposing that we actually merge these changes without agreeing on that.16:59
dansmithsure, I'm just saying.. rolling back at this point might be somewhat uncool for CDers16:59
dhellmannright16:59
*** dims has joined #openstack-release16:59
dansmithfeels like it'd be better to freeze where we are, mea culpa, and stop the bleeding17:00
dhellmannso we'll make a list of patches to roll back, and maybe use those same values to create a release-constraints.txt file to start with17:00
dansmithbut, anyway, damned either way I guess17:00
dhellmannwell, yeah, I don't think we want to approve any more constraints changes17:00
mriedemheh, i'm pink, doug is light pink17:01
mriedemthanks etherpad17:01
mriedem-2 is in place on bot updates to u-c on stable https://review.openstack.org/#/c/257693/17:02
*** dims_ has quit IRC17:02
dhellmannhttps://review.openstack.org/264878 reset upper-constraints for stable/liberty17:14
dhellmannhttps://review.openstack.org/264879 update constraints for our managed libraries17:14
dhellmannmriedem, dansmith : more experiments ^^17:15
*** dtantsur is now known as dtantsur|afk17:15
mriedemdhellmann: was https://review.openstack.org/264878 based on a specific commit hash?17:17
dhellmannyeah, I should have documented that let me find it again17:18
dhellmannmriedem : commit message updated17:19
dhellmannmriedem, dansmith, lifeless, dims, sdague: here's the project-config change to disable constraints updates for liberty: https://review.openstack.org/26488317:26
*** sigmavirus24 is now known as sigmavirus24_awa17:27
*** bdemers has quit IRC17:36
*** bdemers has joined #openstack-release17:40
*** yarkot has joined #openstack-release17:53
*** bdemers has quit IRC17:58
*** bdemers has joined #openstack-release18:00
*** bdemers has quit IRC18:01
dimsdhellmann : ack18:04
*** bdemers has joined #openstack-release18:04
lifelessmriedem: minimums being wrong is also a known problem, but it affects master equally18:05
lifelessmriedem: caps won't address that18:05
lifelessmriedem: (unless I'm confused?)18:05
dansmithdepends on whether you mean caps are <=some_version or ==some_version18:11
dhellmannlifeless : can you put this instruction change on your review queue, please? https://review.openstack.org/26490718:20
dhellmannjroll : I think you might be interested, too https://review.openstack.org/264907 add simpler instructions for adding new dependencies18:20
*** ifat_afek_ has quit IRC18:23
lifelessdhellmann: I'm not sure i agree with the premise18:26
dhellmannlifeless : I want to understand why each line of that file is changed when a human makes the change.18:27
lifelessdhellmann: sure. The existing instructions give us only the new dependencies18:28
dhellmannok, that was not the results we were seeing on a recent patch, let me find it18:28
lifelessdhellmann: I'll be spotty for the next 90m - family morning time18:29
dhellmannlifeless : ok18:29
dhellmannlifeless : early versions of https://review.openstack.org/#/c/220268/ had all sorts of updates included18:29
lifelessso https://review.openstack.org/#/c/220268/2/upper-constraints.txt looks like it is entirely new things, not changes to existing things18:31
dhellmannhttps://review.openstack.org/#/c/220268/11/upper-constraints.txt18:31
lifeless3 looks... ok18:32
dhellmannI have no really way of evaluating that set of changes without reproducing it myself.18:32
*** mriedem has quit IRC18:32
lifelessso 11 does look problematic. We'd have to ask, but I suspect they didn't use the diff technique requested in README (right under your patched lines)18:32
dhellmannthat could be18:33
dhellmanneven if they had, though, as a reviewer I don't know what to do with that number of changes18:33
dhellmannis Pillow related to this new thing? should it be updated?18:33
lifelesswe could automake it further, though its not hard at the moment - run, patch, run, diff, patch18:33
dhellmannmaybe we can enhance the check job to help with that?18:33
dhellmannyeah18:33
dhellmannyeah, well, as a reviewer I don't want to have to reproduce the patch to check its validity, so I was offering some new instructions with a compromise18:34
lifelesssure18:34
lifelessso we can either make the check job do more18:34
lifelessor make it easier for submitters18:34
lifelessor both18:34
lifelessmy concern with your patch is that its harder for submitters18:34
dhellmannharder?18:35
lifelessbecause figuring out what dependencies something has is nontrivial18:35
lifelessthey are often not clearly documented, or the clear documentation is wrong18:35
dhellmannshould we leave those out, then? just add the new thing18:35
lifelessand we need the transitive deps18:35
lifelesslike18:35
lifelessseeing that we're bringing in twisted should probably be setting of alarm bells18:35
dhellmannmimic is a new testing tool, so I wasn't too worried about it18:36
lifelessso its going to mean that folk debugging testing failures need to read twisted code18:36
lifelessas a project we moved away from twisted18:36
dhellmannI don't think so, it's a functional test tool18:36
dhellmannit was described as mock for services18:36
lifelessdhellmann: its an httpd that pretends to be nova18:37
dhellmannthe client lib tests would not be running twisted code, iiuc18:37
lifelessand keystone etc18:37
dhellmannright18:37
lifelessif it behaves wrongly18:37
lifeless- if it has a bug18:37
*** mriedem has joined #openstack-release18:38
lifelesswon't that mean that whoever is trying to figure out whats up is now reading twisted code ?18:38
dhellmannI don't know18:39
dhellmannI see what you're saying. I have no idea how likely that is.18:39
lifelessPersonally I like twisted, for a bunch of reasons. But I'm worried that this is essentialy stealth-reintroducing it18:39
dhellmanndo you want to revert that and talk with jroll and the ironic team?18:40
lifelesslets talk first18:40
lifelessjroll: ^18:40
lifelessanyhow - thats my point about seeing the pins change18:41
lifelesswe also have this thing about licensing etc, and really it should be a transitive concern18:41
lifelessthat we're not doing anything about right now18:41
lifelessbut the same data could be useful18:41
dhellmannI still have no way of knowing if the proposer followed the instructions and got that right or not :-/18:41
lifelessyah18:41
lifelessyou wouldn't with your instructions either - there's a huge good faith assumption present in both cases18:42
jrolllifeless: dhellmann hi18:42
dhellmanntrue18:42
jrollwhat's up?18:42
jrolloh, twisted18:42
lifelessjroll: so, mimic is written in twisted, and its something folk will potentially have to debug when tests fail18:42
lifelessjroll: and while I like twisted and support bringing it or asyncio or something back, the current thing is 'no thanks'18:43
lifelessjroll: and - I don't recall any discussion on -dev about this18:43
lifelessjroll: perhaps I'm being overly sensitive to how folk may react18:43
jrolllifeless: honestly I was wondering how folks would react, too, I'm surprised this is the first time someone has brought it up18:44
lifelessdhellmann: so, it would take a while, but not terribly long, to do two runs and recreate the scenario in check18:44
lifelessjroll: I suspect only a few folk have seen18:44
dhellmannlifeless : 2 runs?18:44
jrollindeed18:44
lifelessdhellmann: git checkout HEAD^; generate-constraints -o baseline ; git checkout ORIG_HEAD; generate-constraints -o new; git checkout HEAD^:upper-constraints.txt; patch < (diff baseline new)18:46
lifelessdhellmann: or approximately that18:46
lifelessdhellmann: better I think to do the two runs and present the reviewer with the diff rather than auto-failing18:46
lifelessdhellmann: but thats still two runs18:46
lifelessjroll: so, I suggest a thread on -dev, rather than waiting18:47
dhellmannok, I see what you mean now. Yes, let's add that. Requirements changes run more complex and longer running jobs than that already, I imagine.18:47
jrolllifeless: so I get your point about twisted, I'm okay with it personally, and I'm happy to talk about it further if you like18:47
lifelessdhellmann: right, devstack :)18:48
jrolllifeless: I'm not sure what to ask on -dev, "we brought in twisted, any objection?"18:48
lifelessjroll: fundamentally, yes18:48
dhellmannjroll : yeah, I think lifeless' point is this is a bigger dependency than we've added in a while, and involves some tools we have previously said we didn't, as a community, want to use, so combining those two things means we should talk about it some before going ahead too fast18:49
lifelessafk18:49
jrollyeah18:51
jrolldhellmann: lifeless: is someone reverting then I guess?18:51
dhellmannjroll : we haven't, yet. I'm trying to decide if that's necessary.18:52
jrollok18:52
dhellmannjroll : why don't you start the discussion and we'll see; and hold off on approving changes in ironic related to this for a day or two?18:52
dhellmannI'd hate to churn a bunch of patches if it turns out to not be a big deal, so let's hit the slow-mo button instead of rewind :-)18:53
jrolldhellmann: okay18:53
dhellmanngreat, thank you18:53
*** sigmavirus24_awa is now known as sigmavirus2418:54
jrolldhellmann: is there a requirements tag or should I just [all] this?18:55
dhellmannjroll : use all, I think18:55
jrollk18:55
jrollthanks18:55
dhellmannjroll : thanks for your patience on this18:55
jrollnp18:56
openstackgerritDoug Hellmann proposed openstack/releases: add send-announcements-to field  https://review.openstack.org/26227919:01
jrolldhellmann: lifeless: fired it off19:09
dansmithmriedem: I didn't get a grenade run on this: https://review.openstack.org/#/c/264860/19:17
dansmithmriedem: nor nova unit tests, but maybe that's expected?19:17
mriedemdansmith: nova unit tests don't run on requirements repo chagnes19:18
mriedem*changes19:18
mriedemgrenade ran o nit19:18
mriedemjust not multinode19:18
dansmithsorry, not grenade multihost tempest19:18
dansmithregular grenade did, but that's not helpful19:18
mriedemhmm, do we run multinode on liberty changes?19:18
dansmithso I guess I have to run the nova unit test manually here?19:18
mriedemchecking19:18
mriedemprobably19:18
dansmithah,19:18
dansmithI was looking at a master change that's why19:19
dansmithbut I guess we didn't run partial on these?19:19
mriedemi guess not19:19
mriedemprobably should19:19
mriedemi see we run partial grenade on nova stable/liberty changes https://review.openstack.org/#/c/258695/19:19
mriedemthere is probably a branch filter on the requirements repo and that job in project-config19:19
dansmithnova ones yeah19:19
dansmithwell, since I think the guarantees this is going to provide are pretty weak, I guess I'll make sure nova unit tests pass19:20
dansmithand if so, then we can just assume it's close enough I suppose19:20
*** bdemers has quit IRC19:30
*** nikhil_k has joined #openstack-release19:31
*** yarkot has quit IRC19:31
*** yarkot has joined #openstack-release19:31
*** mriedem1 has joined #openstack-release19:33
*** dims_ has joined #openstack-release19:33
*** dims has quit IRC19:34
*** stevemar_znc has joined #openstack-release19:37
*** mriedem has quit IRC19:38
*** nikhil has quit IRC19:38
*** sileht has quit IRC19:38
*** stevemar has quit IRC19:38
*** mriedem1 is now known as mriedem19:38
*** stevemar_znc is now known as stevemar19:40
*** sileht has joined #openstack-release19:42
*** sigmavirus24 is now known as sigmavirus24_awa19:45
*** sigmavirus24_awa is now known as sigmavirus2419:48
*** dhellmann_ has joined #openstack-release19:55
*** bdemers has joined #openstack-release19:59
*** dims_ has quit IRC20:00
*** dhellmann has quit IRC20:11
*** dhellmann_ is now known as dhellmann20:11
*** dhellmann has quit IRC20:12
*** dims has joined #openstack-release20:12
*** dhellmann has joined #openstack-release20:14
*** dims has quit IRC20:19
*** dims has joined #openstack-release20:22
*** openstackgerrit has quit IRC20:23
*** dims has quit IRC20:23
*** openstackgerrit has joined #openstack-release20:24
dansmithdhellmann: o.vo 0.9 and 0.10 work with liberty nova because we removed that offending test in nova20:27
openstackgerritAdam Gandelman proposed openstack/releases: Release python-keystoneclient 1.3.4  https://review.openstack.org/26495220:28
dansmithdhellmann: I'm still not really willing to claim that it's okay to roll back to those for real until/unless I get partial or multinode-grenade jobs that prove it20:28
dansmithdhellmann: and we really need a partial from k->l and a multinode-grenade run from l->m(aster)20:28
dhellmanndansmith : we should start making a list of these test jobs that we need to add in the etherpad mriedem set up20:29
dhellmannhttps://etherpad.openstack.org/p/stable-liberty-constraints-sanity20:29
dhellmannI agree, we need to set up the tests before we roll back20:29
dhellmannlet's get the list together so we make sure we hit them all20:29
dansmithdone20:30
dhellmanndansmith : great, thanks20:31
mriedemdansmith: dhellmann: looks like the multinode job runs in master branch requirements changes https://review.openstack.org/#/c/264855/20:34
mriedemso we have liberty->mitaka multinode testing20:34
mriedemhere is our problem on stable20:37
mriedem  - name: ^gate-grenade-dsvm-multinode20:37
mriedem    branch: ^(?!stable/(kilo|liberty)).*$20:37
dhellmannthat looks like an easy fix20:38
mriedemwell20:38
mriedemhttps://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L1080-L108920:38
dhellmannwait, no, what's wrong with that? it's running for liberty, right?20:38
mriedemi'm not sure the multinode job works from kilo->liberty20:38
dhellmannah20:38
mriedemit's not running for liberty changes in the requirements repo20:38
mriedemthe old partial-ncpu job is marked as deprecated20:38
mriedembut that's the one we'd run on stable/liberty requirements changes (i think)20:39
*** dims has joined #openstack-release20:39
mriedemi think we can just add gate-grenade-dsvm-partial-ncpu to the requirements repo20:40
mriedemgiven the filter, it should only run on stable/liberty changes20:40
mriedemlet me try20:40
lifelessback20:46
sdagueright, the multihost grenade job doesn't work until M120:52
sdagueit's pretty new20:52
sdaguemriedem: though, it might be easy enough to backport those changes20:53
dansmithsdague: why does <M1 matter20:53
dansmith/20:53
dansmithdammit -> ?20:53
dansmithwe just care about liberty (with o.vo 0.10) -> master20:54
sdagueif you only care about liberty -> master then why https://review.openstack.org/26495720:54
sdaguethat's about kilo -> liberty20:54
dansmithsdague: for k->l I said we should have the partial job, not the multinode one20:56
sdaguedansmith: right20:56
sdaguehowever, it occurs to me that the multinode job might be pretty close to working20:56
dansmithfor k->l ?20:57
sdaguefor k -> l, given that a lot of the changes were in things which don't have branches20:57
dansmithhuh, okay20:57
sdagueit might be worth doing some runs and figuring out what would be needed to completely fix it20:57
dansmithwell, we really just need to see one or two good runs.. if the partial job works, seems like that's easier20:58
mriedemgood runs20:58
sdagueok, so if that's the case, are we going to leave this on all the time?20:59
*** nikhil_k is now known as nikhil21:29
*** dtantsur|afk has quit IRC21:50
*** dtantsur|afk has joined #openstack-release21:51
*** bdemers has quit IRC21:51
*** bdemers has joined #openstack-release22:20
*** mriedem has quit IRC22:54
*** dims_ has joined #openstack-release23:00
*** dims has quit IRC23:01
*** sigmavirus24 is now known as sigmavirus24_awa23:12
*** gordc has quit IRC23:28
*** dims_ has quit IRC23:39
*** bdemers has quit IRC23:41
*** doug-fish has quit IRC23:41
*** mriedem has joined #openstack-release23:44
*** dims_ has joined #openstack-release23:45
*** dims_ has quit IRC23:50

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