| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 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 | |
| 01:34:24 | melwitt | mysql is case insensitive by default | |
| 01:34:33 | mriedem | yeah, so i guess that's a bogus statement | |
| 01:34:47 | mriedem | FOO and foo would end up the same | |
| 01:35:30 | melwitt | if there's any python caching in between that could be a case sensitive issue | |
| 01:36:28 | melwitt | I know that flavor names are case sensitive for that reason | |
| 01:36:55 | melwitt | request caching in the API by flavor ID | |
| 01:36:55 | mriedem | i'm not following | |
| 01:37:01 | mriedem | oh that | |
| 01:37:17 | mriedem | yeah that's also this bug https://review.openstack.org/#/c/467772/ | |
| 01:37:40 | melwitt | yeah. a long time ago someone tried lowercasing flavor IDs before sending to the REST API and it broke people that had mixed case flavor IDs bc things weren't found in the cache that way | |
| 01:37:58 | melwitt | *lowercasing in novaclient | |
| 01:38:05 | mriedem | so if i set a tag of FOO on my server, and then check if FOO exists, it won't because the db says it's foo? | |
| 01:38:29 | melwitt | no that should match | |