| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-19 | |||
| 14:04:54 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver https://review.openstack.org/638680 | |
| 14:05:21 | mriedem | alex_xu: replied in https://review.openstack.org/#/c/644293/ - thanks for those questions | |
| 14:05:51 | efried | mriedem: This ready to go? https://review.openstack.org/#/c/644423/ I didn't want to rubber-stamp it if you wanted another look. | |
| 14:06:07 | mriedem | efried: looking | |
| 14:06:25 | mriedem | got it | |
| 14:07:04 | efried | thx | |
| 14:12:06 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add docs for compute capabilities as traits https://review.openstack.org/644293 | |
| 14:12:32 | mriedem | efried: aspiers: alex_xu: ^ updated to use one of aspiers' suggestions and document the resource_provider_association_refresh thing in the commit message | |
| 14:14:05 | efried | mriedem: +2, still looks good | |
| 14:20:46 | kashyap | aspiers: I updated the machine types blueprint name (to "gracefully-handle-qemu-machine-types"). When I originally wrote it, discussions were hot on QEMU / libvirt & related lists about making 'q35' default. But since then many things have changed. | |
| 14:21:03 | kashyap | aspiers: When you next respin the patch, might want to update the reference to it. | |
| 14:38:17 | kashyap | aspiers: For later discussion, I'm still thinking if Nova should be in the business of deciding the default machine type fo 'x86'. I'm updating the problem description in the specification. Can discuss there | |
| 14:38:24 | kashyap | (So feel free to disregard me here.) | |
| 14:41:58 | sean-k-mooney | kashyap: right now you can set it in the config if you chooes to otherwise we leave it up to qemu | |
| 14:42:29 | sean-k-mooney | kashyap: im not sure if we need to chage that or not as intaller tool like tripleO can always just set it in the config | |
| 14:42:48 | kashyap | sean-k-mooney: Yes, I'm writing it up in the spec, if only for discussion, and that we considered it. | |
| 14:42:59 | kashyap | (There was an elaborate discussion on the 'qemu-devel' and 'libvirt' lists some months ago to change the defaults.) | |
| 14:43:16 | sean-k-mooney | yes i know :) | |
| 14:43:17 | kashyap | People seem to be overly paranoid about "backwards compat". | |
| 14:43:38 | sean-k-mooney | well it would break centos 6 vms | |
| 14:43:45 | sean-k-mooney | which are apparently still a thing | |
| 14:44:29 | sean-k-mooney | but ya i generally say use a sane default and if there isnt one leave it up to the operator | |
| 14:44:47 | aspiers | kashyap: ah, got it thanks | |
| 14:45:16 | sean-k-mooney | you could argue q35 is a sane default on security grounds but backwards comptiablity is also a good argument against it at least for a time | |
| 14:45:50 | dansmith | mriedem: yeah, you marked it as wishlist...does it need further action to demote it? | |
| 14:46:04 | sean-k-mooney | eventrualy security will win and we will want to change the default. not sure if its now or not but its good to discusse in anycase | |
| 14:52:20 | mriedem | dansmith: if you think it's a "never going to happen" thing, then you could mark it as won't fix with further words | |
| 14:52:52 | mriedem | dansmith: also for your awareness, https://review.openstack.org/#/c/640688/ is being discussed by the tc | |
| 14:54:11 | openstackgerrit | Matthew Booth proposed openstack/nova master: Eventlet monkey patching should be as early as possible https://review.openstack.org/626952 | |
| 14:54:39 | dansmith | mriedem: I don't know that I have a strong opinion on that (nor do I know why the tc would be involved in a discussion about it, but...) | |
| 14:54:40 | kashyap | Anyone with an Ubuntu machine, can you please post this output in a pastebin: `qemu-system-x86 -machine help` | |
| 14:56:03 | dansmith | mriedem: AFAICT, that's nova publishing metrics for which it is the authority to an external metrics-gathering service | |
| 14:56:39 | dansmith | mriedem: I've previously been opposed to abusing nova to collect metrics on non-nova things "since it's already deployed on the compute node" instead of installing a proper metrics-gathering daemon | |
| 14:56:45 | dansmith | but this is not that thing | |
| 14:56:47 | mriedem | kashyap: paste.openstack.org/show/748029/ | |
| 14:56:55 | mriedem | http://paste.openstack.org/show/748029/ | |
| 14:57:05 | kashyap | mriedem: Thank you! | |
| 14:58:08 | mriedem | dansmith: ack, see my comments about the smorgasbord of existing half baked metrics/usage/audit things we already expose | |
| 14:58:16 | mriedem | my main opposition is piling on to that pile | |
| 14:58:28 | dansmith | yeah, this is not that, AFAICT | |
| 15:11:08 | openstackgerrit | sahid proposed openstack/os-traits master: ci: re-enable openstack-python35-jobs https://review.openstack.org/644595 | |
| 15:12:19 | openstackgerrit | Gorka Eguileor proposed openstack/nova master: Use os-brick locking for volume attach and detach https://review.openstack.org/614190 | |
| 15:15:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Address old TODO in claim_resources_on_destination https://review.openstack.org/644596 | |
| 15:39:55 | mdbooth | This is weird, and doesn't reproduce for me locally: http://logs.openstack.org/52/626952/8/check/openstack-tox-docs/0876468/ara-report/result/73a64a42-855e-4818-980a-0a106766e721/ | |
| 15:40:31 | mdbooth | Does anybody know how I can kick off a 'openstack-tox-docs' job in check in isolation? | |
| 15:40:59 | mdbooth | I don't see that job in our .zuul.yaml, so I assume it's defined elsewhere | |
| 15:42:11 | artom | mdbooth, tox -e docs? Or am I being a simpleton? | |
| 15:42:26 | mdbooth | artom: That's how I can run it locally. That works fine. | |
| 15:42:40 | mdbooth | It failed in the check queue, though. I want to see if that happens again without having to wait 2 hours. | |
| 15:42:42 | artom | mdbooth, oh, you mean in CI | |
| 15:42:47 | mdbooth | Indeed. | |
| 15:43:04 | artom | mdbooth, I think if you just touch the docs subtree it'll only run those jobs | |
| 15:43:17 | mdbooth | Do you know where that's defined? | |
| 15:43:23 | artom | ... and you mean on your existing patches, don't you? | |
| 15:43:38 | artom | Without pushing a new docs-only DNM patch or w/e | |
| 15:43:46 | mdbooth | Well if I can find a way to kick it off in isolation I can layer a patch on top or something | |
| 15:43:57 | mdbooth | But I don't know what's running it. It's not in nova's .zuul.yaml | |
| 15:44:27 | mriedem | gibi: question for you in bence's neutron docs patch https://review.openstack.org/#/c/640390/5/doc/source/admin/config-qos-min-bw.rst@98 | |
| 15:44:47 | sean-k-mooney | mriedem: the check queue jsut use ansible to run the same tox env | |
| 15:44:55 | sean-k-mooney | mriedem: sorry mdbooth ^ | |
| 15:45:12 | mdbooth | sean-k-mooney: Where is it defined? | |
| 15:45:34 | sean-k-mooney | mdbooth: ill get the link. its in either zull-jobs or openstack-zull-jobs | |
| 15:45:36 | mdbooth | sean-k-mooney: I want a way to actually run it on CI infrastructure. | |
| 15:46:29 | sean-k-mooney | it should be identically to how you run it locally as its using a tox env but you might need to recreate your tox env with -r to make sure its clean | |
| 15:47:08 | mdbooth | It runs successfully in a local clean tox env | |
| 15:47:16 | mdbooth | I'm looking for a way to run it on CI | |
| 15:47:25 | sean-k-mooney | i think its this job https://github.com/openstack-infra/openstack-zuul-jobs/blob/master/zuul.d/jobs.yaml#L293-L321 | |
| 15:47:35 | mdbooth | It failed there for a reason which looks bizarre. | |
| 15:47:40 | sean-k-mooney | oh wait thats the old one | |
| 15:47:55 | sean-k-mooney | this one https://github.com/openstack-infra/openstack-zuul-jobs/blob/master/zuul.d/jobs.yaml#L618-L632 | |
| 15:48:24 | sean-k-mooney | mdbooth: do you have the failure so i can take a look | |
| 15:48:43 | mdbooth | http://logs.openstack.org/52/626952/8/check/openstack-tox-docs/0876468/ara-report/result/73a64a42-855e-4818-980a-0a106766e721/ | |
| 15:48:51 | mdbooth | AttributeError: module 'select' has no attribute 'poll' | |
| 15:49:13 | mdbooth | Given that this is against a monkey patching change, that's obviously suspect. However, it works locally. | |
| 15:51:39 | sean-k-mooney | well you can see the command at the top it was "tox -edocs -vv" | |
| 15:52:28 | mdbooth | Yep. That's how I know how to run it locally. That works ;) | |
| 15:52:57 | mdbooth | It doesn't work in CI, though. I was looking for a lightweight way to run that in CI to see if it can be reproduced in CI without having to wait 2 hours. | |
| 15:53:17 | sean-k-mooney | mdbooth: https://docs.python.org/3.6/library/select.html#select.poll | |
| 15:53:32 | sean-k-mooney | so apparently that is not suppored on all operating systems... | |
| 15:53:50 | mdbooth | sean-k-mooney: You think I might have been scheduled on a Windows CI worker? | |
| 15:53:53 | sean-k-mooney | we might be missing a depencny on the gate job | |
| 15:54:01 | mdbooth | That seems improbable ;) | |
| 15:54:06 | artom | sean-k-mooney, I'd thunk that meant Linux and Windows, not F29 and Ubuntu | |
| 15:54:12 | sean-k-mooney | it was on ubunut 18.04 | |
| 15:54:46 | artom | mdbooth, actually wait, are *you* running in on Windows? | |
| 15:54:51 | artom | You might be, knowing you | |
| 15:55:01 | mdbooth | artom: Hmm.... | |
| 15:55:09 | mdbooth | Yes I am. | |
| 15:55:15 | sean-k-mooney | mdbooth: can i have the link to the gerrit review | |
| 15:55:20 | sean-k-mooney | ill run it on my laptop | |
| 15:56:01 | mdbooth | artom: Running in WSL. However, I'd expect to see that *I* don't have poll() | |
| 15:56:06 | mdbooth | Linux definitely has poll. | |
| 15:56:12 | artom | mdbooth, true. | |
| 15:56:29 | jangutter | mdbooth: It's not a Windows CI worker - the pre jobs installed some bindep packages in Ubuntu: http://logs.openstack.org/52/626952/8/check/openstack-tox-docs/0876468/ara-report/result/9863769a-0d01-4a5a-b45a-345628504cbf/ | |
| 15:57:05 | mdbooth | jangutter: Surely we don't have any Windows CI workers! ? | |
| 15:57:34 | sean-k-mooney | mdbooth: we proably do for hyperv | |
| 15:57:40 | sean-k-mooney | but not for docs | |
| 15:57:56 | mriedem | lyarwood: dansmith: can one of you fast approve https://review.openstack.org/#/c/643011/ ? | |
| 15:59:03 | mriedem | bauzas: you want to get this rocky backport https://review.openstack.org/#/c/643098/ ? | |
| 15:59:10 | mdbooth | Linux is a bazillion times faster than WSL. | |