Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-12-09
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
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

Earlier   Later