Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-06
19:46:01 mriedem because i'm ready to push my fix
19:46:16 mriedem nvm https://bugs.launchpad.net/nova/+bug/1775418
19:46:18 openstack Launchpad bug 1775418 in OpenStack Compute (nova) "Swap volume of multiattached volume will corrupt data" [Undecided,New]
19:52:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Block swap volume on volumes with >1 rw attachment https://review.openstack.org/572790
19:55:54 openstackgerrit Merged openstack/nova master: Add granular policy rules for traits in placement https://review.openstack.org/570625
19:57:35 openstackgerrit Matt Riedemann proposed openstack/nova master: Block swap volume on volumes with >1 rw attachment https://review.openstack.org/572790
20:29:04 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Handling a down cell https://review.openstack.org/557369
20:32:16 openstackgerrit Brianna Poulos proposed openstack/nova master: Plumb trusted_certs through libvirt driver image paths https://review.openstack.org/561262
20:32:17 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
20:32:18 openstackgerrit Brianna Poulos proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269
20:32:19 openstackgerrit Brianna Poulos proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158
20:32:20 openstackgerrit Merged openstack/nova master: Add nova-manage placement heal_allocations CLI https://review.openstack.org/565886
20:44:48 openstackgerrit Brianna Poulos proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
20:44:49 openstackgerrit Brianna Poulos proposed openstack/nova master: Plumb trusted_certs through libvirt driver image paths https://review.openstack.org/561262
20:44:50 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
20:44:51 openstackgerrit Brianna Poulos proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269
20:44:52 openstackgerrit Brianna Poulos proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158
20:45:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove support for /os-virtual-interfaces REST API https://review.openstack.org/569923
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 melwitt am I thinking about that right?
21:51:14 dansmith well, I dunno
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

Earlier   Later