Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-13
20:19:16 mriedem but,
20:19:16 dansmith 1/1000 is probably a typo, 10/10000 is probably one user that loves shelve
20:19:27 mriedem interop is also like products like distros, not necessarily active clouds
20:19:33 mriedem so that doesn't work as well
20:20:02 mriedem if we can get the data, we can give it to sdague who can give it to watson
20:20:06 mriedem who will then turn it into trivia
20:20:15 dansmith hah
20:20:31 dansmith What is "kill soft delete" alex/
20:20:40 mriedem for 500
20:20:56 mriedem ooo that's the mothertruckin daily double!
20:22:43 dansmith https://i.ytimg.com/vi/3J2PlJmkvog/maxresdefault.jpg
20:22:59 melwitt lol
20:23:00 mriedem so,
20:23:10 mriedem if i'm writing this resize test that gets the quota usage before the resize,
20:23:18 mriedem and then gets the reserved quota usage after the resize,
20:23:26 mriedem before counting quotas they are going to be the same,
20:23:38 mriedem but after counting quotas they are going to be different b/c we don't reserve, right?
20:24:19 mriedem looking at this https://github.com/openstack/nova/blob/ac20980702030424ce4bb3ddf2610d31716a8bd7/nova/api/openstack/compute/used_limits.py#L65
20:24:35 melwitt well, with counting quotas we won't be touching the usages table, so neither usage nor reservation will be changed. so they should be the same (unchanged)
20:24:36 mriedem that tells the limits API whether or not to include 'reserved' quota in the response for usage
20:24:52 melwitt oh, you mean get usage as in, from the used limits API?
20:25:00 melwitt that will show you the new counted usage
20:25:01 mriedem yes
20:25:07 melwitt okay
20:25:23 mriedem so once the server is in verify_resize state, it's going to count against quota?
20:25:24 melwitt in the change it always sets reserved to show 0
20:25:31 mriedem for the new size, if i'm resizing up for example?
20:25:36 melwitt it's not pulling it from the usages table, it's just hard-coded to be 0
20:26:00 dansmith is reserved for resizing instances?
20:26:16 mriedem reserved is just the placeholder for quota usage until the operation is complete
20:26:21 melwitt it's for everything. yeah
20:26:22 mriedem usually committed or rolled back later
20:26:27 melwitt ot
20:26:29 dansmith oh I guess reserved is reservations that haven't been committted
20:26:30 dansmith gotcha
20:26:32 melwitt it's for all ReservableResource
20:26:32 mriedem like, that's why the reservations are passed from api to compute
20:26:49 mriedem yeah, so i'm trying to figure out how i should write the functional test,
20:27:02 mriedem because that's what i was goign to do, check usage before the resize, and compare to usage after the resize is in verify_resize state
20:27:24 mriedem and today they will be different if you include the reserved value in the results
20:27:41 mriedem https://developer.openstack.org/api-ref/compute/?expanded=show-a-quota-detail,show-rate-and-absolute-limits-detail#id225
20:27:46 mriedem 1
20:27:48 mriedem "Specify whether the result of resource total includes reserved resources or not."
20:29:33 melwitt well, I see that resize reservation is committed in compute after the resize request. so that happens before confirm/revert
20:29:50 melwitt so when it's in verify_resize it should have reserved == usage currently, right?
20:30:00 melwitt sorry
20:30:03 melwitt reserved will be 0
20:30:09 mriedem but in_use would be incremented
20:30:12 melwitt right
20:30:13 mriedem ok
20:30:25 mriedem so what will happen with counting quotas?
20:30:47 melwitt usage should be incremented and reserved will be 0 (reserved is hard-coded to 0 always)
20:31:27 mriedem because instance.memory_mb is taken from new_instance_type['memory_mb'] somewhere?
20:31:40 mriedem b/c the count is now taken from instance.memory_mb right?
20:31:40 melwitt lemme see ...
20:31:53 melwitt yeah, as long as the new flavor has been saved to the instance
20:32:11 melwitt I'm looking where that happens. pretty sure it's regardless of confirm/revert
20:32:47 melwitt yeah, in finish_resize() (before confirm/revert) it sets the new flavor. so at that time the new usage should be counted
20:33:04 melwitt if an instance is sitting in verify_resize it's consuming more resources (if a resize up)
20:33:48 mriedem ah Specify whether the result of resource total includes reserved resources or not.
20:33:50 mriedem oops
20:33:53 mriedem _set_instance_info
20:33:55 mriedem in the compute manager
20:34:00 melwitt yeah
20:34:29 mriedem we should probably remove this comment then :) https://github.com/openstack/nova/blob/ac20980702030424ce4bb3ddf2610d31716a8bd7/nova/compute/manager.py#L4006
20:34:36 mriedem since the quota count is goign to be completely based on these now
20:35:22 melwitt yeah, true
20:35:40 mriedem i've noted it in your change
20:35:42 mriedem ok on with the test
20:35:52 melwitt I'm trying to think how a confirm could ever fail quota check. I think it couldn't because all confirm does is remove the stuff from the source host and other cleanup. it wouldn't do anything to change the usage
20:36:18 melwitt just thinking out loud
20:36:20 mriedem that sounds right
20:36:48 mriedem so i'll get this test up and it will test the existing behavior, and then put a change on top to depend on your patch to test the new behavior
20:36:51 melwitt so just makes me wonder why it checks quota on a confirm at all right now
20:37:00 melwitt k, cool.
20:37:02 mriedem shrug
20:38:59 melwitt in a code comment says it does it only for a decrease in usage. ah, because on resize it only makes a reservation for an upsize. never for a downsize
20:39:11 melwitt so this is adjusting usage for a downsize only on confirm. guh, how confusing
20:39:38 melwitt so for our new counting stuff, we shouldn't need to check quota on confirm. only on revert
20:44:04 mriedem and only on revert when upsizing?
20:44:16 mriedem or we just won't make a distinction?
20:44:48 melwitt yeah. it could save wasted query to only do it on a revert of a downsize
20:45:08 melwitt so I think that's a good idea
21:16:16 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Add functional test for resize-confirm plus quota validation https://review.openstack.org/483559
21:31:23 mriedem https://bugs.launchpad.net/cinder/+bug/1694509
21:31:24 openstack Launchpad bug 1694509 in Cinder "eventlet errors and cannot switch to a different thread" [Undecided,Confirmed]
21:31:24 mriedem oops
21:33:26 openstackgerrit Jay Pipes proposed openstack/nova master: scheduler: isolate _get_sorted_hosts() https://review.openstack.org/483564
21:33:27 openstackgerrit Jay Pipes proposed openstack/nova master: add dict of allocation requests to select_dests() https://review.openstack.org/483565
21:33:27 openstackgerrit Jay Pipes proposed openstack/nova master: claim resources in placement API during schedule() https://review.openstack.org/483566
21:33:55 jaypipes cdent, mriedem, dansmith, edleafe, bauzas: ok, I know it's late in the day, but I got it pushed ^^
23:01:31 openstackgerrit Merged openstack/nova master: Fix wrong log parm. https://review.openstack.org/482832
23:36:33 openstackgerrit Merged openstack/nova master: Remove mox from nova.tests.unit.virt.xenapi.test_vm_utils.py https://review.openstack.org/478749
#openstack-nova - 2017-07-14
00:47:45 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Add functional test for resize-confirm plus quota validation https://review.openstack.org/483559
01:03:11 openstackgerrit zhangdaolong proposed openstack/python-novaclient master: Fix the inappropriate parameter name https://review.openstack.org/480826
01:33:37 mriedem mysql is case insensitive by default, right?
01:33:44 mriedem isn't that one of the mysql vs postgresql issues?
01:33:56 mriedem b/c https://developer.openstack.org/api-ref/compute/?expanded=add-a-single-tag-detail says "Tags are case sensitive."
01:33:59 mriedem so i'm not sure that's true
01:34:03 mriedem depending on db backend

Earlier   Later