mirror of https://github.com/apache/jclouds.git synced 2025-02-21 18:06:03 +00:00

History

gurkerl83 3d753a48d2 Clear rule for bouncycastle exclusion

- Mock-Webserver v2.2.0 - Vendor, defined dependency bcprov-jdk15on > Previously, the dependency got excluded; otherwise, it conflicted with the existing bouncy castle version used in JClouds.
- Mock-Webserver v3.14.9 - The vendor does not define a bouncy castle dependency anymore; instead, it moved to the okhttp-tls module.

- Introduce the okhttp-tls module for tests in the core module. The following APIs (Docker, Elastic-Stack) and providers Softlayer extend their respective MockTest from BaseMockWebServerTest. The mock base test is located in the test jar of JClouds core module.
- Due to conflicting bouncy castle classes in the classpath, those which get loaded from the okhttp-tls module, and those defined in JClouds bouncy castle module, the bouncy castle dependency of okhttp-tls has to get skipped for the two APIs and providers mentioned.

Side note:
The JClouds GAE driver module also requires the new okhttp-tls dependency because of the following chain of inheritance.
Different from the situation above, the bouncy castle classes of the okhttp-tls got not excluded.
GaeHttpCommandExecutorServiceIntegrationTest -> BaseHttpCommandExecutorServiceIntegrationTest -> BaseMockWebServerTest

The reason for this is unknown to me.

2021-02-12 18:57:46 +09:00

src

lost changes

2021-02-12 18:57:46 +09:00

bnd.bnd

Onboard bnd-configuration files, one per module

2020-10-26 19:58:41 +09:00

pom.xml

Clear rule for bouncycastle exclusion

2021-02-12 18:57:46 +09:00

README.md

Update profitbricks readme to reflect previous refactoring changes

2016-02-20 01:33:26 +08:00

README.md

jclouds ProfitBricks

Terms

Like any cloud provider, ProfitBricks has its own set of terms in cloud computing. To abstract this into jclouds' Compute interface, these terms were associated:

Node - composite instance of Server and Storage
Image - both user-uploaded and provided Images; and Snapshots
Location - DataCenters and Region (Las Vegas, Frankfurt, etc.)
Hardware - number of cores, RAM size and storage size

Getting Started

ComputeService compute = ContextBuilder.newBuilder( "profitbricks" )
					.credentials( "profitbricks email", "password" )
					.buildView( ComputeServiceContext.class )
					.getComputeService();

This works well; however, we won't be able to use jclouds' ability to execute scripts on a remote node. This is because, ProfitBricks' default images require users to change passwords upon first log in.

To enable jclouds to execute script, we need to use a custom image. The easiest way to do this is via ProfitBricks snapshot:

Go to your DCD.
Provision a server + storage, and connect it to the internet. Upon success, you will receive an email containing the credentials needed to login to your server.
Login to your server, and change the password, as requested.

~ ssh root@<remote-ip>
...
Changing password for root.
(current) UNIX password: 
Enter new UNIX password: 
Retype new UNIX password: 
~ root@ubuntu:~# exit

Go back to the DCD, and make a snapshot of the storage. Put a descriptive name.
Configure jclouds to use this snapshot.

Template template = compute.templateBuilder()
	.imageNameMatches( "<ideally-unique-snapshot-name>" )
	.options( compute.templateOptions()
				.overrideLoginUser( "root" ) // unless you changed the user
				.overrideLoginPassword( "<changed-password>" ))
	// more options, as you need
	.build();
	
compute.createNodesInGroup( "cluster1", 1, template );

Limitations

There's no direct way of specifying arbitrary number of cores, RAM size, and storage size via the compute interface, at least until after JCLOUDS-482 is resolved. The adapter uses a predefined list hardware profiles instead.

Take note that these features are still accessible by unwraping the ProfitBricks API, but this'll reduce portability of your code. See Concepts.