| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-09 | |||
| 13:39:39 | elod | lyarwood: yes, sorry, you are right | |
| 13:39:48 | elod | my bad :X | |
| 13:39:54 | lyarwood | elod: and for that I honestly think we need to remove it from the blacklist in requirements | |
| 13:40:21 | lyarwood | elod: otherwise we need to update all projects etc | |
| 13:40:37 | lyarwood | elod: for both stable/train and stable/stein | |
| 13:40:41 | lyarwood | elod: thanks to grenade | |
| 13:41:26 | elod | lyarwood: the problem is that it could cause another repositories to break (according to the comment in blacklist.txt) :/ | |
| 13:41:47 | elod | however it would be the most convenient way | |
| 13:42:26 | elod | otherwise lots of branches in lots of repos needs to be patched separately :/ | |
| 13:42:35 | lyarwood | elod: I'll propose it and post to the ML | |
| 13:42:38 | lyarwood | elod: yeah indeed | |
| 13:43:50 | elod | lyarwood: thanks! let's see what we can do | |
| 13:48:27 | elod | lyarwood: or maybe if bandit 1.6.3 gets yanked... there's already the issue reported: https://github.com/PyCQA/bandit/issues/663 | |
| 13:53:49 | lyarwood | elod: ah cool | |
| 14:19:28 | bauzas | gibi: around ? | |
| 14:19:49 | bauzas | gibi: I was looking at your comment for https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/request_filter.py@327 | |
| 14:20:31 | bauzas | actually, I think we need to discuss about why we shouldn't be get required_aggregates | |
| 14:20:57 | bauzas | this would be because Neutron doesn't create those aggregates | |
| 14:22:17 | sean-k-mooney | which aggreates | |
| 14:22:28 | bauzas | (well, Nova would create those aggregates as per https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html step 10 ) | |
| 14:22:40 | bauzas | sean-k-mooney: see ^ | |
| 14:22:45 | sean-k-mooney | neutron creates the nova host aggates and addes server too it for the routed networks | |
| 14:23:12 | sean-k-mooney | i.e. neutron calls nova api and relyes on the replciation fo those host aggrates to placment aggreates | |
| 14:23:15 | bauzas | sean-k-mooney: is that nova or neutron ? | |
| 14:23:36 | bauzas | ah-ha ok | |
| 14:24:09 | bauzas | ok, so neutron directly asks the nova api to create the nova aggregates which then automatically creates the placement one | |
| 14:24:11 | bauzas | kk | |
| 14:24:12 | bauzas | so | |
| 14:24:57 | sean-k-mooney | https://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L272-L289 | |
| 14:25:20 | sean-k-mooney | yes when its creatign the RPs and inventories | |
| 14:25:22 | bauzas | if an operator uses this prefilter for routed networks, then in case we can't find a routed network related aggregate, should we accept to find any host ? | |
| 14:25:47 | sean-k-mooney | no i dont think so | |
| 14:25:58 | bauzas | (I mean , when a user asks for a network when creating the instance) | |
| 14:26:41 | sean-k-mooney | can you rephase do you mean "openstack server create --network " | |
| 14:26:45 | sean-k-mooney | or somethign else | |
| 14:27:55 | bauzas | yup, this | |
| 14:28:04 | sean-k-mooney | if a server has a port that is connected to a routed network we shoudl always reuiqre the aggreate if the prefilter is enabled | |
| 14:28:33 | sean-k-mooney | neutron does not allow mixing routed subnets and unrouted subnets in the same network | |
| 14:28:33 | bauzas | sean-k-mooney: look at https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/request_filter.py | |
| 14:28:56 | bauzas | sean-k-mooney: and gibi's concern on L327 | |
| 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 | bauzas | so we should keep it valid | |
| 14:34:01 | sean-k-mooney | its only an issue if its a routed network | |
| 14:34:16 | bauzas | and me just accepting gibi's change to turn it into True | |
| 14:34:16 | sean-k-mooney | since that should always have an aggreate per segment | |
| 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 | |