We’ve just let PHP OpenCloud v1.7.0 into the wild, so it would be great to give some details of the SDK’s new abilities. I’ve written a changelog of features, plus an upgrade guide for any folks who are daunted with the prospect of updating their codebase.
We’ve changed a few core method names for greater consistency and clarity. For example, the factory method for initializing a Compute/Nova service is:
1 2 3 4 5 6 7 8
$client->compute(). I think there’s a need for clarity because there are lots of objects in the SDK that are associated with “Compute”.
Also, where possible, resource models will enforce better encapsulation and a more consistent public API. Gradually we’re rolling out changes so that object properties are mutated through setter methods and accessed through getter methods, rather than direct interaction with object properties. It also works better for awkward names (especially API extensions). If I want to do something to server OS Disk config for example:
1 2 3 4 5 6 7
The above will be part of an upcoming release - but I just wanted to indicate the direction of the SDK.
Where possible, all requests are batched and executed concurrently using PHP’s multi_curl functionality. One feature which incorporates this concurrency is uploading objects to CloudFiles:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
As you can see, the
name key is required for every file. You must also specify either a path key (to an existing file), or a
body can either be a PHP resource or a string representation of the content you want to upload.
Another cool breakthrough is our support for large files, or DLOs (dynamic large object), as they’re known in OpenStack terminology. Uploading these types of file are super easy now and, most importantly, very quick:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
So what we’re doing here is breaking up the mega file into 1.5GB chunks, and assigning 4 cURL handles to upload chunks concurrently. So if you’re uploading a 15GB file, you will see 10 “segment files” in your Container. The naming convention will be
video.mov/segment/2, etc. After all these segments are uploaded, a “manifest file” will be uploaded (under the name
video.mov is accessed, the manifest file is requested which will concatenate all the smaller segments into one.
There’s a bunch of cool stuff you can do now using CloudFiles - for the full list (including two other ways to upload files), I’d recommend reading our new user docs for this feature.
Perhaps the most noticeable change is that the
Guzzle\Http component now powers the majority of HTTP functionality. Instead of maintaining this common utility code, we’re allowing a dedicated open-source project to take care of it, allowing us to concentrate on rolling out more API features. For more information, you can view the official website and the source code.
Better URL handling
URLs are now treated as
Guzzle\Http\Url objects throughout the library rather than basic strings. Another thing to realize is that although the
url() method still works for most resource objects, it is now deprecated - you should use
getUrl() instead. Let’s give it a spin:
1 2 3 4 5 6 7
You can also use this class for your own use:
1 2 3 4 5 6 7 8 9 10 11 12
Similarly, you can take advantage of the consistently named new HTTP requests methods, and construct your own:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
So, all in all, a whole ton of awesome new stuff. We’re constantly working on new features - one thing I want to work on next is uploading/synchronizing entire directories with CloudFiles. If you have any cool ideas for upcoming releases, or would like to contribute code, you are more than welcome to do so.