Use of cloudFilesCDN with internalURL

[tomgidden]

To be able to utilize ServiceNet to do the API operations, it seems necessary to indicate internalURL rather than publicURL as the RAXSDK_OBJSTORE_URLTYPE. However, that doesn't then allow use of CDN, with an exception of ObjectStore\CdnNotAvailableError, which is caused by a silent ignore of an EndpointError with the message:

No endpoints for service type [rax:object-cdn], name [cloudFilesCDN], region [LON] and urlType [internalURL]

Tracking back, it's clear that the endpoint's reported cloudFilesCDN service doesn't supply an internalURL, whereas the cloudFiles service does, but it seems a very common use-case to manage Cloud Files via ServiceNet but publish public CDN URLs.

Is the only workaround to do the object creation and management via ServiceNet, but then open a second ObjectStore and re-retrieve the objects just to get their CDN URLs?

[gecampbell]

That's honestly not a use case I had anticipated. You could potentially change the ObjectStore::__construct() method to have an optional parameter that would be the URLtype of the CDN. The code on objectstore.php, ca. line 131, would then use that internalURL instead of the same one passed for the base.

I need to think about this.

[tomgidden]

Thanks for that suggestion! I've implemented it as starberry/php-opencloud@b02384e and it seems to work so far, with very limited testing. However, it does mean that the convenient factory methods via Service can't be used, and the ObjectStore needs to be instantiated directly:

$ostore = new OpenCloud\ObjectStore($rack, 'cloudFiles', 'LON', 'internalURL', 'publicURL');

...and it's clearly a bit of a kludge ;) so I haven't put in a pull request!

It does seem like a very likely use case to me, though: a Cloud Server uploads files to Cloud Files using ServiceNet, but then serves those files to the public Internet via CDN. It looks like a limitation in having the cloudFiles and cloudFilesCDN services reported separately by the API endpoint.

[corrigang]

This is similar to a use case I'm dealing with: I have published public URLs in my external data store, and want to execute an internal Copy() of the DataObject instance... but I can't easily get back to the internal object reference starting with a public URL.

[TeckniX]

Just wondering where we were on this, as the internal URL method (aka ServiceNET) has been suggested by most rackers (speed purposes), yet the method doesn't allow the retrieval of the PublicURL().

The internalURL is apparently a 'favorite' for pushing data within Rackspace, but the drawback of not having the PublicURL() available is a bit annoying.

[jamiehannaford]

@tomgidden @TeckniX @corrigang Hey guys, could you try out the latest version? Warning: Please bear in mind that because Cloudfiles/Swift has been completely refactored, a lot of the public API has changed. Please consult the docs before doing anything.

Accessing public information about the CDN whilst using internalURL with containers is now possible:

use OpenCloud\Rackspace;

$client = new Rackspace(Rackspace::US_IDENTITY_ENDPOINT, [
    'username' => 'foo',
    'apiKey'   => 'bar'
]);

$service = $client->objectStoreService('cloudFiles', 'DFW', 'internalUrl');

// Find container's CDN SSL URL
$container = $service->getContainer('baz');
echo $container->getCdn()->getCdnSslUri();

// Find one of its object's public URL
$object = $container->getObject('example.txt');
echo $object->getPublicUrl();

[jamiehannaford]

If anybody has issues with this, comment on this thread and I'll reopen for investigation.