[heat] Parametrization of Neutron trunk subports scaling down
Hi, With Hot templates we run into a scaling issue with Neutron trunk subports. The task is to create Neutron trunks with "vlan_count" number of subports, and with stack update be able to add or remove subports of the created trunk. We tried with resourceGroup, and that works well if we increase the number of subports. The problem comes with decrease, as with resourceGroups I can't (my lack of knowledge) tell heat_engine that first update the trunk and remove the subport and after that delete the port. And Neutron API gives back conflict as the port which heat_engine tries to delete is still used by the trunk. Do you know a way to accomplish such an operation with Hot templates? Thanks in advance for the help. Best wishes Lajos Katona (lajoskatona)
Do you mind sharing your (partial) template so that I can dig into it ? (It'd be nice if you can open a bug in storyboard[1]) [1] https://storyboard.openstack.org/#!/project/openstack/heat I've not tried the said use case really by my self. As far as I remember we had a similar requirement in TripleO (though we didn't use trunk resource) but used jinja2 template and render the template contents in client side. On 3/23/24 00:35, Lajos Katona wrote:
Hi, With Hot templates we run into a scaling issue with Neutron trunk subports. The task is to create Neutron trunks with "vlan_count" number of subports, and with stack update be able to add or remove subports of the created trunk. We tried with resourceGroup, and that works well if we increase the number of subports. The problem comes with decrease, as with resourceGroups I can't (my lack of knowledge) tell heat_engine that first update the trunk and remove the subport and after that delete the port. And Neutron API gives back conflict as the port which heat_engine tries to delete is still used by the trunk.
Do you know a way to accomplish such an operation with Hot templates?
Thanks in advance for the help. Best wishes Lajos Katona (lajoskatona)
Hi, I copied the simplified yamls to an etherpad: https://etherpad.opendev.org/p/Trunk_creation_with_resourceGroup We tried to move the nested stack (subports.yaml) into stack.yaml but we were not able to solve the problem so I believe the issue is not coming from the "nestedness" of the resourceGroup. Thanks in advance for the help. Lajos Katona (lajoskatona) Takashi Kajinami <kajinamit@oss.nttdata.com> ezt írta (időpont: 2024. márc. 25., H, 5:46):
Do you mind sharing your (partial) template so that I can dig into it ? (It'd be nice if you can open a bug in storyboard[1])
[1] https://storyboard.openstack.org/#!/project/openstack/heat
I've not tried the said use case really by my self. As far as I remember we had a similar requirement in TripleO (though we didn't use trunk resource) but used jinja2 template and render the template contents in client side.
Hi, With Hot templates we run into a scaling issue with Neutron trunk subports. The task is to create Neutron trunks with "vlan_count" number of subports, and with stack update be able to add or remove subports of the created trunk. We tried with resourceGroup, and that works well if we increase the number of subports. The problem comes with decrease, as with resourceGroups I can't (my lack of knowledge) tell heat_engine that first update the trunk and remove the subport and after
On 3/23/24 00:35, Lajos Katona wrote: that delete the port.
And Neutron API gives back conflict as the port which heat_engine tries to delete is still used by the trunk.
Do you know a way to accomplish such an operation with Hot templates?
Thanks in advance for the help. Best wishes Lajos Katona (lajoskatona)
Sorry I didn't update this thread for long. I think the current problem is that the trunk uses outputs from the resource group, so always trunk is updated after the resource group is updated. I've checked a few other methods but could not find a valid solution so far. We may be able to implement the new OS::Neutron::TrunkPort resource and manage trunk port using that dedicated resource defined in the subports stack, but this apparently requires a new resource implementation and is not available at this moment. On the other hand I wonder if implementing vlans by resource group is actually a good strategy. The main use case of it is managing an instance and resources associated with it for easy scale-out/in of instances and as far as I know using it for other pattern is not quite popular use case. I'm not very sure if it some operations may work for this case. (eg. when you have 3 vlans, 101, 102, and 103 and attempt to remove the 2nd one, 102). I may probably suggest implementing the template generation at client side (eg using jinja2), instead of heavily relying on Resource Group for this case. On 3/25/24 19:20, Lajos Katona wrote:
Hi, I copied the simplified yamls to an etherpad: https://etherpad.opendev.org/p/Trunk_creation_with_resourceGroup <https://etherpad.opendev.org/p/Trunk_creation_with_resourceGroup>
We tried to move the nested stack (subports.yaml) into stack.yaml but we were not able to solve the problem so I believe the issue is not coming from the "nestedness" of the resourceGroup.
Thanks in advance for the help. Lajos Katona (lajoskatona)
Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> ezt írta (időpont: 2024. márc. 25., H, 5:46):
Do you mind sharing your (partial) template so that I can dig into it ? (It'd be nice if you can open a bug in storyboard[1])
[1] https://storyboard.openstack.org/#!/project/openstack/heat <https://storyboard.openstack.org/#!/project/openstack/heat>
I've not tried the said use case really by my self. As far as I remember we had a similar requirement in TripleO (though we didn't use trunk resource) but used jinja2 template and render the template contents in client side.
On 3/23/24 00:35, Lajos Katona wrote: > Hi, > With Hot templates we run into a scaling issue with Neutron trunk subports. > The task is to create Neutron trunks with "vlan_count" number of subports, and with stack update be able to add or remove subports of the created trunk. > We tried with resourceGroup, and that works well if we increase the number of subports. > The problem comes with decrease, as with resourceGroups I can't (my lack of knowledge) tell > heat_engine that first update the trunk and remove the subport and after that delete the port. > And Neutron API gives back conflict as the port which heat_engine tries to delete is still used by the trunk. > > Do you know a way to accomplish such an operation with Hot templates? > > Thanks in advance for the help. > Best wishes > Lajos Katona (lajoskatona)
Hi Takashi, Thanks for the effort. I see the template one as most effective in short term. Best wishes Lajos Katona (lajoskatona) Takashi Kajinami <kajinamit@oss.nttdata.com> ezt írta (időpont: 2024. ápr. 17., Sze, 13:58):
Sorry I didn't update this thread for long.
I think the current problem is that the trunk uses outputs from the resource group, so always trunk is updated after the resource group is updated. I've checked a few other methods but could not find a valid solution so far. We may be able to implement the new OS::Neutron::TrunkPort resource and manage trunk port using that dedicated resource defined in the subports stack, but this apparently requires a new resource implementation and is not available at this moment.
On the other hand I wonder if implementing vlans by resource group is actually a good strategy. The main use case of it is managing an instance and resources associated with it for easy scale-out/in of instances and as far as I know using it for other pattern is not quite popular use case. I'm not very sure if it some operations may work for this case. (eg. when you have 3 vlans, 101, 102, and 103 and attempt to remove the 2nd one, 102). I may probably suggest implementing the template generation at client side (eg using jinja2), instead of heavily relying on Resource Group for this case.
Hi, I copied the simplified yamls to an etherpad: https://etherpad.opendev.org/p/Trunk_creation_with_resourceGroup < https://etherpad.opendev.org/p/Trunk_creation_with_resourceGroup>
We tried to move the nested stack (subports.yaml) into stack.yaml but we were not able to solve the problem so I believe the issue is not coming from the "nestedness" of the resourceGroup.
Thanks in advance for the help. Lajos Katona (lajoskatona)
Takashi Kajinami <kajinamit@oss.nttdata.com <mailto: kajinamit@oss.nttdata.com>> ezt írta (időpont: 2024. márc. 25., H, 5:46):
Do you mind sharing your (partial) template so that I can dig into it ? (It'd be nice if you can open a bug in storyboard[1])
[1] https://storyboard.openstack.org/#!/project/openstack/heat < https://storyboard.openstack.org/#!/project/openstack/heat>
I've not tried the said use case really by my self. As far as I remember we had a similar requirement in TripleO (though we didn't use trunk resource) but used jinja2 template and render the template contents in client side.
On 3/23/24 00:35, Lajos Katona wrote: > Hi, > With Hot templates we run into a scaling issue with Neutron trunk subports. > The task is to create Neutron trunks with "vlan_count" number of subports, and with stack update be able to add or remove subports of the created trunk. > We tried with resourceGroup, and that works well if we increase
On 3/25/24 19:20, Lajos Katona wrote: the number of subports.
> The problem comes with decrease, as with resourceGroups I can't
(my lack of knowledge) tell
> heat_engine that first update the trunk and remove the subport
and after that delete the port.
> And Neutron API gives back conflict as the port which heat_engine
tries to delete is still used by the trunk.
> > Do you know a way to accomplish such an operation with Hot
templates?
> > Thanks in advance for the help. > Best wishes > Lajos Katona (lajoskatona)
participants (2)
-
Lajos Katona
-
Takashi Kajinami