Notes on using OpenStack with Juju

Kapil Thangavelu kapil.thangavelu at canonical.com
Tue Dec 11 13:39:44 UTC 2012


On Tue, Dec 11, 2012 at 8:20 AM, Thomas Leonard <
tal at it-innovation.soton.ac.uk> wrote:

> On 2012-12-04 17:15, Martin Packman wrote:
>
>> On 04/12/2012, Thomas Leonard <tal at it-innovation.soton.ac.uk**> wrote:
>>
>>>
>>> The 7ed23f... bit is simply the (public) project ID, not any kind of
>>> access
>>> token. So how is Swift supposed to authorise the request?
>>>
>>
>> Because the container should have been created with an anyone-can-read
>> acl:
>>
>> <http://bazaar.launchpad.net/~**juju/juju/trunk/view/head:/**
>> juju/providers/openstack/**client.py#L509<http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/openstack/client.py#L509>
>> >
>>
>
> Hi Martin,
>
> This seems to contradict the earlier claim that charms should be private:
>
> On 2012-08-10 18:21, Clint Byrum wrote:
> > The objects should be protected in their storage against arbitrary
> > entities discovering and downloading them, as the contents could be
> > considered sensitive (though official charm store policy doesn't allow
> > this, users may want to create charms that embed passwords or keys
> > and such.
>
>
The problem is that the object storage in openstack does not have a
standard mechanism for restricted access sans credentials. There's a
tempurl middleware which would suffice (equivalent to the ec2 signed url
mechanism) but its not widely deployed or discoverable. We don't want to
propogate account credentials to additional machines in the environment.


>
> On 2012-12-04 17:15, Martin Packman wrote:
>
>> Given you have the generic 'juju-tal' control-bucket rather than the
>> auto-generated name which is more likely to be unique, my first
>> suggestion would be to use a different name so the container gets
>> recreated and see if that helps.
>>
>
> I tried that, but it didn't help. I added a check to
> Bootstrap._verify_file_storage to check that it can read the file without
> using the auth token (so that it fails faster). I've attached the trace
> from tcpflow. It appears that Juju tries to make it world-readable, but it
> has no effect.


The auth token is nesc on other platform's object storage implementations.


>
>
>  If I understand you correctly, the value is correctly given to swift
>> so it should just be the anonymous access that's an issue. Have you
>> confirmed you can retrieve the correct value if you provide a token?
>>
>
> Yes, that works.
>
>
>
> --
> Dr Thomas Leonard
> IT Innovation Centre
> Gamma House, Enterprise Road,
> Southampton SO16 7NS, UK
>
>
> tel: +44 23 8059 8866
>
> mailto:tal at it-innovation.**soton.ac.uk <tal at it-innovation.soton.ac.uk>
> http://www.it-innovation.**soton.ac.uk/<http://www.it-innovation.soton.ac.uk/>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20121211/5d356388/attachment.html>


More information about the Juju mailing list