Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-27
19:10:58 mriedem i don't know that it needs to go to ocata
19:11:13 mriedem i think this actually crept up in CI because posting allocations during scheduling failed
19:11:15 mriedem which wasn't in ocata
19:12:15 jaypipes mriedem: I'll handle the backport to pike, then, no prob.
19:13:22 sdague mriedem: +2, though I'm still rather down on all the deepcopy and modify pattern, I think it creates more of these bugs in the future
19:13:35 sdague vs. just do a full expand every time there is a new tweak on the schema
19:22:23 mriedem sdague: thanks
19:22:27 mriedem dansmith: here is my proposed reno https://gist.github.com/mriedem/3da0a2edf18be0487e8becad31293077
19:22:36 mriedem for https://review.openstack.org/#/c/521186/
19:22:44 openstackgerrit Merged openstack/nova master: finish refactor AllocCandidates._get_by_filters() https://review.openstack.org/516782
19:23:04 openstackgerrit Merged openstack/nova master: required traits for no sharing providers https://review.openstack.org/517027
19:23:20 openstackgerrit Merged openstack/nova master: Add ProviderSummary.resource_class_names @property https://review.openstack.org/517646
19:31:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Refined fix for validating image on rebuild https://review.openstack.org/521186
19:31:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153
19:31:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662
19:31:37 mriedem jaypipes: i added a reno on https://review.openstack.org/521186 which you were +2 on
19:33:43 cfriesen when updating the default quota class set, if I set a value lower than the current usage will that prevent any more resources from being consumed? updating quota-sets has the "force" option for this case, but I don't see that for quota class sets.
19:36:51 mriedem cfriesen: quota classes aren't tied to a tenant
19:37:00 mriedem so there is no 'current usage' on a quota class
19:37:38 mriedem as for "if I set a value lower than the current usage will that prevent any more resources from being consumed" - i'm not sure
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: Refined fix for validating image on rebuild https://review.openstack.org/523212
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: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: 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

Earlier   Later