History

Dori Polotsky 1c57d07f70 JCLOUDS-847: Poor upload performance for putBlob This change improves the performance of writing to sockets with the default Java URL connection HTTP client, by enlarging the buffer used for socket writes from an implicit hard-coded 4KB / 8KB buffer to a configurable 32KB buffer. The buffer size is now controlled by the following property with the following default value: jclouds.output-socket-buffer-size: 32768 The implementation is based on a variant of ByteStreams.copy (written as ByteStreams2.copy) which accepts the buffer size as an argument, unlike the original Guava code that uses a hard-coded size. The change was done directly within the loop that copies the input stream to the output stream, and not by wrapping a BufferedOutputStream around the existing output stream, in order to avoid copying the payload twice. On some platforms this change can improve both the putBlob throughput and the total CPU consumption.		2019-04-27 15:16:08 +09:00
..
src	JCLOUDS-847: Poor upload performance for putBlob	2019-04-27 15:16:08 +09:00
README.md	Update profitbricks readme to reflect previous refactoring changes	2016-02-20 01:33:26 +08:00
pom.xml	fix typo in project.version	2018-02-21 16:45:43 +01: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.