Closed #1202.
--
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#event-3586273351
Please reopen against apache/jclouds if this is still relevant.
--
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-663855703
@danielestevez any plans ti implement the cleanup improvements in this PR? If
not feel free to close it and open a new one.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This PR is about fixing the cleanup. As discussed previously that should be
better achieved by tagging the implicit security groups jclouds creates. I'm ok
at using this PR to implent this, or to close it and open a follow-up one. Up
to you @danielestevez! And thanks for all the recent patches!
This simple validator should work https://github.com/jclouds/jclouds/pull/1213
and we could close this PR
--
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-391501389
Thanks, @danielestevez. I've just added a comment to your commit.
--
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-389865682
About this, i started to implement a custom validation for ARM here extending
current interfaces
https://github.com/danielestevez/jclouds/commits/groupNamingValidation
Still not sure about the implementation, and specially naming but there it is
if you want to take a look
--
You are receiving
The DNS one is just a naming convention known to work for most providers. Being
restrictive works fine for portability but conflicts when you're trying to use
it with pre-existing stuff. In this case I'd say it makes sense to have a
custom one for Azure, since it is only used to name things:
For the first point, i supposed it made sense to delete only those "implicit"
orphaned groups created by jclouds, but it's true it'd delete groups from the
subscription so adding a tag would make this process indeed more robust.
For the validator, i thought there was maybe a reason to use a
H 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
> I think this change is not safe
Thanks for catching this, @nacx! Are we perhaps missing a unit test somewhere
to ensure the cleanup method behaves as you described?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Checked again:
The problem happens when trying to security groups from nodes not created by
jclouds and therefore, not respecting naming convention (using Upper case
breaks
Ok! I'll take a look at it again.
When i tried it it was trying to remove a security group already existing in
the user subscription, maybe the problem is there
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think this change is not safe. The group name the method [gets passed
in](https://github.com/jclouds/jclouds/blob/master/providers/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/compute/AzureComputeService.java#L120)
is **not** the name of a security group. It is the name of the
This currently fails if you use a securityGroup with Upper case letters in your
subscription.
Naming check shouldn't be needed in a delete operation.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds/pull/1202
-- Commit Summary --
* Removes
15 matches
Mail list logo
