Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-12-09
15:06:42 sean-k-mooney its just called segment https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L29
15:08:48 bauzas sean-k-mooney: well, we raise_exc=False
15:10:37 gibi bauzas: now I read back, It is OK to me what you and sean-k-mooney come up with
15:12:04 sean-k-mooney bauzas: so we check if the multi provide net extension exist here https://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py#3524
15:12:33 sean-k-mooney but we shoudl be checking if the segment extions exists
15:14:23 bauzas this sounds a reasonable ask
15:14:59 sean-k-mooney we can cache it the same way we do with the other check so we only do it once.
15:15:03 bauzas sean-k-mooney: but my question remains open, do we get an empty list for a network that doesn't do routed segments or whatever else ?
15:16:32 sean-k-mooney the api ref does not say but i would expect the list endpoint which we are calling to return an empty list
15:16:37 sean-k-mooney i can check there unit tests
15:17:13 bauzas sean-k-mooney: thanks
15:18:14 stephenfin bauzas, lyarwood, gibi, (anyone else): This is not high priority work, but I have an ass-load of OSC patches that would benefit from some nova devs' eyes
15:18:15 stephenfin https://review.opendev.org/q/project:openstack/python-openstackclient+status:open+file:compute+owner:stephenfin%2540redhat.com
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

Earlier   Later