| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 20:10:32 | mriedem | i'm asking in ops | |
| 20:10:36 | mriedem | so will get back to you in 3 days | |
| 20:10:37 | dansmith | maybe do some targeted data gathering on the idea | |
| 20:10:39 | cburgess | dansmith Its mostly useless in its current form. | |
| 20:10:39 | dansmith | hah | |
| 20:10:53 | dansmith | cburgess: agreed, and it's constantly broken, untested, etc | |
| 20:10:59 | mriedem | sdague and i have kicked around ideas on data mining api usage | |
| 20:11:11 | mriedem | b/c we've asked this about shelve too | |
| 20:11:20 | mriedem | this would also be a good user survey question | |
| 20:11:23 | cburgess | mriedem Our product team keeps asking for that. So maybe its something of value to add in optionally for people to turn on/off | |
| 20:11:28 | dansmith | I know people that use shelve | |
| 20:11:35 | cburgess | dansmith I'm sorry | |
| 20:11:35 | mriedem | cburgess: keeps asking for what? | |
| 20:11:49 | mriedem | cburgess: api usage data mining? | |
| 20:11:52 | cburgess | mriedem Our product team wants to be able to data mine the API calls to figure out which clients use which features etc. | |
| 20:11:56 | mriedem | ah | |
| 20:12:03 | mriedem | yeah, i don't think we'd need to turn it on/off, | |
| 20:12:05 | mriedem | it'd be nova-manage | |
| 20:12:08 | mriedem | mine the instance actions table | |
| 20:12:13 | dansmith | cburgess: that's a script of processing the log right? | |
| 20:12:15 | mriedem | pretty simple actually | |
| 20:12:24 | mriedem | this data is all in instance actions already | |
| 20:12:24 | cburgess | Which one can do by scraping the logs but.. they want want something a bit more sophsiticated | |
| 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 | |