| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 15:18:43 | gibi | stephenfin: now queued them for review | |
| 15:19:08 | stephenfin | I've been skimming through novaclient commands, mapping them to OSC equivalents, and figuring out what's missing. I'm getting very close to feature parity with those and know where the remaining gaps are | |
| 15:19:12 | stephenfin | gibi: \o/ thanks! | |
| 15:19:21 | bauzas | stephenfin: opened the link but later, I'm sorry | |
| 15:19:42 | stephenfin | Later is good. This is low priority. I just want it to move _eventually_ :) | |
| 15:19:55 | bauzas | stephenfin: ping me tomorrow morning then | |
| 15:20:11 | lyarwood | stephenfin: ack open, I'll start looking through them now | |
| 15:23:03 | gibi | stephenfin: there is a probable mitigation for the long standing bug 1823251 https://review.opendev.org/c/openstack/nova/+/765300 | |
| 15:23:03 | openstack | bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed] https://launchpad.net/bugs/1823251 | |
| 15:23:28 | stephenfin | gibi: looking | |
| 15:23:35 | gibi | so far I was not able to reproduce the bug with this patch in 10 CI runs | |
| 15:25:09 | bauzas | sean-k-mooney: I mean, my concern is to know whether we can know that if we get an empty list of aggregates, it's either fine or not | |
| 15:27:24 | sean-k-mooney | https://github.com/openstack/neutron/blob/a9fc746249cd34cb7cc594c0b4d74d8ddf65bd46/neutron/tests/unit/extensions/test_segment.py#L341-L351 | |
| 15:27:42 | sean-k-mooney | so it will be a list of segments i think but it will be empty still checking | |
| 15:31:44 | sean-k-mooney | gibi i hit that bug too | |
| 15:32:21 | gibi | sean-k-mooney: all of us hit that during the past one and a half year, we turned that test off during FF many times in the past to make patches land | |
| 15:32:40 | gibi | it seems like an unsolvable thing | |
| 15:32:42 | sean-k-mooney | oh i mean i have seen it in the last week | |
| 15:32:44 | gibi | at least to me | |
| 15:33:02 | bauzas | sean-k-mooney: well, ok, so no way to distinct in between networks not using routed segments vs. networks using routed segments but with no aggregate for this segment | |
| 15:33:03 | gibi | yeah, recently I seen it almost every day, hence my new atempt to sovle it | |
| 15:33:23 | sean-k-mooney | bauzas:right but the later case should never happen | |
| 15:33:58 | sean-k-mooney | bauzas: neutron always creates the aggreates if the segments service plugin is loaded | |
| 15:34:18 | sean-k-mooney | which is what provides routed network support in neutron | |
| 15:35:03 | bauzas | sean-k-mooney: ok, so, just checking the extension is enough | |
| 15:35:20 | bauzas | and getting no aggregates is totally fine | |
| 15:35:33 | sean-k-mooney | getting no segments is fine | |
| 15:35:53 | sean-k-mooney | if we get segment but done get aggreates for those segment that a neutorn issue | |
| 15:36:05 | gibi | ^^ +1 | |
| 15:36:05 | bauzas | ok, then I'll distinct this | |
| 15:36:06 | sean-k-mooney | it means neutron could not create them for some reason | |
| 15:36:19 | bauzas | in scheduler.utils | |
| 15:36:36 | bauzas | okay, I should be able to upload a new rev in 10 mins | |
| 15:36:45 | bauzas | still a WIP tho | |
| 15:36:45 | sean-k-mooney | cool | |
| 15:37:05 | sean-k-mooney | by did i see correctly that you are adding the network request to the request spec | |
| 15:37:32 | sean-k-mooney | i might have a use for that in for one of my specs | |
| 15:38:14 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/765901/1/specs/wallaby/approved/port-scoped-sriov-numa-affinity.rst#75 | |
| 15:38:54 | sean-k-mooney | i was planning to add a prefilter but realised i did not have the requested networks in the prefilter | |
| 15:39:16 | sean-k-mooney | so i was going to move it eairler but i think i can just build on your change instead | |
| 15:39:32 | sean-k-mooney | bauzas: can you review and provide input on that in particalar | |
| 15:40:42 | bauzas | sean-k-mooney: okay, will look | |
| 15:42:03 | sean-k-mooney | there is an clean way to do it with out a prefiler but i dont want to break the patern if i dont have to | |
| 15:53:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add requested_networks field to RequestSpec object https://review.opendev.org/c/openstack/nova/+/749977 | |
| 15:53:50 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Add a routed networks scheduler pre-filter https://review.opendev.org/c/openstack/nova/+/749068 | |
| 16:30:09 | melwitt | LarsErikP: I can take care of the merge conflict for the ussuri backport, no worry | |
| 16:30:35 | melwitt | for the victoria one, we are currently stuck behind a known gate failure, I posted a note on the review | |
| 17:06:03 | stephenfin | lyarwood: should I even bother exposing this if it's really internal only? https://review.opendev.org/c/openstack/python-openstackclient/+/765366 | |
| 17:07:17 | lyarwood | stephenfin: yeah we could just block it in the cli | |
| 17:07:31 | lyarwood | stephenfin: but I'm assuming that will create future up and/or downstream bugs | |
| 17:07:40 | lyarwood | stephenfin: but they always have the API | |
| 17:08:15 | stephenfin | that's what I'm thinking. I'm not converting e.g. the 'nova reset-network' command | |
| 17:08:16 | lyarwood | stephenfin: that said the recently landed update stuff is actually useful outside of swap volume | |
| 17:08:46 | lyarwood | stephenfin: so you would just be blocking the swap volume stuff and allowing the volume update flow | |
| 17:09:18 | lyarwood | stephenfin: and FWIW this is why I wanted the swap volume flow fork lifted out from this API *before* we landed the volume update stuff | |
| 17:09:31 | stephenfin | so I'd drop the dst_volume argument and simply use src_volume for both | |
| 17:09:39 | lyarwood | yeah | |
| 17:09:43 | stephenfin | I can do that | |
| 17:26:30 | melwitt | stephenfin: while you're here, do you think you might be able to give this patch to use unittest.mock instead of third party mock a refresh from merge conflicts? https://review.opendev.org/c/openstack/nova/+/714676 prometheanfire was asking yesterday if we'd made progress on support for mock 4.0.2 https://review.opendev.org/765680 | |
| 17:26:53 | melwitt | *while you're here, I wanted to ask | |
| 18:57:35 | stephenfin | melwitt: Sorry, missed that. I'd deprioritized that because I couldn't figure out what the gain was. mock (the pypi package) is a rolling backport of upstream changes and as such, any bugs it introduces are things we're going to have to fix when we reach that future Python version anyway | |
| 18:58:12 | sean-k-mooney | stephenfin: not always | |
| 18:58:14 | stephenfin | so sticking with mock and simply getting it working with 4.0 seemed a wiser course of action, tbh | |
| 18:58:17 | melwitt | oh, hm | |
| 18:58:23 | sean-k-mooney | we have nit bugs in there backported implemation | |
| 18:58:29 | sean-k-mooney | that are not there in the native one | |
| 18:59:01 | stephenfin | I don't think so, at least not from reading upstream bug reports | |
| 18:59:27 | stephenfin | any bugs are also present in unittest.mock on the either the latest Python or Python master, I don't recall which | |
| 18:59:33 | melwitt | stephenfin: I see, ok, I can try that approach then. I didn't realize why the conversion patch wasn't being worked | |
| 18:59:41 | sean-k-mooney | our inablity to use one of the mock decortors is due to mock the lib vs unittest.mock | |
| 19:00:12 | stephenfin | sean-k-mooney: my understanding of that was that it was also an issue in the Python 3.9 unittest.mock implementation | |
| 19:00:19 | sean-k-mooney | i think its teh use of assert raises as a context manager actully | |
| 19:00:38 | stephenfin | I can root out the bug report in the morning (dinner time here) | |
| 19:01:27 | stephenfin | melwitt: I think that might be a wiser approach, but I'm not the only one with a say here. It just seems foolish to have to work around bugs with e.g. unittest.mock on Python 3.6 when mock 3.x+ doesn't have them | |
| 19:03:12 | melwitt | stephenfin: no I think what you're saying makes sense, I think that would be a simpler way to address this | |
| 19:03:41 | sean-k-mooney | stephenfin: https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaises | |
| 19:03:45 | melwitt | I can put that together | |
| 19:03:53 | sean-k-mooney | with self.assertRaises(SomeException) as cm: | |
| 19:03:55 | sean-k-mooney | do_something() | |
| 19:04:03 | sean-k-mooney | stephenfin: that does not work with mock the lib | |
| 19:04:13 | sean-k-mooney | or at least it did not work in the past | |
| 19:05:28 | sean-k-mooney | perhaps its actully caused by soemthing else but that is what we belived it was blocking that form working in nova the last time we investigated | |
| 21:57:13 | JamesBenson | Hi all, I've modified my nova.conf with `cpu_mode = host-model` in a mixed CPU environment, but not all of my CPU flags passed through. What else am I missing? | |
| 23:40:18 | openstackgerrit | melanie witt proposed openstack/nova stable/victoria: WIP [stable-only] Target cell for min bw migration service lookup https://review.opendev.org/c/openstack/nova/+/766364 | |
| 23:42:36 | sean-k-mooney | JamesBenson: host model will not pass all the flags | |
| 23:43:27 | sean-k-mooney | JamesBenson: some cpu flags are not virtualisable but the real reason is host model chose the clost model to you actual cpu listed in qemus/libvirts cpu model xml file | |
| 23:44:06 | sean-k-mooney | those models are ment to represent the common set of flag commen to a specific generation of a cpu not the specific sku | |
| 23:44:31 | sean-k-mooney | so if you cpu has feature that are not avaiable on other cpus in the same generation those feature flags likely wont be present | |
| #openstack-nova - 2020-12-10 | |||
| 00:45:29 | openstackgerrit | Wenping Song proposed openstack/nova master: Remove redundant code in instance delete https://review.opendev.org/c/openstack/nova/+/759577 | |
| 02:17:02 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API https://review.opendev.org/c/openstack/nova/+/766380 | |
| 02:29:39 | brinzhang | gmann: hi, I have a question with remove tenant_id | |
| 02:30:15 | brinzhang | gmann: the Servers Security Groups API, just need to change this apihttps://docs.openstack.org/api-ref/compute/?expanded=list-security-groups-by-server-detail#servers-security-groups-servers-os-security-groups | |
| 02:31:15 | brinzhang | but it will be impact the deprecated apis, https://docs.openstack.org/api-ref/compute/?expanded=list-security-groups-by-server-detail#security-groups-os-security-groups-deprecated | |
| 02:31:41 | brinzhang | does it need to be consider to change the deprecated apis? | |
| 02:32:23 | brinzhang | I saw the refresh policies changed the deprecated APIs too | |
| 03:34:52 | JamesBenson | sean-k-mooney: originally I had tried `custom` and posted `cpu_models = nehalem,westmere` & `cpu_model_extra_flags = pcid, vmx, pdpe1gb` but then I couldn't boot up VM's. Those three flags are the ones of interest, but aren't in both models. | |
| 03:36:03 | JamesBenson | sean-k-mooney: I thought that the way mentioned above was the right way, but couldn't get it working. Maybe the flags need to be there for all of them? | |
| 07:53:18 | openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | |
| 08:12:17 | openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | |
| 08:19:48 | openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | |