Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-19
15:41:46 mriedem we can see that the host model in the capabilities is <model>POWER8</model>
15:45:20 lei-zh1 but I still need to handle the conf you mentioned, suppose it's a valid case, I should make a guess and set the model to power8, right?
15:45:25 mriedem i mean, we could hack something in here like, if cpu_mode='none' and arch == ppc64le, use cpu_mode='host-model' and cpu_model='power8' but it would be blatantly ignoring what's in nova.conf
15:48:20 mriedem lei-zh1: i left a couple of comments
15:48:30 mriedem you might just need to change 2 things:
15:48:37 mriedem if cpu.mode is None or cpu.mode == 'none'
15:48:47 mriedem 2. if arch == ppc64le: mode = 'power8'
15:50:47 mriedem efried: i think https://review.openstack.org/#/c/564440/ was originally part of https://review.openstack.org/#/c/564452/ and then split out
15:51:32 efried mriedem: It was originally like really early in the series and then moved up, but I don't think it was moved far enough to make dansmith happy.
15:51:47 mriedem > This is now at the end of the series. I've kept it separate from the "populate the thing" patch but that's to keep this readable. I can combine them if you don't mind the larger diff
15:51:55 efried mriedem: His original complaint - that we have dead conf options that say they do a thing they don't do - would still apply.
15:51:57 mriedem that's an old comment from stephenfin now too
15:52:06 efried mriedem: Yeah, I saw that, but it's not actually at the end of the series.
15:52:12 mriedem right
15:52:18 efried mriedem: Rule of thumb, I would think, is that the conf options ought to be in the same patch as the reno3
15:52:23 efried s/3/./
15:52:50 stephenfin efried: I can squash it with the following patch but https://review.openstack.org/#/c/564441/ is already quite beefy
15:53:00 mriedem so,
15:53:06 stephenfin Sorry, https://review.openstack.org/#/c/564452
15:53:07 mriedem the other thing we can do, and we've done before,
15:53:18 mriedem is we don't approve the bottom thing until we've got +2s lined up on the thing to use it
15:53:36 efried yeah, that would be fine by me.
15:53:43 mriedem let's WIP the bottom thing then
15:54:04 mriedem done
15:54:20 mriedem i was just pulling this up coincidentally
15:54:34 efried I mean, I really don't feel it matters if we have a situation like this where conf options exist but don't work for a couple commits on the master branch during active development.
15:54:45 efried As long as we make sure we don't hit a release boundary with it.
15:54:48 mriedem right
15:54:53 mriedem and with 1 week to FF, it's risky
15:55:01 mriedem i'll review the rest of the series now
15:55:04 mriedem been meaning to anyway
15:56:23 lei-zh1 mriedem, please see my comments in the patch
16:02:20 mriedem gibi: i threw an idea in https://review.openstack.org/#/c/583347/ as an alternative for unsetting the spec_obj.instance_uuid while filtering hosts to get alternates, see what you think
16:02:43 mriedem either is a hack, but the alternative i just said might be a less impactful hack to any out of tree filters that rely on spec_obj.instance_uuid
16:05:28 gibi mriedem: those filters that rely on spec_obj.instance_uuid has the same issue as the anti-affinity one for multicreate alternates, that spec_obj.instance_uuid is actually invalid for the alternate scheduling. So I think the current patch fixes their issue as well
16:06:18 mriedem gibi: well, anything will explode in that path if it tries to access an unset spec_obj.instance_uuid
16:06:27 mriedem since we don't lazy-load that field in the RequestSpec object
16:06:46 mriedem i agree that filters shouldn't rely on that field *because* of multi-create
16:07:19 mriedem alternatively - to the alternative - we could temporarily set a sentinel uuid
16:07:29 mriedem which will be something that's never in the host_state.instances
16:07:32 gibi mriedem: ahh you are corret the current change doesn't make out of tree filters automatically better. Then you suggestion is as good as the current patch for me
16:08:40 mriedem if you have out of tree filters then all bets are off anyway, but it is admittedly weird to have a request spec w/o an instance_uuid field set
16:11:33 gibi the sentinel way could work and I agree that it is nicer than the unset field we just needs to adjust some logging not to log the sentinel as that is misleading
16:19:46 mriedem melwitt: appears we have a test that needs to be skipped for lvm http://logs.openstack.org/70/434870/37/check/nova-lvm/a7cce3d/logs/screen-n-cpu.txt.gz?level=TRACE#_Jul_19_14_40_50_480759
16:22:23 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use placement 1.28 in scheduler report client https://review.openstack.org/583667
16:22:56 openstackgerrit Matt Riedemann proposed openstack/nova master: Skip test_resize_server_revert_with_volume_attached in nova-lvm https://review.openstack.org/584018
16:22:58 mriedem melwitt et al ^
16:43:15 mriedem stephenfin: a couple of things in here https://review.openstack.org/#/c/564441/
16:47:03 stephenfin mriedem: looking
16:54:23 stephenfin mriedem: Comments left on all those. Will address once I learn what silly things I've done in the other patches that need fixing :)
16:57:52 mriedem i see your comments and raise you 2
16:59:01 mriedem i think i answered one of my own questions
17:17:28 openstackgerrit Graham Hayes proposed openstack/nova master: Do not install zVMCloudConnector in poy36 https://review.openstack.org/584031
17:28:01 openstackgerrit Artom Lifshitz proposed openstack/nova master: DNM: extra logging for 1775947 https://review.openstack.org/584032
17:38:58 efried mriedem: Wherezat bug / pull request y'all opened yesterday for the zvm lib supporting py36?
17:40:29 efried mriedem: nm, found it.
18:08:44 openstackgerrit Lei Zhang proposed openstack/nova master: Add method to get cpu traits https://review.openstack.org/560317
18:22:52 mriedem stub_out is failing me and i don't know why
18:25:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Do not install zVMCloudConnector in py36 https://review.openstack.org/584031
18:29:14 mriedem oh wow, well, figured it out
18:30:29 efried is mugsie Graham Hayes? Never knew that guy had a real name.
18:30:43 mriedem yup
18:30:57 mriedem i've actually *seen* him in person
18:30:58 mriedem believe it or not
18:31:10 efried Oh, yeah, I've seen him any number of times. Just didn't realize he had a name.
18:31:16 mriedem "that dns guy"
18:31:48 efried Been trying to get the mugsie/penick cage match going.
18:32:35 mriedem battle royale
18:43:34 efried Remind me what are the rules for what releases a conductor and its computes can be at?
18:43:52 mriedem computes n-1
18:44:44 mriedem the control plane can tolerate n-1 computes for rolling upgrades
18:45:04 efried and GET /allocation_candidates happens on... the controller?
18:45:09 mriedem yeah, scheduler
18:45:24 mriedem controller = api, conductor, scheduler
18:45:50 efried Trying to figure out why this allocation_request_version thing exists
18:46:40 efried Sounds like its purpose is to allow us to "cheat" and use a higher microversion on the n-1 compute than that codebase actually knows about.
18:47:02 mriedem correct
18:47:05 mriedem well, not the compute,
18:47:07 mriedem the cell conductor
18:47:24 efried um
18:47:29 efried because the cell conductor can be n-1 as well?
18:48:02 mriedem api->superconductor->scheduler (get allocation candidates and get alternate hosts from those allocatoin requests at the given microversion used in the scheduler)->pass down to compute to build; fails and reschedule to cell conductor which uses the allocation request, created in the scheduler, to claim resources against the alternate host in placement
18:48:41 efried And the cell conductor can be downlevel from the superconductor?
18:48:44 mriedem long-term i think we want to be able to do rolling upgrades of the cells themselves so yes cell conductor could be n-
18:48:45 mriedem *n-1
18:49:01 mriedem it's been a long time since i've talked about rolling upgrades for cells with dansmith
18:49:41 mriedem gibi: good news - the delattr stuff for getting alternate hosts was a bugaboo so i'm removing all that code and added a wrinkle to the functional test to assert there are no alternate hosts when this bug is fixed
18:50:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Add regression test for bug 1781710 https://review.openstack.org/583339
18:50:33 openstack bug 1781710 in OpenStack Compute (nova) "ServersOnMultiNodesTest.test_create_server_with_scheduler_hint_group_anti_affinity failing with "Servers are on the same host"" [High,Fix released] https://launchpad.net/bugs/1781710 - Assigned to Matt Riedemann (mriedem)
18:50:34 openstackgerrit Matt Riedemann proposed openstack/nova master: Update RequestSpec.instance_uuid during scheduling https://review.openstack.org/583347
18:50:36 mriedem melwitt: jaypipes: ^ should be better now
18:51:12 mriedem tl;dr the change is now just make sure and set the in-context correct instance_uuid on the RequestSpec before calling the filters
18:54:15 efried Because of da new rulez, if the conductor is running N, the version of placement that all of its cell conductors and computes will be dealing with is at least the minumum for N, not the minimum for N-1, right?
18:54:56 efried guess the rules aren't new
18:57:02 mriedem new rules being we don't do version negotiation for placement?
18:57:24 mriedem that doesn't apply if the code is on an N-1 service and it thinks the minimum required version is whatever it was for N-1
18:57:57 mriedem i mean, that's kind of the point of why we send the allocation candidate request version down to the cell,
18:58:19 mriedem because if it's downlevel, and the request body format changed, we need to tell the cell exactly what version to make that request with that particular body
18:58:32 mriedem it's like gd time travel
18:58:53 mriedem efried: do you want to continue talking about this or want me to review https://review.openstack.org/#/c/556669/ ?

Earlier   Later