[JCLOUDS-1318] fix based on nodeTerminatePredicate #1117
[JCLOUDS-1318] fix based on nodeTerminatePredicate #1117
Conversation
@@ -95,6 +101,7 @@ public Boolean apply(String id) { | |||
} | |||
|
|||
boolean serverDeleted = novaApi.getServerApi(regionAndId.getRegion()).delete(regionAndId.getId()); | |||
checkState(nodeTerminatedPredicate.apply(id), "server was not destroyed in the configured timeout"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it desirable to throw an exception here, or should we just log a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good question @geomacy, maybe a warning is enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about it more, I guess destroyNode
should not invoke CleanUpServer
but simply
boolean serverDeleted = novaApi.getServerApi(regionAndId.getRegion()).delete(regionAndId.getId());
checkState(nodeTerminatedPredicate.apply(id), "server was not destroyed in the configured timeout");
as CleanUpServer
will be invoked by https://github.com/jclouds/jclouds/blob/master/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/NovaComputeService.java#L99 anyways. I'll test it, meanwhile wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No real opinion on that to be honest! I would say though, that if the cleanupServer.apply()
is being invoked as per the link above (inside cleanUpIncidentalResourcesOfDeadNodes
), then you probably want to avoid the exception here, as otherwise the first exception when iterating over deadNodes
will prevent any remaining nodes even being attempted.
@@ -165,6 +169,14 @@ protected TemplateOptions provideTemplateOptions(Injector injector, TemplateOpti | |||
} | |||
|
|||
@Provides | |||
@com.google.inject.name.Named(TIMEOUT_NODE_TERMINATED) | |||
protected Predicate<String> provideDropletTerminatedPredicate(final NovaApi api, ComputeServiceConstants.Timeouts timeouts, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename method to provideServerTerminatedPredicate
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM at a quick read. Still have a feeling it shouldn't throw exceptions if destroyNode
fails but will defer to you on this.
848125a
to
69bcd5c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @andreaturli! Great work here. Just a couple comments!
checkArgument(novaApi.getKeyPairApi(region).isPresent(), | ||
"Key Pairs are required by options, but the extension is not available! options: %s", templateOptions); | ||
} | ||
if (templateOptions.shouldGenerateKeyPair()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we check instead if the user configured inbound ports?
I see that the groups are just passed through to the server options, so n need for the extension api if the user only sets the security group names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, changing it now
if (keyPair != null && keyPair.getPrivateKey() != null) { | ||
privateKey = Optional.of(keyPair.getPrivateKey()); | ||
credentialsBuilder.privateKey(privateKey.get()); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need this code. Users using an existing, pre-created keypair won't be able to login to the node since the private key won't be populated to the login credentials.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right!
I've re-added same logic in ApplyNovaTemplateOptionsCreateNodesWithGroupEncodedIntoNameThenAddToSet
thanks!
Tested with
templateOptions.generateKeyPair(true);
and with
templateOptions.keyPairName("test");
String privateKey = Files.toString(new File("/Users/andrea/Downloads/test.pem"), Charsets.UTF_8);
templateOptions.overrideLoginPrivateKey(privateKey);
looks good to me
On a side note, we are changing the name of the tags we use and the life cycle of the key pairs. People could be relying on this, so I'm not sure if it is a good idea to backport this to 2.0.x. |
1133ddc
to
8612758
Compare
rebuild please |
@nacx I think the build issue is related to the PR, need to understand why *AdapterExpectTest is soo slow now, I guess it's because the refactoring involves somehow the injector |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just looked at the last changes. I'll run a local build too and see what happens with that slow test.
} | ||
} else if (templateOptions.getKeyPairName() != null && templateOptions.getLoginPrivateKey() != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why checking also the private key here? If users configure a key pair we don't care if they also configure the private key. Creating a node and not accessing it is a valid use case. Perhaps users access it in another connection (where the private key will be configured). I'd remove the private key check from here and always set the keypair when its name is set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was a bit unsure as well, I'll remove the extra check
|
||
boolean keyPairExtensionPresent = novaApi.getKeyPairApi(region).isPresent(); | ||
List<Integer> inboundPorts = Ints.asList(templateOptions.getInboundPorts()); | ||
if (!templateOptions.getGroups().isEmpty() && !inboundPorts.isEmpty()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be ||
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ops, yes, thanks
9f90964
to
6fa492c
Compare
- wait for serer deletion, before deleting the security group - rename cleanupServer to cleanupResources - remove keyPairCache - better usage of tags to remove securityGroups created by jclouds - remove keyPair after the creation of a group - remove test for create unique keypair - openstack nova re-adding support for existing keypair - fix securityGroupApi check - fix other unit tests - remove ServerPredicates as it is now duplicated - remove TemplateOptions.securityGroupNames as deprecated - address commits for ApplyNovaTemplateOptionsCreatesNodesWithGroupEncodedIntoNameAndAddToSet - fix testCreateNodeWhileUserSpecifiesKeyPairAndUserSpecifiedGroups
6fa492c
to
5f92bf3
Compare
thanks @nacx let's wait for the builder as extra-check. |
rebuild please |
merging to master only |
merged at master |
Heads up, the commit changes how security groups are set in |
This is worth mentioning explicitly in the release notes as a breaking change. And we already have other comments. We should create a wiki page where we list them all to make sure we don't forget any when it's time to release. |
BTW, thanks for the heads up @neykov! |
Added a jira as a reminder for the release notes - https://issues.apache.org/jira/browse/JCLOUDS-1323. |
I'd like this to be backported to 2.0.x as well