| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-13 | |||
| 18:32:30 | dansmith | if we round to 20% less (code to merge) we could all take tomorrow off | |
| 18:32:44 | melwitt | haha | |
| 18:36:37 | mriedem | i have to work on my pbc tomorrow | |
| 18:36:38 | mriedem | so no dice | |
| 18:39:09 | dansmith | mriedem: oh horrors of horror | |
| 18:39:20 | dansmith | er, horror of horrors? | |
| 18:39:27 | dansmith | whatever. horror-ible. | |
| 18:39:33 | mriedem | ha | |
| 18:39:44 | mriedem | don't make me get out ralph wiggum again | |
| 18:39:48 | dansmith | hehe | |
| 18:40:32 | melwitt | what's pbc | |
| 18:40:45 | mriedem | personal business commitments | |
| 18:41:06 | mriedem | goals | |
| 18:41:28 | mriedem | like, "i'm going to synergize for cloud enterprise adoption 2.0" | |
| 18:42:15 | melwitt | hah | |
| 18:44:30 | edleafe | mriedem: don't forget the cover page for the TPS report | |
| 18:44:36 | edleafe | mriedem: you did get the memo, right? | |
| 18:44:54 | jaypipes | mriedem: don't forget to unprison your think rhino. | |
| 18:44:59 | mriedem | i did put a cover page on my expense claim and throw that in the mail today | |
| 18:45:57 | openstackgerrit | zhang zhenzhong proposed openstack/nova master: fix rp registration failed while placement endpoint created after compute start https://review.openstack.org/483460 | |
| 18:46:28 | melwitt | lol think rhino? unprison? | |
| 18:46:29 | cdent | jaypipes: you may have some opinions on that ^^ | |
| 18:50:48 | jaypipes | melwitt: https://twitter.com/e_monty/status/852540106317627392 | |
| 18:51:22 | melwitt | lol | |
| 18:51:28 | edleafe | jaypipes: ah, that totally clears everything up | |
| 18:51:35 | jaypipes | hehe | |
| 18:53:43 | openstackgerrit | zhang zhenzhong proposed openstack/nova master: remove un-necessary update() in _init_compute_node of rt https://review.openstack.org/483506 | |
| 19:04:37 | dansmith | mriedem: this event rebase is taking a long time because of your silly volume extend nonsense, but I'm about done | |
| 19:04:56 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix and optimize external_events for multiple cells https://review.openstack.org/445142 | |
| 19:07:06 | mriedem | boohoo | |
| 19:07:19 | melwitt | hehehe | |
| 19:08:57 | dansmith | mriedem: you guys are only on cloud 2.0? | |
| 19:09:23 | dansmith | I think we're on 4.0 now | |
| 19:25:58 | melwitt | comcast is here to replace a line outside so I might drop off while they're working | |
| 19:27:57 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Microversion 2.50 - fix quota class sets resource usage https://review.openstack.org/483060 | |
| 19:27:58 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: Add support for the 2.51 microversion https://review.openstack.org/483149 | |
| 19:35:24 | mriedem | dansmith: melwitt: so we talked about some testing we can do against the quotas change, | |
| 19:35:35 | mriedem | novaclient functional runs in serial with a single tenant | |
| 19:35:52 | mriedem | normal tempest jobs are a unique tenant per test so if we're leaking quotas we won't find it in the normal runs | |
| 19:36:04 | mriedem | so i was thinking about doing something in novaclient as a DNM change and point it at the quotas patch | |
| 19:36:08 | mriedem | like run something 20 times | |
| 19:36:16 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/483337 | |
| 19:36:38 | mriedem | thoughts on what we'd want to cover there? i think normal server create/delete is already covered by the existing novaclient functional tests | |
| 19:36:52 | mriedem | so was thinking about adding a novaclient functional test for resize that we could then run like 20 times in a loop | |
| 19:37:15 | mriedem | *we talked about this in the nova meeting i mean | |
| 19:38:05 | mriedem | thoughts on what to test there? like resize up/confirm, resize down/confirm * 20, and resize up/revert, resize down/revert * 20 | |
| 19:41:00 | melwitt | soft delete/restore | |
| 19:41:12 | mriedem | ok | |
| 19:41:40 | melwitt | multi create | |
| 19:42:06 | mriedem | hmm, actually, i suppose this is why tempest doesn't test soft delete, | |
| 19:42:15 | mriedem | is that the soft delete behavior is based on config... | |
| 19:42:21 | mriedem | and by default it doesn't soft delete | |
| 19:42:28 | melwitt | yeah | |
| 19:42:36 | mriedem | so would have to test that one manually | |
| 19:58:19 | openstackgerrit | Jackie Truong proposed openstack/nova master: [WIP] Implement certificate_utils https://review.openstack.org/479949 | |
| 20:05:07 | openstackgerrit | Jackie Truong proposed openstack/nova master: [WIP] Add trusted certificates to InstanceExtras https://review.openstack.org/457711 | |
| 20:08:59 | dansmith | mriedem: do you recall anyone saying they actually use soft delete? | |
| 20:09:46 | mriedem | dansmith: no | |
| 20:10:13 | dansmith | given it's not user-visible (control anyway) we might want to seriously consider yanking it out, IMHO | |
| 20:10:28 | cburgess | dansmith: +1 | |
| 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 | |