Navigation Menu

Skip to content
This repository has been archived by the owner on Jul 25, 2020. It is now read-only.

[JCLOUDS-1318] fix based on nodeTerminatePredicate #1117

Conversation

andreaturli
Copy link
Contributor

  • wait for server deletion, before deleting the security group

I'd like this to be backported to 2.0.x as well

@@ -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");
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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?

Copy link
Contributor

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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename method to provideServerTerminatedPredicate.

Copy link
Contributor

@geomacy geomacy left a 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.

@andreaturli andreaturli force-pushed the fix/openstack-nova-clean-server branch from 848125a to 69bcd5c Compare July 11, 2017 14:26
Copy link
Member

@nacx nacx left a 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()) {
Copy link
Member

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?

Copy link
Contributor Author

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());
}
Copy link
Member

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.

Copy link
Contributor Author

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

@nacx
Copy link
Member

nacx commented Jul 14, 2017

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.

@andreaturli andreaturli force-pushed the fix/openstack-nova-clean-server branch from 1133ddc to 8612758 Compare July 15, 2017 09:26
@andreaturli
Copy link
Contributor Author

rebuild please

@andreaturli
Copy link
Contributor Author

@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

Copy link
Member

@nacx nacx left a 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) {
Copy link
Member

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.

Copy link
Contributor Author

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()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be ||.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ops, yes, thanks

@andreaturli andreaturli force-pushed the fix/openstack-nova-clean-server branch 2 times, most recently from 9f90964 to 6fa492c Compare July 17, 2017 08:26
- 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
@andreaturli andreaturli force-pushed the fix/openstack-nova-clean-server branch from 6fa492c to 5f92bf3 Compare July 17, 2017 08:34
@andreaturli
Copy link
Contributor Author

thanks @nacx let's wait for the builder as extra-check.
Meanwhile I'm rebasing and squashing

@andreaturli
Copy link
Contributor Author

rebuild please

@andreaturli
Copy link
Contributor Author

merging to master only

@andreaturli
Copy link
Contributor Author

merged at master

@neykov
Copy link
Member

neykov commented Jul 21, 2017

Heads up, the commit changes how security groups are set in templateOptions. Previously the human readable name was accepted. Now the UUID of the security group is required.

@nacx
Copy link
Member

nacx commented Jul 21, 2017

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.
This said, @andreaturli is there a clean way to preserve the old behavior too?

@nacx
Copy link
Member

nacx commented Jul 21, 2017

BTW, thanks for the heads up @neykov!

@neykov
Copy link
Member

neykov commented Jul 21, 2017

Added a jira as a reminder for the release notes - https://issues.apache.org/jira/browse/JCLOUDS-1323.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants