| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 14:29:13 | bauzas | actually, the prefilter won't ask for any aggregate if we can't find them | |
| 14:29:30 | bauzas | it's just the method which would be returning either False or True | |
| 14:29:34 | sean-k-mooney | so we shoudl be rejecting the request | |
| 14:29:35 | bauzas | but, | |
| 14:29:56 | bauzas | returning False won't do anything AFAICT | |
| 14:30:05 | sean-k-mooney | i mean raise an excption | |
| 14:31:05 | bauzas | sean-k-mooney: k, i see | |
| 14:31:10 | bauzas | sean-k-mooney: that said, just a question | |
| 14:31:14 | bauzas | given two networks | |
| 14:31:33 | bauzas | one having routed segments, and one without any routed segments | |
| 14:32:00 | bauzas | neutron would then create aggregates for the routed segments mapping to net1 | |
| 14:32:11 | bauzas | but wouldn't do anything for net2, right? | |
| 14:32:14 | sean-k-mooney | in that case you want the intersection fo the aggreates | |
| 14:32:23 | sean-k-mooney | yes | |
| 14:32:39 | sean-k-mooney | well not the intersection | |
| 14:32:45 | bauzas | sean-k-mooney: k, so if a user is passing net2 when creating the instance, then we should be accepting it | |
| 14:33:04 | bauzas | and not rejecting the instance creation | |
| 14:33:08 | sean-k-mooney | yes althoughg its unlikely that there will be a mix | |
| 14:33:25 | sean-k-mooney | its vlaid but you tend to have one or the other | |
| 14:33:38 | bauzas | sure, but then the fact that we can't find aggregates for this network doesn't mean it's a blocker | |
| 14:33:50 | sean-k-mooney | correct | |
| 14:33:51 | bauzas | hence us not rejecting it | |
| 14:34:01 | sean-k-mooney | its only an issue if its a routed network | |
| 14:34:01 | bauzas | so we should keep it valid | |
| 14:34:16 | sean-k-mooney | since that should always have an aggreate per segment | |
| 14:34:16 | bauzas | and me just accepting gibi's change to turn it into True | |
| 14:34:34 | sean-k-mooney | you still need to rais in the routed case i think | |
| 14:34:42 | bauzas | sean-k-mooney: sure but the prefilter doesn't know why the aggregate wasn't there | |
| 14:34:55 | bauzas | nova only knows about aggregates | |
| 14:35:05 | sean-k-mooney | but it know if its a routed network request right? | |
| 14:35:11 | bauzas | how? | |
| 14:35:45 | sean-k-mooney | from the presence of a segment on the neutron subnet | |
| 14:35:46 | bauzas | requested_networks is there for *any* network query | |
| 14:35:59 | sean-k-mooney | or ip_allocation=defer | |
| 14:36:01 | bauzas | sean-k-mooney: sorry but again, we don't know it | |
| 14:36:37 | sean-k-mooney | utils.get_aggregates_for_routed_network is calling neutron | |
| 14:36:43 | sean-k-mooney | so it can check | |
| 14:38:06 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py#3539 | |
| 14:38:19 | sean-k-mooney | if that retuns segments then its a routed netork | |
| 14:38:37 | bauzas | well, shit, you're right | |
| 14:38:57 | bauzas | we can raise an exception accordingly | |
| 14:40:14 | bauzas | and we do actually | |
| 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 | |