Hmmmm I think it is still not the right fix. And I see two different issues here:
1. We shouldn't rely on naming validation to identify something as "created by jclouds". 2. The current validator does not match the Azure naming restrictions, so we'd better change it. For the second point, we could replace [the default validator](https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/internal/FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java#L79) by a more relaxed implementation that better reflects Azure naming restrictions. Once that validator is created we should be able to configure it by binding it in the HTTP API module as: ```java bind(new TypeLiteral<Validator<String>>() {}).to(CustomNamingValidator.class).in(Scopes.SINGLETON); ``` Once we have a proper naming validator in place for Azure, we should fix how we identify the security groups we automatically created. We could do this in a similar way to what we do with the availability sets: when we create these implicit security groups [here](https://github.com/jclouds/jclouds/blob/master/providers/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/compute/loaders/CreateSecurityGroupIfNeeded.java#L91), we could add a tag (say, `jclouds-<whatever is good here>`) to *mark* the group as an auto-generated one. Then the cleanup strategy, apart from getting the security group (it won't fail now as we have a proepr validator) will check if it is has the tag, and decide if it has to be deleted or not based on that. I think this approach is much more robust and we should go for something like this. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1202#issuecomment-387002426
