Uploaded image for project: 'jclouds'
  1. jclouds
  2. JCLOUDS-1330

Azure ARM orphaned networks not cleaned up when node deleted

Details

    • Bug
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 2.0.2
    • None
    • jclouds-compute

    Description

      Azure ARM orphaned networks not cleaned up when node deleted which also prevents the resource group from being removed.

      Not sure this is actually a bug.

      According to https://github.com/duncangrant/jclouds-labs/blob/dbadb279f14848f21879f7eb6c7136e1a5f11192/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/compute/strategy/CleanupResources.java#L94-L95 the network should be cleaned up when the resource group is deleted.

      However this is not the case. As can be seen here: https://github.com/duncangrant/jclouds-labs/blob/dbadb279f14848f21879f7eb6c7136e1a5f11192/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/compute/strategy/CleanupResources.java#L207
      As the resource group contains the network this will prevent the resource group from being deleted leaving both the network and the resource group.

      I think that, assuming the network was created by jclouds at the same time as the resource group, it is reasonable to delete both here.

      Attachments

        Activity

          nacx Ignasi Barrera added a comment - - edited

          This is intentional since the addition of the feature for attaching VMs to existing networks via the new Azure ARM specific template options. We don't want to delete what jclouds didn't create.
          A good fix could be to do the same we do with the Availability Sets: tag the networks jclouds creates here and only delete the tagged ones when cleaning up the resources.

          If this makes sense, wanna try raising a PR with the fix? I'd be happy to help.

          nacx Ignasi Barrera added a comment - - edited This is intentional since the addition of the feature for attaching VMs to existing networks via the new Azure ARM specific template options. We don't want to delete what jclouds didn't create. A good fix could be to do the same we do with the Availability Sets: tag the networks jclouds creates here and only delete the tagged ones when cleaning up the resources. If this makes sense, wanna try raising a PR with the fix? I'd be happy to help.
          duncanjg Duncan Grant added a comment -

          nacx I think I've already tried that. I'll dig out the code and see if I can make it PR quality.

          duncanjg Duncan Grant added a comment - nacx I think I've already tried that. I'll dig out the code and see if I can make it PR quality.
          andreaturli Andrea Turli added a comment -

          duncangrant any update on this? I think the implementation suggested by nacx should work

          andreaturli Andrea Turli added a comment - duncangrant any update on this? I think the implementation suggested by nacx should work
          duncanjg Duncan Grant added a comment -

          andreaturli sorry I haven't had much time to look at this. I've pushed the branch that I started on here https://github.com/duncangrant/jclouds-labs/tree/cleanup-virtual-networks but I couldn't really figure out how to actually find the virtual network that is associated with the VM. I'm not sure when I'll have time to do more on this.

          Also intellij has screwed up the import statements.

          duncanjg Duncan Grant added a comment - andreaturli sorry I haven't had much time to look at this. I've pushed the branch that I started on here https://github.com/duncangrant/jclouds-labs/tree/cleanup-virtual-networks but I couldn't really figure out how to actually find the virtual network that is associated with the VM. I'm not sure when I'll have time to do more on this. Also intellij has screwed up the import statements.
          jmspring Jim Spring added a comment -

          I'll look at the diff, but is the proposal to delete the network when the node associated with it is deleted? What if another resource is using that network? If the resource group is deleted, then for sure the network should be as well – this is what happenes through the Azure portal, CLI, etc when you delete the resource group.

          Deleting a node, however, that is behavior different from using Azure directly. What do other JClouds providers do in this case?

          jmspring Jim Spring added a comment - I'll look at the diff, but is the proposal to delete the network when the node associated with it is deleted? What if another resource is using that network? If the resource group is deleted, then for sure the network should be as well – this is what happenes through the Azure portal, CLI, etc when you delete the resource group. Deleting a node, however, that is behavior different from using Azure directly. What do other JClouds providers do in this case?
          nacx Ignasi Barrera added a comment -

          I'd say, when deleting a node, we should delete the networks it was attached to if:

          • The network was automatically created by jclouds (it has a marker tag that allows us to identify them).
          • There are no other nodes attached to it.

          This way we prevent deleting networking infrastructure that could be pre-created by users, and we allow reusing them as needed.

          Regarding the resource-group deletion, we are already deleting it if empty, after having cleaned up all resources associated to the deleted nodes . See here, so I think that logic is already OK. We should assume that users may create stuff in the resource group, and we don't want to automatically delete everything we are not directly in control of.

          So, I'd say we just need to add the logic to delete "our" orphaned networks. The rest should be ok as-is. Does this make sense?

          nacx Ignasi Barrera added a comment - I'd say, when deleting a node, we should delete the networks it was attached to if: The network was automatically created by jclouds (it has a marker tag that allows us to identify them). There are no other nodes attached to it. This way we prevent deleting networking infrastructure that could be pre-created by users, and we allow reusing them as needed. Regarding the resource-group deletion, we are already deleting it if empty, after having cleaned up all resources associated to the deleted nodes . See here , so I think that logic is already OK. We should assume that users may create stuff in the resource group, and we don't want to automatically delete everything we are not directly in control of. So, I'd say we just need to add the logic to delete "our" orphaned networks. The rest should be ok as-is. Does this make sense?
          jmspring Jim Spring added a comment -

          I think a specific deletion of a resource group should delete all resources in it regardless of who created the resources.

          In this case, if the resources were created with jclouds, we should delete them like the network and the RG if empty. If non-jclouds resources were added to the RG, then they shouldn’t be deleted (unless the user specifies a specific RG delete).

          One option would be to use tags to specify jclouds created resources.

          Sent from my iThingy

          jmspring Jim Spring added a comment - I think a specific deletion of a resource group should delete all resources in it regardless of who created the resources. In this case, if the resources were created with jclouds, we should delete them like the network and the RG if empty. If non-jclouds resources were added to the RG, then they shouldn’t be deleted (unless the user specifies a specific RG delete). One option would be to use tags to specify jclouds created resources. Sent from my iThingy

          People

            Unassigned Unassigned
            duncanjg Duncan Grant
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated: