Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-11
19:31:15 mriedem and after we create,
19:31:16 melwitt mriedem: when we check quota after we created a resource, we want to check: count now against the limit
19:31:25 mriedem we check count now against limit
19:31:28 mriedem after creating the thing
19:31:28 melwitt right
19:31:33 melwitt exactly
19:32:13 melwitt "now that we have created the thing, are we currently over quota" and that will be a "yes" if parallel requests raced and too many resources got created
19:33:23 melwitt (if too many got created and are > limit all together)
19:33:42 mriedem right, i was wondering if we needed to process the 'overs' kwarg out of TooManyInstances and delete more than one instance
19:34:18 melwitt oh, I see. I had thought no because each thread created one instance and would delete one instance
19:34:54 mriedem yeah i'm talking to myself in the review a bit
19:36:03 melwitt trying to think if there's a wrinkle with multi boot. I had thought only delete the one that registered as OverQuota and leave the rest, because it's going to set them all to ERROR anyway I think because of how multi boot works when one fails
19:36:21 mriedem yeah i was also thinking about multi create
19:36:35 mriedem and how, if possible, that can screw us here
19:37:22 mriedem but we get the min and max from the request before _provision_instances calls check_num_instances_quota
19:37:22 melwitt yeah. at the least I should add a test for that scenario (recheck_quota fails during multi boot). I hadn't thought of it at the time
19:37:45 melwitt oh ... that's right
19:37:56 mriedem i'm not sure if we can get into that failure
19:38:05 melwitt it checks them all at the same time. but I do know if it fails max_count it will check again with min_count
19:38:57 melwitt er sorry, it will calculate how many it can fit and if it's at least min_count, it will go ahead with how many it thinks will fit
19:39:10 melwitt I found that part pretty confusing
19:39:45 mriedem yeah, elif min_count <= allowed <= max_count:
19:39:55 mriedem return check_num_instances_quota(context, instance_type, min_count,
19:39:55 mriedem allowed, project_id=project_id,
19:39:55 mriedem user_id=user_id)
19:40:02 mriedem so allowed becomes the new max_count
19:40:20 mriedem so give me the min i want plus fill up the rest of my quota
19:41:19 melwitt right, if max was more than quota
19:48:58 jaypipes mriedem: answered you. ack on the reason for not adding a new policy rule.
19:49:29 mriedem double ack good buddy 10-4
20:18:10 mriedem hmm
20:18:20 mriedem melwitt: we should see if tempest has a soft delete / restore test
20:19:21 claudiub mriedem: heya. any idea where the nova PCI passthrough / SR-IOV guide went?
20:19:32 mriedem melwitt: there isn't - there are only negative tests in tempest for restore
20:19:36 mriedem test_restore_nonexistent_server_id
20:19:40 mriedem test_restore_server_invalid_state
20:19:42 claudiub can't seem to find anymore, only some wiki since juno
20:20:26 mriedem claudiub: hmm, the docs are all being migrated from the openstack-manuals repo
20:20:43 mriedem https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:doc-migration
20:20:54 mtreinish mriedem: I like how you know that off the top of your head
20:21:07 mriedem mtreinish: know what now?
20:21:08 melwitt mriedem: we have functional tests for it nova/tests/functional/test_servers.py test_deferred_delete*
20:21:35 mriedem mtreinish: i searched through the tempest compute api tests for the 'restore' action
20:21:36 mriedem :)
20:21:36 mtreinish there is no restore test in tempest
20:21:54 mriedem found the client call and traced that back to the 2 negative tests
20:21:57 mtreinish heh, you should have just gone with it
20:22:04 mriedem i mean, i know all
20:22:04 mtreinish pretended to know :)
20:22:32 claudiub mriedem: cool, ty. :)
20:22:56 mriedem claudiub: probably this change https://review.openstack.org/#/c/477497/
20:23:12 mriedem the cpu topologies stuff is in there for numa, huge pages and cpu pinning
20:23:16 claudiub yep, that's the one i was looking at.
20:23:44 mriedem ok, i know there is some stuff in the flavor extra specs doc about pci passthrough
20:23:52 mriedem i think the sriov stuff is in the networking guide?
20:24:06 claudiub i was asking because i was getting some nova-api errors when i was trying to spawn an insance with a flavor extra_spec pci_passthrough:alias
20:24:32 claudiub and was wondering if i missed some configuration
20:25:09 mriedem melwitt: so my point with restore is,
20:25:23 mriedem the way things used to work, when we soft deleted an instance, we would decrement usage, right?
20:25:30 mriedem and on restore, we'd check instance quota + 1
20:25:54 claudiub as for sriov, afaik, it should be able to be used just like pci passthough.
20:26:08 melwitt mriedem: I think soft-deleted instances count against quota until they are deleted for real behind the scenes after the reclaim interval passes
20:27:11 melwitt wait hang on, maybe I'm wrong
20:27:35 mriedem yeah i don't think that's right
20:27:49 mriedem soft delete in the api would create a decrement reservation and pass that to the compute manager
20:27:50 melwitt yeah, sorry. quota is indeed released upon soft delete even if reclaim hasn't happened yet
20:28:02 mriedem the compute manager soft_delete_instance would commit the reservation when it deleted the guest
20:28:13 melwitt I got mixed up thinking about a patch someone has up to tie up quota until reclaim
20:28:15 mriedem or rollback if the soft delete fails in the manager
20:29:30 mriedem ok leaving comments
20:29:33 melwitt mriedem: so it's a matter of, we need to make sure the count doesn't count soft deleted instances, and I'm pretty sure it doesn't bc the {'deleted': False} filter includes soft delete IIRC
20:29:36 mriedem still chugalugging through the api
20:29:44 melwitt thanks
20:30:03 mriedem i haven't even gotten to the count_as_dict thingy yet
20:30:04 mriedem :)
20:30:26 mriedem i'd think we could also just remove the check_num_instances_quota call from restore() in the compute api
20:31:39 mriedem which now has me thinking,
20:31:45 melwitt why? to keep the behavior we would check quota since that's going to change usage
20:32:04 mriedem this is going to be an upcall from the computes
20:32:10 melwitt soft delete takes it out of usage, restore would put it back into usage
20:32:48 melwitt I thought the check for restore is in compute/api, not an upcall. *looks*
20:32:58 mriedem it is,
20:33:11 mriedem i'm talking about anything that happens in the compute manager on soft_delete_instance or reclaim_queued_deletes
20:34:20 melwitt why does it matter what happens in compute manager? if usage is decremented when the user soft deletes, it's already handled?
20:35:45 mriedem where do we actually decrement the usage in the API on soft delete though?
20:37:17 melwitt when it's marked as soft deleted, it should no longer show up in the count because of the {'deleted': False} filter in the count function
20:37:28 mriedem oh yeah, was just about to make that connection
20:39:47 melwitt this is where the logic is https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2167-L2192
20:56:00 mriedem melwitt: dansmith: ok, i have posted comments. i have to jump on a call for a bit. i still need to go through the resize stuff to complete the api, and then everything else after that...
20:57:40 melwitt thanks mriedem
21:08:34 dansmith is the gate sick?
21:08:40 dansmith seems like the queue is barely draining
21:15:18 alaski \quit
21:15:28 alaski grr
21:16:34 melwitt o/ alaski
21:35:26 jaypipes I want to firebomb these scheduler unit tests.
21:38:10 melwitt :)
21:38:43 jaypipes melwitt: seriously. I am contemplating making napalm to douse my computer with.
21:39:59 melwitt heh. I feel you.
21:43:13 alaski o/ cdent and melwitt

Earlier   Later