| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 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 | |
| 08:38:21 | bauzas | good morning Nova | |
| 08:44:36 | 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 | |
| 09:34:59 | gibi | melwitt: hi | |
| 09:35:13 | melwitt | gibi: hi | |
| 09:35:29 | gibi | melwitt: I saw your comment about the chicken-egg | |
| 09:36:19 | melwitt | I figured :) I'm tired so I might be wrong but afaict it is chicken and egg | |
| 09:36:20 | gibi | melwitt: I guess we need to pull the fixes top of each other and then ask infra to promote | |
| 09:36:57 | gibi | melwitt: I will add a unit test coverage for your qos fix during my day (I assume you will go to sleep soon) | |
| 09:37:05 | melwitt | yeah, either that or disable the min bw tempest tests to let the lower-constraints change through and then re-enable it | |
| 09:37:22 | lyarwood | ah right I was going to ask about the bw failures in nova-next | |
| 09:37:26 | brinzhang | gibi, dansmith: could you please review cyborg shelve/unshelve patch again https://review.opendev.org/c/openstack/nova/+/729563 ? thanks | |
| 09:37:38 | lyarwood | brinzhang: dansmith is out until 2021 FYI | |