Open Stack

On Thu, 2023-01-05 at 08:36 -0600, hai wu wrote:
> Thanks for confirming. The reason why I asked this question is due to
> VM deletion. By default, deleting a VM instance means its single
> openstack port associated with the VM (created automatically by nova),
> would be auto deleted, there's no extra work needed for that; But if
> the associated openstack port was manually created for this VM
> instance, then it seems it would NOT remove this openstack port
> automatically.
> 
correct for what its worth in general we have been pushing peopel to a workflow
where they create teh port first and avoid the automatic creation fo a port via nova.

passing a network or subnet is simpler but all of the non trivial cases such as seting 
a vnic type or properly supproting QOS need the other workflow.

if it was not for legacy users depending on the automatic cleanup i woudl presonally prefer
to make nova created port behave like manulaly created ports. we could do that in an api
microverion but it never felt imporant enought to change.
>  I would like to ensure the cleanup of such ports upon
> VM deletion. There's connection.network.delete_port() function from
> openstacksdk, and I could retrieve all associated ports for a
> particular vm instance, so it is possible to just delete all
> associated ports for the instance upon VM deletion call, but there
> might be some conflicts, meaning that for ports auto created by nova,
> those will be purged by openstack automatically.
you should not get a conflict if you delete the port while the vm deletion is happening either you or nova will get a 404
neutron will also send a network_vif_deleted event to nova to notify it and nova would try an detach the port
technially this could race since they do not share the same lock

https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8166-L8168 vs
https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3187

but it should not prevent the delete of the vm or ports form completeing.


>  How to ensure there
> would be no conflicts upon vm deletion call, and ensure all associated
> ports would be purged without error?

the best way to day is to get the list of ports assocated with the vm.
delete the vm and then after the delete is complete delete any remaining ports
by looping over the list and handelign the 404 for ports already deleted by nova.

if we were to extend neutron with a new delete_on_detach extension we could automate this
more cleanly but since that does not exist this is left to the user.

> 
> On Thu, Jan 5, 2023 at 6:32 AM Sean Mooney <smooney at redhat.com> wrote:
> > 
> > On Thu, 2023-01-05 at 10:08 +0100, Slawek Kaplonski wrote:
> > > Hi,
> > > 
> > > Dnia czwartek, 5 stycznia 2023 03:54:25 CET hai wu pisze:
> > > > I could not find any API way to tell the difference between openstack
> > > > ports created automatically when a new instance got created, and
> > > > openstack ports manually created for port reservation purposes.
> > > > 
> > > > There's 'preserve_on_delete' attribute in the openstack database for
> > > > each vm instance, and if it is set to 'true', then the port was
> > > > manually created, if not, then it was automatically created. But
> > > > there's no API to retrieve this.
> > > > 
> > > > Am I missing something?
> > > > 
> > > > Hai
> > > > 
> > > > 
> > > 
> > > You are no missing anything. There is no way to check that using API (both Neutron nor Nova).
> > ya i think you can tell from the nova db if it was created by nova by corralating the virutal interface table and request spec for the instance
> > but its not somethign you can tell form the api or form neutron's perspective.
> > 
> > there are some cases where preserve_on_delete can be lost too. namely if neutron breaks and the network info cache is currpted and teh ports are
> > removed form the cache when the cache is forcefully rebuilt the value of preserve_on_delete may not be preserved.
> > https://bugs.launchpad.net/nova/+bug/1834463 we also have https://bugs.launchpad.net/nova/+bug/1976545
> > one of the possible fixes for the later https://review.opendev.org/c/openstack/nova/+/844326 would ideally involve a new neutron api extention to
> > model delete_on_detach
> > 
> > im not sure if that is related to why you asked this question?
> > can you expalin why you are trying to determin if it was manually created vs created by nova?
> > 
> > > 
> > 
>