| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-27 | |||
| 20:34:38 | artom | mriedem, dansmith, I think we may have gotten a filter wrong, but I could just be being an idiot. Review left. | |
| 20:35:34 | mriedem | cfriesen: that's what i explained before | |
| 20:35:59 | mriedem | cfriesen: and why i wrote https://review.openstack.org/#/c/411035/ | |
| 20:47:46 | mriedem | artom: so just AggregateMultiTenancyIsolation at this point | |
| 20:47:47 | mriedem | ? | |
| 20:48:07 | artom | mriedem, yeah. Am I correct in wondering why it's True? | |
| 20:48:20 | mriedem | yeah i think that's a carry over from PS5 when it used to be called POLICY_FILTER | |
| 20:48:24 | mriedem | and got lumped in as 'policy' | |
| 20:48:35 | mriedem | https://review.openstack.org/#/c/521186/5..7/nova/scheduler/filters/aggregate_multitenancy_isolation.py | |
| 20:49:12 | artom | Cool, so I'm not in the field | |
| 20:50:54 | mriedem | ok so i think i'll just change that one unless dansmith objects | |
| 20:51:09 | dansmith | I'm sure I don't | |
| 20:52:10 | artom | dansmith is like this pigeon at this point: https://imgur.com/gallery/Y5Ps3 | |
| 20:52:37 | dansmith | pretty much | |
| 20:53:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refined fix for validating image on rebuild https://review.openstack.org/521186 | |
| 20:53:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153 | |
| 20:53:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662 | |
| 20:53:52 | mriedem | artom: are you happy now? | |
| 20:56:09 | artom | mriedem, sorry what? I've gone and joined dansmith and the pigeon on the dog: https://i.imgur.com/ijgWRzw.jpg | |
| 20:56:19 | artom | mriedem, in seriousness though, yes. Thanks for being patient :) | |
| 20:57:16 | mriedem | approved, thanks for being thorough | |
| 20:57:41 | mriedem | just like henry david | |
| 20:57:52 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/522929 | |
| 20:58:39 | artom | Oh and this means I get to do all those downstream CVE backports I signed for | |
| 20:59:11 | artom | So, actually, I have another nit I'd like to bikeshed over for the entire week | |
| 21:15:39 | openstackgerrit | Claudiu Belu proposed openstack/nova master: POC: tests: autospecs all the mock.patch usages https://review.openstack.org/470775 | |
| 21:17:19 | claudiub|2 | mriedem: hi. if you're still interested about mock autospecing, the above patch enforces autospec on all mock.patch calls. it does have a few hacks though, if you're willing to accept the compromise. | |
| 21:23:44 | belmoreira | dansmith: was testing what you proposed. I though I had a good solution... now I feel embarrassed :) | |
| 21:23:46 | belmoreira | dansmith: It works great! thanks | |
| 21:24:52 | dansmith | belmoreira: cool, glad to hear it | |
| 21:26:20 | belmoreira | dansmith: do you think this can still be added into newton? | |
| 21:26:39 | dansmith | belmoreira: not backported upstream most likely, but it should apply easily (as you know) | |
| 21:27:50 | belmoreira | ok, thanks again | |
| 21:32:21 | cfriesen | mriedem: did we ever figure out what to do about keypairs and users/tenants? (like where one user creates a heat stack and another within the same tenant can't delete it) | |
| 21:32:40 | cfriesen | can't find anything in the etherpads | |
| 21:34:01 | mriedem | cfriesen: you can now rebuild an instance with a new key_name | |
| 21:34:18 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/rebuild-keypair-reset.html | |
| 21:35:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add instance action record for attach/detach/swap volumes https://review.openstack.org/517205 | |
| 21:37:17 | cfriesen | mriedem: right, I knew about that part. but I thought some people were talking about how keypairs should really be owned by the tenant. Could be it never actually got written down. | |
| 21:37:47 | mriedem | cfriesen: i'm not really remembering that | |
| 21:37:53 | mriedem | cfriesen: maybe sdague does | |
| 21:38:22 | cfriesen | thx | |
| 21:43:18 | sdague | keypairs are the only resource not owned by the tenant | |
| 21:44:10 | sdague | it makes for a very weird model of ownership, because the point was supposed to be that tenants owned all the things, and users were just permissions to be part of a tenant | |
| 22:04:51 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 22:19:28 | melwitt | cfriesen, mriedem: I recall some discussion about how user A in a tenant can't ever view user B's keypairs in the same tenant. I just can't remember where/when that was | |
| 22:19:59 | melwitt | it's so baked in that it would probably be difficult to change | |
| 22:21:17 | cfriesen | melwitt: true. what about the the weirdness of per-tenant keypair quotas when keypairs belong to users across all tenants? | |
| 22:23:28 | melwitt | cfriesen: currently, I think you can set keypair quota per tenant but what it means is "how many keypairs can each user in the tenant have" | |
| 22:23:52 | melwitt | are you thinking of a per tenant quota that means "how many keypairs can this tenant have in total"? | |
| 22:23:59 | cfriesen | melwitt: but a user can exist in multiple tenants, so which one applies? | |
| 22:24:15 | melwitt | whichever one the user is authing as at the moment | |
| 22:24:34 | melwitt | i.e. the tenant passed in the REST API request | |
| 22:24:42 | cfriesen | okay, that makes sense in a weird sort of way. | |
| 22:25:06 | cfriesen | it does mean your usage in one tenant could go up due to activity in another tenant | |
| 22:27:26 | melwitt | ah yeah, that's true. keypairs are counted per user. | |
| 22:27:30 | mriedem | yikun: good morning. :) do we really need https://review.openstack.org/#/c/517273/ to add paging support for the os-migrations API? can't we just find the starting cell for the marker by iterating the cells until we find the one with the marker migration? that's obviously less efficient since we don't have a mapping in the API database, but i don't think performance here is as big a concern as it is for paging instances acros | |
| 22:27:30 | mriedem | ltiple cells. | |
| 22:30:50 | zigo | I'm getting a weird error in my tempest test env: qemu-img: file system may not support O_DIRECT\nqemu-img: Could not open '/var/lib/nova/instances/_base/c44b0b620ae7c6fd8111e0abb5a8d1fc39fcdf08.converted': Could not open '/var/lib/nova/instances/_base/c44b0b620ae7c6fd8111e0abb5a8d1fc39fcdf08.converted': Invalid argument | |
| 22:31:25 | zigo | It looks like qemu-img doesn't like me running on a filesystem using overlay for / over tmpfs ... | |
| 22:31:47 | zigo | Is there any workaround ? | |
| 22:33:48 | zigo | penick: Blinking reading what I wrote ? :) | |
| 22:33:56 | melwitt | zigo: what release of nova are you running? | |
| 22:34:17 | zigo | melwitt: 16.0.3 | |
| 22:34:25 | melwitt | I found this stackoverflow thing about it https://serverfault.com/questions/537440/qemu-dont-start-quest-with-disk-image-on-tmpfs which reminded me I've seen code in the libvirt driver that's supposed to handle this | |
| 22:34:29 | zigo | I'm trying to functional-validate Pike for Debian. | |
| 22:35:50 | zigo | melwitt: It seems related to qemu-img not converting the image before booting it, though... | |
| 22:36:07 | melwitt | this part is checking whether the filesystem supports direct io and will set cache=writethrough in that case to avoid the crash https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L406-L414 | |
| 22:36:39 | zigo | stack dump: http://paste.openstack.org/show/627515/ | |
| 22:36:41 | melwitt | (which is the workaround, cache=writethrough but it should be working around for you automatically) | |
| 22:38:21 | zigo | Hum ... | |
| 22:38:44 | zigo | melwitt: Is there any way I can just force nova to never use direct IO then? | |
| 22:38:53 | zigo | Even an ugly hack, just to check ... | |
| 22:38:57 | mriedem | dansmith: you might have some ideas here https://review.openstack.org/#/c/517273/21/nova/compute/migration_list.py - i think using the instance list merge sort framework that you wrote is maybe overkill for paging migrations across cells, but i'm unsure if the alternative (including a merge sort of the results in the api) is any less complicated. | |
| 22:40:00 | dansmith | mriedem: definitely if we don't allow sort keys or directions (agreed we shouldn't) | |
| 22:40:05 | zigo | melwitt: I'll try to always set writethrough and see what happens... | |
| 22:40:16 | dansmith | mriedem: looks like it was blindly copied in there huh? | |
| 22:40:22 | melwitt | zigo: something that might work is if you set [libvirt]/disk_cachemodes = file=writethrough | |
| 22:40:46 | dansmith | mriedem: I can apply more brainpower to this tomorrow if needed | |
| 22:41:04 | zigo | melwitt: Thanks, trying now ! | |
| 22:42:51 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: SEA https://review.openstack.org/523216 | |
| 22:45:04 | zigo | melwitt: Bad luck, it's still the same log in nova-compute.log ... :/ | |
| 22:45:04 | mriedem | dansmith: there is a patch below it which extracts some of the common object wrapper bits, but otherwise yeah it's mostly a copy of instance_list | |
| 22:45:37 | dansmith | mriedem: yeah, I'm not really in favor of genericifying that stuff unless we need to, it just becomes more complex | |
| 22:45:38 | mriedem | and i'm thinking if the user can't pass sort keys/dirs, (which they can't for os-migrations), then it's less work for us to just find the marker, page from there (like we used to do for instances) and merge sort the results at the end | |
| 22:45:46 | dansmith | yup | |
| 22:46:06 | mriedem | i know yikun wrote up some test cases so i think he was mostly worried about the merge sort prat | |
| 22:46:07 | mriedem | *part | |
| 22:46:13 | melwitt | zigo: guh :( okay, so we have some bug there where we're not setting cache mode in that particular code path or something like that. I'd have to dig into it more to know what's going on there | |
| 22:46:49 | zigo | melwitt: Let me check with /var/lib/nova/instances mounted on ext4, just to make sure that's the issue. | |
| 22:47:31 | melwitt | zigo: what images_type are you using? just flat? or is it volume or ceph? | |
| 22:48:13 | zigo | melwitt: You mean for the image that I'm trying to boot? It's a "nornal" qcow2 image ... | |
| 22:48:42 | zigo | ie: the official Debian OpenStack Stretch image that I maintain in cdimages.debian.org/cdimages/openstack ... | |
| 22:49:04 | zigo | flat file in glance ... | |
| 22:49:33 | melwitt | oh okay, I see | |
| 22:59:52 | zigo | melwitt: I'm getting a different error due to other issues in my setup (neutron issue apparently), but I'm not seeing the qemu-img problem anymore after mounting over ext4 ! | |
| 23:00:00 | zigo | So definitively there's a problem... | |
| 23:01:17 | zigo | Should I file a bug? | |
| 23:03:14 | melwitt | zigo: yeah, if you could file a bug that would help us look into it | |
| 23:13:30 | gmann | mriedem: melwitt happy to get more review on novaclient zullv3 migration - https://review.openstack.org/#/q/topic:zuulv3-novaclient | |