Using Juju with HP-Cloud - fist impressions

Mon Mar 25 20:16:44 UTC 2013

W dniu pon, mar 25, 2013 o 4:36 ,nadawca Ian Booth 
<ian.booth at canonical.com> napisał:
> H
> 

> One possible reason for any difference is that the web page you are 
> looking at
> was written for Python Juju. Go Juju doesn't deliberately use 
> different config
> settings but there might be subtle differences.
> 
> default-image-id: "75845"
> 
> The image id above from juju init is for a recent Precise 12.04 64 
> bit server.
> The 8419 image id on the web page is for a deprecated image, so the 
> difference
> there is that the web page is out of date. A general comment - image 
> ids are
> used right now because work to support constraints is not quite ready 
> for
> Openstack deployments. The need for explicit image ids will disappear 
> as soon as
> the constraints work is finalised.
> 
> The default series config setting for Go Juju is commented out in the 
> juju init
> generated config, but the purpose of the field is currently the same 
> as for
> Python Juju. Work is being done in Go Juju to change how series is 
> handled, and
> this will be documented in the relevant release notes
> 

I only meant that image-id implies series. If one is specified then the 
other is useless. It is also unclear which takes precendence when both 
are used.

> 
>>  3) Juju gives a very confusing error message if object storage is 
>> not activated
>>  and activated in the right region
>>  
>> 
> We'll see what can be done to improve the error message. Do you have 
> an example
> of the message you are referring to?
> 

I don't have the error message anymore (and I cannot deactivate the 
object store from the web console) but I would expect something like
 "you need to activate object store for <region> to use juju: <link to 
where this can be done>. Since this is something that each user of HP 
cloud will bump into (unless they activate everything up front, which I 
would not do) it should be handled better.

> 
> Yes, this is a known limitation. See bug 1135335.
> 
>>  5) Region names seem to have changed as compared to our 
>> documentation examples
>>  
>> 
> Do you have a specific example? The web page refers to region
> "az-1.region-a.geo-1" and this is the same as I have in my 
> OS_REGION_NAME env
> variable.
> 

Ah, more confusion, see below

> 
>>  6) the purpose of some fields feels too cryptic. I don't really 
>> know what
>>  'tenant-name' is for.
>>  
>> 
> From the juju init output:
> 
>     # Usually set via the env variable OS_TENANT_NAME, but can be 
> specified here
>     # tenant-name: <your tenant name>
> 
> Where to get your tenant name is shown the the web page.
> 

Replace TENANT with FROZBONICATOR. It still doesn't tell you how this 
field is used. I guess there are two parts of configuration that juju 
requires:

1) Boring stuff that "just has to be defined" that is not real 
configuration, just fixed-per-user blob
2) Configuration that users want to change and thus need to understand.

Currently TENANT falls under 1) but I suspect it's 2) in disguise 

As a user I still don't understand what the tenant is or how it can be 
used to gain something. Since I apparently can create them on 
https://account.hpcloud.com/projects can those be just called 
"projects"?

What Juju can do better here: the automatically generated configuration 
example could briefly explain what the tenant/project field is for 
along with a link to juju docs that explain the topic in depth and give 
examples on when a user might want to create additional projects.

>>  7) Bootstrap fails like this:
>>  
>>  zyga at g580:~$ juju bootstrap --upload-tools
>>  error: cannot start bootstrap instance: cannot find image satisfying
>>  constraints: failed to get list of flavours, caused by: no 
>> endpoints known for
>>  service type: compute
>>  
>> 
> This indicates the region is not set correctly.
> 

You were right. 

This is totally confusing though and I don't understand why that value 
is correct, compare:

 From https://account.hpcloud.com/account/api_keys

There are seven groups of service endpoints:
1) identity
2) block storage
3) CDN
4) compute
5) image management
6) networking
7) object storage

In each group there are multiple URLs apparently grouped by regions:

* region-a.geo-1  
* region-b.geo-1 
* az-1.region-a.geo-1

The value with "az-1." prefix is only used by block storage, compute 
and networking.

As a user I really expected something tangible like what Amazon 
currently provides (geographical location). Presumably "az-1" is 
availability zone 1 but I'm just guessing. How that compares to region 
a and b is beyond me.

What Juju can do better here: have working documentation that works out 
of the box
What HP could do better here: the UI is confusing. I realize that some 
of those values are very much for developers to use but perhaps some 
partnership "this is how to use juju with your account" could be 
possible here.

So with the region fix, I apparently can bootstrap. Going to 
https://console.hpcloud.com/compute/az-1_region-a_geo-1 I can see one 
machine running.

Issuing $ `juju status` fails though:

zyga at g580:~/.juju$ juju bootstrap --upload-tools
zyga at g580:~/.juju$ juju status
error: no reachable servers
zyga at g580:~/.juju$ juju status
error: failed to get list of server details, caused by: 
https://az-1.region-a.geo-1.compute.hpcloudsvc.com/v1.1/35370665361422/servers/detail?name=juju-hpcloud-.%!A(string=failed 
executing the request), caused by: Get 
https://az-1.region-a.geo-1.compute.hpcloudsvc.com/v1.1/35370665361422/servers/detail?name=juju-hpcloud-.%2A: 
remote error: handshake failure

Thanks
ZK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130325/2ba643a7/attachment.html>