| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 14:40:36 | bauzas | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/utils.py@1383 | |
| 14:42:12 | bauzas | aaaand we actually do this for *any* segment, which is bad and probably why I'm getting large number of issues | |
| 14:42:16 | bauzas | I think I found a bug :)à | |
| 14:43:20 | gibi | bauzas: sorry, I have to get back to you with this I had a complicated day so fat | |
| 14:43:23 | gibi | far | |
| 14:44:08 | bauzas | heh no worries | |
| 14:44:11 | sean-k-mooney | bauzas: raising PlacementAPIConnectFailure is not really the best | |
| 14:44:37 | bauzas | sean-k-mooney: mriedem did that I think in case of any placement call issues | |
| 14:44:56 | sean-k-mooney | ya but its not nessialy a connection issue | |
| 14:45:03 | bauzas | agreed | |
| 14:45:08 | sean-k-mooney | in this case however i dont know if we need to call placemnet at all | |
| 14:45:34 | sean-k-mooney | dont we mirror the aggreate to placement using the hostaggret uuid for the placement aggreate uuid | |
| 14:45:56 | sean-k-mooney | i think we can just do an api db lookup instead | |
| 14:45:57 | bauzas | correxct | |
| 14:46:29 | sean-k-mooney | this is how neutron creates the hostaggret | |
| 14:46:32 | bauzas | I see your point | |
| 14:46:48 | bauzas | if neutron creates a nova aggregate, then I'm ok with your proposal | |
| 14:47:05 | bauzas | I wouldn't be OK if neutron was creating a placement aggregate directly | |
| 14:47:33 | sean-k-mooney | yep it does then it lookup the uuid of the created nova aggrate and uses that to add its RP too the placment aggreate | |
| 14:47:53 | bauzas | your point is fair, I'll change it | |
| 14:47:55 | sean-k-mooney | the nova aggreate is named 'Neutron segment id %s' % segment_id | |
| 14:48:14 | bauzas | that being said, just a left concern, | |
| 14:48:32 | bauzas | if a user passes net2 when creating | |
| 14:48:35 | fungi | sorry, was in meetings... i'd never seen pipdeptree before, that's a rather awesome tool | |
| 14:48:53 | bauzas | sean-k-mooney: (with net2 having no routed segments) | |
| 14:49:08 | sean-k-mooney | it wont enter the for | |
| 14:49:08 | bauzas | sean-k-mooney: in this case, we would ask neutron to give us net2's segments, right? | |
| 14:49:34 | sean-k-mooney | yep network_api.get_segment_ids_for_network woudl retrun None or [] i think | |
| 14:49:34 | bauzas | oh | |
| 14:49:35 | fungi | and yeah, i've long asserted that to generate a consistent set of lower constraints you'd need to make it with something like a hacked pip which tries to solve for lowest rather than highest satisfying version of every dependency in the transitive set | |
| 14:50:08 | sean-k-mooney | it returns [] | |
| 14:50:18 | sean-k-mooney | py | |
| 14:50:19 | bauzas | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py#3548 | |
| 14:50:36 | bauzas | sean-k-mooney: say a net2 is not configured for routed networks | |
| 14:50:46 | bauzas | sean-k-mooney: what would this API return ? | |
| 14:51:20 | sean-k-mooney | i would expect an empty list but lets see what the api ref says | |
| 14:52:03 | bauzas | I was thinking that a segment API resource was not only for routed networks | |
| 14:52:23 | sean-k-mooney | not is routed netowrks only | |
| 14:52:30 | sean-k-mooney | https://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-segments-detail#list-segments | |
| 14:52:35 | sean-k-mooney | we are using the list endpoint | |
| 14:52:35 | fungi | when the idea of lower constraints jobs was first proposed some years back, i suggested that if people really wanted to do that they should work with the pip maintainers to implement some option to invert version selection, because otherwise the constraints lists wouldn't really be complete or internally consistent... folks said "meh it's good enough" and just punted by guessing some constraints | |
| 14:52:41 | sean-k-mooney | so that shoudl return an empy list | |
| 14:52:46 | sean-k-mooney | ill check on my home cloud | |
| 14:52:56 | bauzas | sean-k-mooney: ack, thanks | |
| 14:57:14 | sean-k-mooney | i think the query sting is wrong by the way | |
| 14:57:21 | sean-k-mooney | ?network_id=%sfields=id i think should be ?network_id=%s&fields=id | |
| 14:57:38 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py@3548 | |
| 15:02:16 | sean-k-mooney | bauzas: ok so i dont have the resouce in my api | |
| 15:02:27 | sean-k-mooney | i guess i dont have the api extion enabled | |
| 15:02:32 | sean-k-mooney | which ill check now | |
| 15:02:42 | bauzas | K | |
| 15:02:48 | bauzas | thanks for helping, btw. | |
| 15:05:49 | sean-k-mooney | so ya i dont have the segments extnsion enabled http://paste.openstack.org/show/800901/ | |
| 15:06:02 | sean-k-mooney | which mean that we also need to check for that in the nova code | |
| 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 | |