| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-25 | |||
| 13:21:52 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/537897 | |
| 13:21:52 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 13:41:11 | stephenfin | owalsh: I think so, yup. I should probably encode that | |
| 13:51:39 | Spazmotic | IBM CI what is wrong with you :( http://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/index.html | |
| 13:52:06 | mmedvede | Spazmotic: it should be fixed now, at least the original problem that was causing earlier failures | |
| 13:52:16 | Spazmotic | Ahhh thanks mmedvede | |
| 13:52:19 | Spazmotic | I'll give it a new recheck hehe | |
| 13:53:13 | mriedem | Roamer`: i won't be +Wing your change because we require 2 +2s | |
| 13:58:26 | mriedem | gibi_: we should probably consider bumping the nova functional job timeouts as a change on top of your patch to move them into the nova tree | |
| 14:00:00 | hrw | stephenfin: turns out that one change to libvirt makes life easier. | |
| 14:00:20 | hrw | stephenfin: will wait for libvirt devs to respond before testing it further | |
| 14:00:29 | mriedem | nova meeting starting in #openstack-meeting | |
| 14:00:46 | gibi_ | mriedem: I can do that | |
| 14:01:34 | gibi_ | mriedem: is it just the functional or also the functional-py35 job that times out frequently? | |
| 14:01:40 | mriedem | both | |
| 14:01:45 | gibi_ | mriedem: OK | |
| 14:04:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Ensure emulator threads are always calculated https://review.openstack.org/537363 | |
| 14:04:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Don't filter out sibling sets with one core https://review.openstack.org/537361 | |
| 14:04:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Always pass 'NUMACell.siblings' to _pack_instance_onto_cores' https://review.openstack.org/537364 | |
| 14:13:37 | stephenfin | mriedem: Could you take a look at this after the meeting? https://review.openstack.org/#/c/527182/ It's blocking https://review.openstack.org/#/c/526329/ | |
| 14:14:04 | stephenfin | Maybe gibi_ too, if you have the time ^ | |
| 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 | |