| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 20:13:57 | mriedem | i'm just looking at basic things right now | |
| 20:14:10 | mriedem | "of all instance actions in this cloud, what % is shelve?" | |
| 20:14:10 | cburgess | mriedem Fair enough... | |
| 20:14:33 | mriedem | basically first iteration is a report of the count of instance actions in a cloud | |
| 20:14:41 | dansmith | hmm, not sure what use that is unless you're comparing to another | |
| 20:14:41 | mriedem | which is pretty simple | |
| 20:15:09 | mriedem | ? | |
| 20:15:21 | mriedem | if we know there are 100 instance actions in the db, and 5 are shelve, then we know 5% is shelve | |
| 20:15:24 | dansmith | on an active cloud, 10% shelve would be huge. on a static "we just moved our workloads to cloud", 10% wouldn't mean as much | |
| 20:15:38 | mriedem | yeah, again, baby steps | |
| 20:15:58 | mriedem | you have to be able to mine the data in a single install, and then start aggregating that probably in the user survey, or some other tool, idk | |
| 20:16:11 | mriedem | based on the size of the cloud, which is probably based on # of vms and/or # of computes | |
| 20:16:13 | dansmith | that's what I'm saying, it only really means something in comparison | |
| 20:16:32 | mriedem | if i'm asking a binary yes/no question, | |
| 20:16:33 | mriedem | it means something | |
| 20:16:43 | mriedem | ala user survey, does your cloud use shelve | |
| 20:16:46 | mriedem | or, | |
| 20:16:49 | mriedem | do users of your cloud use shelve | |
| 20:16:50 | mriedem | yes/no | |
| 20:17:06 | melwitt | I think the user survey is out right now | |
| 20:17:14 | mriedem | yeah this would be 2018 at this point | |
| 20:17:18 | mriedem | for the user survey | |
| 20:17:20 | mriedem | but, | |
| 20:17:20 | melwitt | yeah | |
| 20:17:21 | dansmith | mriedem: but you don't want someone with one shelve ever to answer yes | |
| 20:17:40 | dansmith | anyway, not arguing with data of course, I'm just not sure what I'd make of "10% shelve" as an answer | |
| 20:17:41 | mriedem | if we provided a thing in nova-manage, we could also ask people to run that in the ops list and report back their findings | |
| 20:17:42 | melwitt | do you use shelve A Lot(tm)? | |
| 20:17:48 | mriedem | which is skewed i know, but so is the user survey | |
| 20:18:04 | dansmith | I mostly care about "would you freak if we removed feature X?" | |
| 20:18:17 | mriedem | yes you'd have to account for outliers like 1 usage of 1000 | |
| 20:18:25 | mriedem | gdi you bastards | |
| 20:18:29 | mriedem | i'm going home | |
| 20:18:31 | melwitt | lol | |
| 20:19:00 | mriedem | getting something like this fed into the interop wg could also be a possibility | |
| 20:19:08 | mriedem | as they are feeding their interop results in there regularly | |
| 20:19:16 | dansmith | 1/1000 is probably a typo, 10/10000 is probably one user that loves shelve | |
| 20:19:16 | mriedem | but, | |
| 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 | mriedem | like, that's why the reservations are passed from api to compute | |
| 20:26:32 | melwitt | it's for all ReservableResource | |
| 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 | melwitt | lemme see ... | |
| 20:31:40 | mriedem | b/c the count is now taken from instance.memory_mb right? | |
| 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 | |