Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-27
19:37:54 mriedem it might
19:38:00 cfriesen mriedem: I was envisioning usage as being basically per tenant.
19:38:33 mriedem we check limits based on (1) is there a specific limit for this project, (2) if not, is there a specific limit for this quota class, (3) if not, what's the configured limit
19:38:37 cfriesen so you have the class default as 10, the tenant currently has 9, I change the class default to 8
19:39:06 mriedem i think that will cause the next instance create to be overquota
19:39:27 cfriesen that matches my understanding, thanks. it's odd we have "force" for that when setting tenant quotas but not the global default
19:39:34 mriedem the point in changing the limits to be below the usage (like the force parameter in PUT /os-quota-sets) is to get to the desired limit regardless of current usage
19:40:01 mriedem if we checked that on the global default, we'd have to check usage for all projects
19:40:10 mriedem and,
19:40:26 mriedem we could be tracking quota for projects that no longer actually exist in keystone
19:40:35 cfriesen true enough
19:40:54 openstackgerrit Merged openstack/nova master: Implement query param schema for delete assisted vol https://review.openstack.org/513668
19:41:07 openstackgerrit Merged openstack/nova master: Versioned notifications for service create and delete https://review.openstack.org/519588
20:08:58 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/523213
20:08:58 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Refined fix for validating image on rebuild https://review.openstack.org/523212
20:08:59 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix doubling allocations on rebuild https://review.openstack.org/523214
20:15:25 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: SEA https://review.openstack.org/523216
20:19:37 cfriesen mriedem: when querying quota details including usage for a tenant/user, does it only count resources created by that user?
20:20:42 mriedem cfriesen: you should talk to melwitt
20:27:39 mriedem cfriesen: in general quotas are on the usage in the project,
20:27:41 mriedem except for keypairs
20:28:25 mriedem you can see how usage is counted by the methods called for each CountableResource here https://github.com/openstack/nova/blob/master/nova/quota.py#L1903
20:28:58 cfriesen mriedem: thanks
20:30:35 mriedem so i guess PUT /os-quota-sets/{tenant_id} is a bit weird if you're updating limits for keypairs, since those are per-user, so that should really be something like PUT /os-qouta-sets/{tenant_id}/key_pairs/{user_id} - or something like that
20:32:24 cfriesen quotas in general is a mess. the mapping between the HTTP API and the internal representation is really indirect. Looking at the quota for a user/tenant, it takes multiple queries to figure if the limit came from a tenant/user quota, a tenant quota, the default quota class, or the default in the code or config file.
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: Fix doubling allocations on rebuild https://review.openstack.org/521662
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: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 ltiple cells.
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: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)

Earlier   Later