Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-11
18:41:23 mriedem ok
18:50:26 mriedem jaypipes: replied,
18:50:33 mriedem see if my reply on the policy stuff makes sense
18:50:40 jaypipes k
18:52:48 openstackgerrit Merged openstack/nova master: Fix error message when support matrix entry is missing a driver https://review.openstack.org/480708
18:59:58 mriedem melwitt: i think we need to handle this differently https://review.openstack.org/#/c/446243/ - but you could hold off on updating it for awhile, i'm going to dive into the counting instances change at the bottom
19:00:02 mriedem for about 4 hours
19:00:37 melwitt mriedem: cool, saw the comment. makes sense
19:01:10 melwitt and thanks in advance for reviewing counting instances
19:03:20 dansmith mriedem: melwitt I don't really disagree, although I think that if they don't notice the deprecation message, they won't notice the error if we exit with zero, which means we're just kicking the can down the road
19:03:34 dansmith but if making it a no-op gets us out of deprecation jail, then whatever
19:04:34 melwitt yeah, fair point
19:04:35 mriedem yes it avoids deprecation jail
19:10:31 mriedem gd those giant ass try/except blocks
19:29:01 mriedem melwitt: how does check_deltas work with the 0 delta again?
19:29:31 melwitt mriedem: it just means check usage vs limit without a delta, delta of 0
19:30:59 melwitt mriedem: when we check quota before we create a resource, we want to check: count now + count delta against the limit
19:31:10 mriedem yeah
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,

Earlier   Later