| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-25 | |||
| 14:15:40 | mriedem | sure | |
| 14:15:54 | mriedem | stephenfin: trade you https://review.openstack.org/#/c/140733/ | |
| 14:16:22 | stephenfin | Sounds good | |
| 14:16:46 | efried | holy crap, that one's >3 years old | |
| 14:19:26 | mriedem | b/c the cinder driver for it was removed awhile back | |
| 14:20:06 | Roamer` | stephenfin, efried, we (StorPool) and, actually, also Canonical would be very, very happy for if this could go in | |
| 14:20:09 | Roamer` | sorry... | |
| 14:20:18 | Roamer` | I honestly hadn't realized that it needed a second +2 vote, my bad, my very bad :( | |
| 14:21:03 | Roamer` | and yeah, there's history... we tried submitting a driver too late for Juno, then it went into Kilo, then we messed up and it was removed, and now we're trying to get it back | |
| 14:21:07 | Roamer` | aaaaand I'll shut up now | |
| 14:22:45 | kashyap | mriedem: Heya, so...I wrote this: https://review.openstack.org/#/c/523958/18. I agree with you on most / all topics. Besides this. Wonder what you think of my POV there. | |
| 14:26:19 | openstackgerrit | sahid proposed openstack/nova master: libvirt: disconnect volume from host during detach https://review.openstack.org/515008 | |
| 14:26:43 | gibi_ | stephenfin: lgtm! +2 | |
| 14:27:18 | efried | gibi_ But don't +W it, cause the gate's broken. Or whatever. | |
| 14:28:09 | gibi_ | efried: I was the first +2 | |
| 14:35:21 | gibi | stephenfin: could you look at these? https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-queens+status:open+label:Code-Review%253D%252B2 to easy notification transformation before FF :) | |
| 14:35:36 | mriedem | gibi: stephenfin: i'll look at https://review.openstack.org/#/c/465081/ again, | |
| 14:35:39 | mriedem | since i was -1 on it | |
| 14:36:02 | gibi | mriedem: thanks | |
| 14:36:22 | stephenfin | gibi: Sure, it's been on my list | |
| 14:36:28 | takashin | mriedem: Thank you. | |
| 14:36:31 | stephenfin | Along with some of gmann's API stuff | |
| 14:36:53 | gibi | stephenfin: thanks | |
| 14:39:19 | ameeda | hello, how to run pep8 for one class ? | |
| 14:39:46 | ameeda | tox -e pep8 -- -n nova/tests/unit/compute/test_compute_api.py , doesn't work | |
| 14:41:07 | maciejjozefczyk | ameeda: tox -e pep8 nova/virt/libvirt/driver.py ? | |
| 14:41:19 | stephenfin | ^ that | |
| 14:41:19 | mriedem | kashyap: replied | |
| 14:42:18 | ameeda | maciejjozefczyk: Thanks, let me try | |
| 14:42:27 | SpazZz | Why is it still 40 degrees in south texas | |
| 14:42:28 | ameeda | maciejjozefczyk: Thanks ^_^ | |
| 14:42:29 | efried | ameeda You can run flake8 directly from the pep8 venv. source .tox/pep8/bin/activate; flake8 path/to/file.py path/to/another.py etc.py | |
| 14:42:31 | SpazZz | One more day of this and i'll die | |
| 14:42:33 | SpazZz | thems the rules | |
| 14:42:38 | efried | SpazZz ++ | |
| 14:42:41 | ameeda | thanks all | |
| 14:42:49 | maciejjozefczyk | ameeda: :) | |
| 14:42:59 | sean-k-mooney | ameeda: if you have commited the chagne you can use tox -e fast8 to just run tox on the files you changed in the last commit | |
| 14:43:08 | maciejjozefczyk | sean-k-mooney: good to know | |
| 14:43:57 | efried | And to nerd out just a little bit more, to check the last e.g. 6 commits in a series, I do this from my pep8 venv: git diff --name-only HEAD~6 | grep '\.py$' | xargs flake8 | |
| 14:43:57 | SpazZz | If any cores got some cycles today for this would be much appreciated. +1'd by two citrix folks, need mah +2 love now :) https://review.openstack.org/#/c/533168/ | |
| 14:44:01 | mdbooth | sean-k-mooney: If that's the same as 'tox -e pep8 -- -HEAD' it will also include uncommitted changes in the working directory. | |
| 14:44:19 | SpazZz | Ignore the IBM.. it'll go away eventually :P | |
| 14:44:20 | ameeda | sean-k-mooney: thank you, I appreciate all your help | |
| 14:44:57 | mdbooth | efried: Nice... | |
| 14:45:10 | sean-k-mooney | mdbooth: oh am yes it is. i sometiems have line lenght issue in my commit message so i prefer to commit first out of habbit | |
| 14:45:12 | mriedem | lyarwood: mdbooth: regarding https://review.openstack.org/#/c/523958/ - since it knowingly regresses swap volume with a luks-encrypted volume, is anyone working on a nova patch to workaround that and fallback to the old non-native routine? | |
| 14:45:30 | mdbooth | mriedem: I responded to that on the ML | |
| 14:45:35 | mriedem | lyarwood: mdbooth: because it's getting pretty late to just merge this and put something in the release notes about oopsies | |
| 14:45:51 | mdbooth | I don't really regard it as a regression, tbh, as it was entirely broken until this Monday | |
| 14:46:10 | mdbooth | And there's already an upstream bug tracking it in libvirt | |
| 14:46:17 | jaypipes | mriedem, efried: good morning fellas. I have a few hours before I need to go to the airport. so I'll try to focus on patch reviews during this time. do we have a priority list? | |
| 14:46:27 | jaypipes | dansmith: you too.. | |
| 14:46:54 | mdbooth | mriedem: We'd be adding in workaround code for something which needs an underlying fix. | |
| 14:47:13 | mriedem | mdbooth: then we need something more discoverable than a small note in a release note, | |
| 14:47:30 | mriedem | e.g. maybe a docs update to cinder saying that you can't migrate/retype an encrypted volume for now | |
| 14:47:41 | efried | jaypipes The update_provider_tree series is ready up to update_from_provider_tree. There's some possibly-controversial stuff towards the top. Not sure how much chance of getting approved before FF, but at least worth skimming. | |
| 14:48:01 | mdbooth | mriedem: Well you never could... | |
| 14:48:02 | jaypipes | mriedem, efried: I'm also continuing my patch series on the alloc candidates and n-r-p. been slow going because of $work the last two days | |
| 14:48:19 | mdbooth | mriedem: It's only a disappointment to anybody running master who updated on Monday | |
| 14:48:31 | efried | Heh. $work meaning work you get a paycheck for? :) | |
| 14:48:31 | jaypipes | efried: what's the latest status on alex_xu's patches around traits in alloc candidates? | |
| 14:48:45 | jaypipes | efried: yeah, that :) | |
| 14:48:51 | mriedem | mdbooth: ok - my point is, i don't know if no one else in the world knows you never could | |
| 14:48:55 | efried | jaypipes I believe we're +W and in recheck hell, but that could just be the bottom patch. | |
| 14:48:57 | efried | looking... | |
| 14:48:57 | mriedem | so, docs would be a good start | |
| 14:49:15 | mriedem | because users of openstack do'nt know, or shouldn't need to know, low level details about how the code works | |
| 14:49:18 | jaypipes | efried: the REST API change one? | |
| 14:49:19 | alex_xu | jaypipes: yes, all of those patches get approved...then recheck and recheck... | |
| 14:49:34 | jaypipes | alex_xu: gotcha, k, thx for the update | |
| 14:49:55 | stephenfin | Roamer`, mriedem: That's done now. There's some cleanup/simplification that can be done, but that's a separate effort | |
| 14:50:40 | mdbooth | mriedem: Critically we're not regressing. | |
| 14:50:58 | jaypipes | mriedem: depends. if you've an NFV user, of *course* you need to know all the low-level details of everything going on. ;) | |
| 14:51:02 | Roamer` | stephenfin, thanks a lot! And, yes, good catch on the exception... | |
| 14:52:02 | mriedem | jaypipes: yeah that's true | |
| 14:52:24 | mdbooth | mriedem: The way I see it is this implementation is much simpler and more robust for Nova, as I mentioned on the ML. | |
| 14:52:32 | jaypipes | efried: is the recheck hell due to timeouts in zuul jobs or is it due to a particular bug in a dependency (or nova etc) | |
| 14:52:32 | mriedem | jaypipes: well, except for the part where you just tell nova to put the instance on this host and this numa node and this set of cpus, totally bypassing the scheduler | |
| 14:52:45 | jaypipes | mriedem: right. NFV. | |
| 14:53:01 | efried | jaypipes The latest and greatest is the log server went read-only. We're supposed to not recheck anything until they've sent another broadcast saying it's fixed. | |
| 14:53:02 | mriedem | jaypipes: there was a big regression on tuesday that caused most dsvm jobs to fail. the fix for that merged yesterday. | |
| 14:53:06 | mdbooth | We can add complexity to work around a temporary limitation in the underlying library, but given that the feature in question never worked anyway I think it would be better just to note that it doesn't work. | |
| 14:53:09 | jaypipes | mriedem: that's pretty much what I've been talking about at this $work thing for 2 days. | |
| 14:53:12 | mriedem | however, still hitting job timeouts and post failures | |
| 14:53:26 | jaypipes | k | |
| 14:53:45 | jaypipes | efried: ack | |
| 14:53:59 | mdbooth | mriedem: Specifically, I don't want to add yet anothing config option for this: it should be transparent to the operator. | |
| 14:54:01 | efried | jaypipes I also noticed (not sure if there's actual cause->effect here) that rechecking jobs *later* in The Big Series caused the bottom patch to stall in the gate. | |
| 14:54:11 | jaypipes | hmm. | |
| 14:54:22 | efried | jaypipes So I think whenever stuff opens up again, I'm going to try just checking the bottom one. | |
| 14:54:23 | jaypipes | not sure I've personally seen that yet. | |
| 14:55:04 | efried | yeah, it was weird. The bottom one was in the gate and blue worms creeping along, looking good. Then I rechecked some above it. And then the bottom one stopped having blue worms (but stayed in the gate queue). | |
| 14:55:18 | mriedem | mdbooth: i'm not asking for a config option | |
| 14:55:52 | efried | ...where it has been for ~11.5h now | |
| 14:56:47 | openstackgerrit | Ameed Ashour proposed openstack/nova master: detaching volumes when deleted VM is in error state https://review.openstack.org/528069 | |
| 14:56:48 | openstackgerrit | Ameed Ashour proposed openstack/nova master: detach instance volumes when VM creation fails https://review.openstack.org/528385 | |
| 14:57:44 | mdbooth | mriedem: It's not a regression though, right? Specifically because it was always broken. There is nobody currently using this feature who will have their workflow broken by this change. | |
| 14:58:28 | mriedem | mdbooth: if we're not going to put some kind of conditional fallback code in place, then i don't think the release note should mention it really - it's confusing and alarming if you didn't realize this iddn't work until recently; and on top of that, we likely need an api-ref update to cinder to mention that retype/migration of an attached encrypted volume won't work on the compute side because of some bug | |
| 14:59:05 | mriedem | s/of some bug/it's not yet supported/ | |