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.


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)
>