| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 20:12:39 | cburgess | dansmith Yeah we have been trying to get the data team to do something with it... mixed results. | |
| 20:12:43 | mriedem | select * from instance_actions where action == 'shelve' | |
| 20:13:12 | cburgess | mriedem I don't think instance_action is enough for all the stuff product has in mind. You have to look at args at times to figure out whats being done in the call. For instannce boot from volume etc. | |
| 20:13:26 | dansmith | for client versions it does nothing | |
| 20:13:43 | melwitt | notifications would be a good way to mine | |
| 20:13:46 | cburgess | Type of security groups rules (nested vs not) etc. | |
| 20:13:52 | cburgess | melwitt yeah true... | |
| 20:13:57 | mriedem | i'm just looking at basic things right now | |
| 20:14:10 | cburgess | mriedem Fair enough... | |
| 20:14:10 | mriedem | "of all instance actions in this cloud, what % is shelve?" | |
| 20:14:33 | mriedem | basically first iteration is a report of the count of instance actions in a cloud | |
| 20:14:41 | mriedem | which is pretty simple | |
| 20:14:41 | dansmith | hmm, not sure what use that is unless you're comparing to another | |
| 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 | melwitt | yeah | |
| 20:17:20 | mriedem | but, | |
| 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 | 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 | |