| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-06 | |||
| 20:46:22 | mriedem | melwitt: https://review.openstack.org/#/c/565886/10/nova/tests/functional/test_nova_manage.py | |
| 20:46:52 | melwitt | ty | |
| 20:47:20 | melwitt | let's see where I'm going wrong here | |
| 21:00:59 | openstackgerrit | Merged openstack/nova master: Remove support for /os-fping REST API https://review.openstack.org/567682 | |
| 21:01:05 | openstackgerrit | Merged openstack/nova master: Add contributor docs on deprecating and removing compute REST APIs https://review.openstack.org/567687 | |
| 21:14:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove support for /os-virtual-interfaces REST API https://review.openstack.org/569923 | |
| 21:19:16 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949 | |
| 21:19:17 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Plumb trusted_certs through libvirt driver image paths https://review.openstack.org/561262 | |
| 21:19:18 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 21:19:19 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269 | |
| 21:19:20 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158 | |
| 21:32:03 | mriedem | melwitt: not sure if anyone talked to you about this yet, but https://review.openstack.org/#/c/572583/ is likely going to be a major priority to get done in rocky since nested provider stuff is going to be held up on us handling the data migration properly | |
| 21:32:51 | mriedem | i think we might want to have a call or something to go over relative priorities for things we really need to get done in the 3rd milestone, because i have a feeling there are a few things floating around | |
| 21:33:05 | mriedem | this and handling a down cell are the 2 main ones i'm thinking of | |
| 21:33:54 | melwitt | I'm aware of the importance of the data migration stuff, for whatever reason I didn't realize the "reshape" spec was about that | |
| 21:34:29 | melwitt | yeah, sounds cool to me | |
| 21:35:03 | mriedem | i ignored the whole nrp upgrade thread in the ML, just jumped on the call yesterday that led to the spec | |
| 21:35:55 | mriedem | tl;dr there will be a new placement api to atomically change the inventory and allocations for a given set of providers/consumers, which we'll run on start of a compute when upgrading to rocky, and we'll also have an offline hook to do that also for FFU | |
| 21:36:37 | melwitt | right. I wasn't around in time for the call but I read through the etherpad afterward | |
| 21:41:22 | melwitt | my multi-cell func test fail is related to booting with a server group. boot without a group works fine. argh. | |
| 21:42:05 | melwitt | mriedem: a call sounds cool. are you thinking sometime tomorrow morning? since tomorrow is spec freeze | |
| 21:42:28 | mriedem | umm | |
| 21:42:38 | mriedem | maybe | |
| 21:42:51 | mriedem | i haven't gone through efried's spec in detail yet, and need to go through surya's latest revision | |
| 21:43:33 | mriedem | friday at least | |
| 21:43:38 | mriedem | once the spec freeze dust settles | |
| 21:43:44 | mriedem | and i'd consider these spec freeze exception candidates | |
| 21:43:52 | melwitt | okay, that's what I was about to ask | |
| 21:44:11 | melwitt | if we needed to do all the things by EOD tomorrow or if we have some time as exceptions | |
| 21:44:25 | mriedem | we can always make exceptions | |
| 21:45:18 | melwitt | alright | |
| 21:45:49 | dansmith | mriedem: reading the docs for the other weights we have makes me realize we have some that accept negative values | |
| 21:46:14 | dansmith | so maybe I should make the default -BIGNUMBER and require them to use negative values to properly weigh failures | |
| 21:46:15 | artom | mriedem, drive by review on https://review.openstack.org/#/c/572790/, will go to sleep soon (travelling back to my time zone) | |
| 21:46:25 | dansmith | I thought they were all zero/positive | |
| 21:46:37 | mriedem | dansmith: i know there was an iops one that i saw | |
| 21:46:41 | mriedem | that was the only one i saw i guess | |
| 21:47:49 | dansmith | mriedem: well, what do you think? | |
| 21:48:02 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 21:48:03 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269 | |
| 21:48:04 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158 | |
| 21:48:26 | openstackgerrit | Merged openstack/nova master: Trivial: let internal use only func has _ prefix https://review.openstack.org/572304 | |
| 21:50:19 | mriedem | sorry i got artom'ed | |
| 21:50:41 | artom | im in ur patch, artoming ur patch | |
| 21:50:42 | dansmith | ouch | |
| 21:50:54 | mriedem | dansmith: if negative makes more sense then that's fine by me | |
| 21:51:00 | melwitt | dansmith: if none of the other weighers auto-negate things, I would think it's more intuitive if it's specified as a negative number. with the thinking that if the normal pattern is "bigger numbers win" then specifying a larger negative number means weight a failure as far less likely to be selected | |
| 21:51:01 | mriedem | honestly the weight multipliers break my head | |
| 21:51:14 | dansmith | well, I dunno | |
| 21:51:14 | melwitt | am I thinking about that right? | |
| 21:51:32 | dansmith | melwitt: the way I think of all our weighers, the bigger the number, the more significance it has | |
| 21:51:43 | melwitt | I'd want to pick something that fits in best with what's there so that people who already use it don't have to reverse their thinking for that one option | |
| 21:51:50 | dansmith | however, there area few where you may want affinity or the opposite, so you can do negative or positive | |
| 21:51:52 | melwitt | *already use weights | |
| 21:52:00 | dansmith | you likely never want to prefer hosts that suck, | |
| 21:52:19 | dansmith | so I dunno that it would ever be positive (if we didn't auto-negate) | |
| 21:52:32 | mriedem | https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L428 is the one i noticed | |
| 21:52:44 | mriedem | oh and this https://github.com/openstack/nova/blob/master/nova/conf/scheduler.py#L737 | |
| 21:52:49 | mriedem | weight_of_unavailable... | |
| 21:53:25 | dansmith | that's a bit different | |
| 21:54:02 | dansmith | and the iops one can be positive or negative with useful meaning | |
| 21:54:10 | melwitt | do the other negative ones ever make sense as positive values? k | |
| 21:54:52 | dansmith | yes, ops defaults negative, but changing it to positive means something useful | |
| 21:55:07 | dansmith | soft_anti_affinity and soft_affinity are both positive, but have opposite meanings | |
| 21:55:38 | dansmith | https://github.com/openstack/nova/blob/master/nova/scheduler/weights/affinity.py#L93-L96 | |
| 21:55:39 | melwitt | so if it auto negates ... to make build fails even less likely to schedule toward, you would increase the positive value. that is, make build failures heavier | |
| 21:55:42 | dansmith | Just like I do ^ | |
| 21:56:19 | dansmith | melwitt: right, if it auto-negates (as it does now) then you raise the number to make build failures more significant (i.e. less likely to be chosen) | |
| 21:56:31 | dansmith | I think that anti-affinity one is my proof that I'm okay | |
| 21:56:33 | melwitt | yeah, that makes sense to me | |
| 21:56:45 | dansmith | it auto-negates because it makes more sense to have a positive value for significance | |
| 21:56:55 | melwitt | yeah it's like a coefficient I guess | |
| 21:57:10 | mriedem | i left a question in there, but should we put a min value on the multiplier? | |
| 21:57:14 | melwitt | I think either way is find, both make sense in their own way | |
| 21:57:17 | mriedem | otherwise anything negative weighs failed hosts higher right? | |
| 21:57:19 | melwitt | *fine | |
| 21:57:45 | dansmith | mriedem: I dunno, if somene wanted to actually select recent fails, they could set it to -BIG, which ... maybe? | |
| 21:57:50 | dansmith | if they do auto-disable on their own, | |
| 21:57:59 | dansmith | they may want recently-fixed hosts to be super important or something? | |
| 21:58:00 | mriedem | via notifications or something | |
| 21:58:04 | melwitt | although allowing negative and positive values could make you favor build failures if you mess up, so maybe that is worse | |
| 21:58:10 | dansmith | I wouldn't document that, but if you remove the ability, then they can't | |
| 21:58:19 | mriedem | sure | |
| 21:58:24 | mriedem | anywho | |
| 21:58:24 | dansmith | melwitt: right but if you do ^ then maybe you want that | |
| 21:58:41 | mriedem | watcher could have it's own super awesome auto-disabler | |
| 21:58:43 | dansmith | I think I'm going to leave it as-is, I convinced myself with the anti-affinity precedent | |
| 21:59:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Block swap volume on volumes with >1 rw attachment https://review.openstack.org/572790 | |
| 22:01:28 | openstackgerrit | Dan Smith proposed openstack/nova master: Change consecutive build failure limit to a weigher https://review.openstack.org/572195 | |
| 22:14:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Block swap volume on volumes with >1 rw attachment https://review.openstack.org/572790 | |
| 22:15:58 | dansmith | mriedem: oh, those were all in default previously I guess? we should update that doc | |
| 22:17:47 | mriedem | i'm sure they are old yeah | |
| 22:17:52 | mriedem | but we can cleanup the rest in a follow up | |
| 22:17:57 | mriedem | they likely have a rename alias | |
| 22:18:19 | dansmith | yeah they do | |
| 22:18:28 | dansmith | I didn't even process that as the config section, | |
| 22:18:37 | dansmith | I just copied a block and changed the names | |
| 22:19:12 | openstackgerrit | Dan Smith proposed openstack/nova master: Change consecutive build failure limit to a weigher https://review.openstack.org/572195 | |
| 22:25:49 | mriedem | in trumps america, i process it for you | |
| 22:26:20 | mriedem | i think i'll just fast approve given sylvain was +2 | |