| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-08 | |||
| 15:03:18 | mriedem | just add the packages to nova's bindep file | |
| 15:03:22 | Roamer` | ameeda, try to figure out what the bug actually is, what libpcre3-dev is and why it needs to be added | |
| 15:03:36 | mriedem | Roamer`: it's a transitive dependency, | |
| 15:03:42 | Roamer` | mriedem, I know, I fixed it for our CI | |
| 15:03:43 | mriedem | because of the new dep on the whereto package | |
| 15:03:51 | mriedem | whereto requires pcre | |
| 15:03:59 | cdent | bauzas: thanks for that. I read through and I wonder to what extent claims in the scheduler are now making a difference to the concerns? | |
| 15:04:02 | ameeda | thanks all for help, I have to go now, I will back soon. | |
| 15:06:11 | bauzas | cdent: I feel we solved the main blocker | |
| 15:06:13 | gibi | mriedem: I think it is not a big deal but we have some inconsistency here https://review.openstack.org/#/c/541008/9/nova/tests/unit/image/test_glance.py@1629 | |
| 15:06:22 | bauzas | cdent: because I was wrong in the past | |
| 15:06:35 | bauzas | cdent: the fact that we have workers doesn't mean greenlets | |
| 15:06:53 | bauzas | hence separate processes, exactly like having multiple n-sch services | |
| 15:07:21 | bauzas | so, what we solved with scheduler claims is also a valid argument for saying we can have workers | |
| 15:10:57 | cdent | I've made reference to the code and the email thread in the notes I'm writing up, so we'll have that to refer back to later if needed | |
| 15:11:12 | mriedem | gibi: i think it's probably fine, the only place we append anything to that url is in "generate_image_url" and we append /images/{id} to it | |
| 15:11:23 | mriedem | for the createImage response location header | |
| 15:11:43 | mriedem | and some notification during rebuild | |
| 15:13:17 | edleafe | bauzas: I do remember that the argument was made for claiming in the scheduler that it would allow for multiple scheduler processes | |
| 15:13:33 | mriedem | the pike release notes also say you can now run multiple schedulers b/c we do claims in the scheduler | |
| 15:13:44 | mriedem | which is why i wanted to add that test wrinkle to the nova-next job | |
| 15:13:54 | mriedem | since we have had 409 issues since pike with claims in the scheduler | |
| 15:13:57 | stephenfin | sean-k-mooney: So etcd failed to start. Lovely :) | |
| 15:14:25 | bauzas | mriedem: sure, but we don't support yet multiple workers, hence the discussion | |
| 15:14:41 | bauzas | it's just a very simple patch | |
| 15:14:48 | bauzas | but someone has to write it | |
| 15:15:04 | mriedem | bauzas: you mean this patch? https://review.openstack.org/#/c/159382/ | |
| 15:15:28 | bauzas | and again, I think I wonder what is the opportunity of having a separate process for filtering | |
| 15:15:45 | bauzas | in particular now we have cells v2 and superconductor/conductors | |
| 15:16:41 | bauzas | mriedem: yup | |
| 15:17:00 | bauzas | anyway, something to merge in Rocky :) | |
| 15:17:14 | openstackgerrit | Merged openstack/nova master: Fix 500 in test_resize_server_negative_invalid_state https://review.openstack.org/531117 | |
| 15:21:14 | openstackgerrit | Jianghua Wang proposed openstack/nova master: VGPU: Modify the example of vgpu white_list set https://review.openstack.org/539183 | |
| 15:23:16 | openstackgerrit | Merged openstack/nova master: Add index(instance_uuid, updated_at) on instance_actions table https://review.openstack.org/530429 | |
| 15:23:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: VGPU: Modify the example of vgpu white_list set https://review.openstack.org/539183 | |
| 15:24:53 | gibi | mriedem: OK, then I'm +2 | |
| 15:26:25 | jianghuaw | mriedem, thanks. | |
| 15:28:47 | sean-k-mooney | stephenfin: that is unrelated i normally trun it off as it is not need at all for a default devstack install | |
| 15:29:27 | sean-k-mooney | stephenfin: i have found the etcd installation in devstack to be kindo of flaky | |
| 15:29:34 | efried | lajoskatona: I'm going to rebase the series upon which you have https://review.openstack.org/#/c/527728/9 stacked. I'll go ahead and pull yours into the rebase unless you have objections? | |
| 15:30:10 | stephenfin | sean-k-mooney: So I had HOST_IP configured to the IP of the IF I was binding DPDK to. Think I had that wrong, tbhg | |
| 15:30:40 | sean-k-mooney | stephenfin: haha ya that could cause issues allright | |
| 15:31:16 | dansmith | mriedem: in case it's not clear I think this patch from tssurya is closer to being ready than takashi's https://review.openstack.org/#/c/541246/ | |
| 15:33:26 | sean-k-mooney | stephenfin: are you deploying on a phyicla server or a vm | |
| 15:33:35 | stephenfin | sean-k-mooney: The latter | |
| 15:33:36 | mriedem | dansmith: i think it is too | |
| 15:33:38 | stephenfin | Sorry - former | |
| 15:33:44 | stephenfin | Got a machine sat here beside me | |
| 15:36:08 | sean-k-mooney | ok this let me see if i have the vm i was doing the centos fixes on still and i can see if i can grab the local.conf. that said if you have issue with the getting started guide it would be nice to fix them too | |
| 15:37:08 | stephenfin | sean-k-mooney: Well, let's see. It's proceeding quite nicely so far | |
| 15:37:12 | stephenfin | since I fixed the HOST_IP issue | |
| 15:43:02 | lajoskatona | efried: from my side it is ok for rebasing. I just tried to put my patch for tests on top of yours to see how it goes on latest nested patches | |
| 15:43:29 | efried | lajoskatona: Okay. Should be coming up in the next 10-15 minutes. | |
| 15:44:58 | mriedem | dansmith: one of the proxy methods in https://review.openstack.org/#/c/541005/ is broken | |
| 15:45:03 | mriedem | otherwise just some questions | |
| 15:45:50 | dansmith | mriedem: ack thanks /cc stephenfin | |
| 15:49:49 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Fix wrong link for "Manage Flavors" in CPU topologies doc https://review.openstack.org/542270 | |
| 15:50:19 | stephenfin | mriedem, dansmith: Alrighty then, dumb question time 🎉 How are we able to drop the v4 proxy in the above change so early? Surely that means all our clients would have to talk 5.0 as soon as we do that? | |
| 15:50:44 | dansmith | stephenfin: we merge the 5.0 server and client in queens, | |
| 15:50:53 | dansmith | then in rocky we can drop the 4.x server proxy | |
| 15:51:02 | dansmith | stephenfin: we send 5.0 by default after that second change | |
| 15:51:21 | dansmith | which means queens supports 5.0 client side, and since we only support one gap, we can drop 4.x in rocky | |
| 15:51:40 | dansmith | stephenfin: you saw the second change in that stack right? | |
| 15:53:45 | stephenfin | dansmith: Riiight, so once people start deploying from master (future Rocky), the expectation is that _everything_ in the deployment will be on stable/queens code or newer | |
| 15:53:50 | stephenfin | Yup, I did indeed | |
| 15:54:48 | dansmith | stephenfin: them's the rules yeah | |
| 15:54:49 | stephenfin | sean-k-mooney: Success! (I think) Now to actually test it and recreate NUMA issues :) | |
| 15:55:08 | stephenfin | dansmith: Gotcha. And the 6 month rule we have for conf options doesn't apply to this? | |
| 15:55:14 | dansmith | stephenfin: no | |
| 15:55:20 | dansmith | stephenfin: (no it does not) | |
| 15:55:43 | stephenfin | 👍 | |
| 15:56:38 | dansmith | I'm assuming you mean the 6-mo deprecation warning period.. this is per release, and nothing is being deprecated.. we only support one version back technically anyway, so this is just us officially dropping stuff that has technically been deprecated for a long time | |
| 15:56:46 | dansmith | (and this is the pattern we do every time we bump) | |
| 15:58:29 | stephenfin | dansmith: Yup, that's the one. Thanks for the context | |
| 15:58:55 | stephenfin | dansmith: and a last one: this is a different RPC API with it's own unique version, right? https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L51 | |
| 15:59:03 | dansmith | aye | |
| 16:00:05 | stephenfin | Lovely. So now I need to go figure out _which_ other RPC API needs to be bumped to v5 to remove all that code I linked. Fun times :) | |
| 16:01:32 | openstackgerrit | Merged openstack/nova master: Fixed auto-convergence option name in doc https://review.openstack.org/542237 | |
| 16:01:40 | dansmith | given you linked to stuff in virt, really it should only be compute rpc | |
| 16:01:53 | dansmith | if not, we're leaking details (which is possible I guess) | |
| 16:05:12 | mriedem | dansmith: did you want to +W this backport https://review.openstack.org/#/c/539005/ ? | |
| 16:08:34 | hrw | mriedem: thanks for accepting my pike backport | |
| 16:09:11 | mriedem | yw | |
| 16:09:40 | stephenfin | dansmith: [1] is my main concern. Assuming RequestSpec objects are used by the scheduler, we'll need to bump that version too to remove the called function [1] https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L140 | |
| 16:09:43 | hrw | mriedem, stephenfin: can you find a few minutes for https://review.openstack.org/#/c/541728/ one? support matrix for aarch64 patch | |
| 16:09:56 | stephenfin | hrw: I can probably squeeze it in | |
| 16:10:01 | hrw | thx | |
| 16:10:16 | hrw | trying to get my nova queue cleaned | |
| 16:11:09 | stephenfin | dansmith: More specifically, that calls into one of those offending functions here https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L177-L178 | |
| 16:11:34 | dansmith | stephenfin: I'm not sure why that's a problem, but I can't really concentrate while on this call so I'll look when I'm done | |
| 16:11:46 | mriedem | hrw: left a comment in doc/source/user/feature-matrix-gp.ini but i don't really understand what the values are supposed to mean in that doc | |
| 16:11:52 | mriedem | if 'missing' means CI or functionality | |
| 16:11:57 | mriedem | johnthetubaguy might know | |
| 16:12:07 | mriedem | it was part of the feature classification work that osic was doing | |
| 16:12:24 | hrw | mriedem: functionality rather. there are other column without CI stuff | |
| 16:12:43 | mriedem | hrw: you can't create/delete a server with aarch64? | |
| 16:13:19 | stephenfin | mriedem: Looking at line 76, it would seem we should be using partial, not missing | |
| 16:13:33 | hrw | mriedem: docs part is weird. | |
| 16:13:34 | stephenfin | Assuming you _can_ create a server, heh | |
| 16:14:01 | hrw | mriedem: functionality list depends on tempest tests. and in tempest output I did not found ones referred there | |