Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-13
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
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

Earlier   Later