Persistence in charms

[Gary Poster]

On 02/24/12 13:59, Clint Byrum wrote:
> Excerpts from Gustavo Niemeyer's message of Fri Feb 24 06:36:45 -0800 2012:
>> Hey Gary,
>>
>>> Moreover, wanting a public url for these kinds of persistent files--logs,
>>> database files and the like--seems like it would be the exception rather
>>> than the rule.  Having them shared privately seems more commonly desirable.
>>
>> It sounds like you're asking for a file server.. this fits quite well
>> as just another charm that your charm can require. It can be as simple
>> as a webdav server that provides an authenticated https base URL
>> through the relation data, and as complex as a deployment of ceph's
>> object store.
>>
>> Wouldn't that solve your problem?
>>
>
> I think it would solve the issue, and we could probably even build the
> stash tools as part of charm-helper to make easy for all charms that
> need that functionality to make use of it. I already have a few cases
> where clusters can make use of seed-data to initialize new members and
> right now there are 3 or 4 different ways that is happening in charms.
>
> However, Juju always has access to a read/write object store, so it
> seems natural that it would abstract that away and give the users a
> means by which they could make use of it in charms. This needs careful
> consideration, but I think ultimately its a nice 2nd toe in the water
> for persistence (the first toe being EBS volumes on EC2).
>
> A file server charm would eat up another machine on ec2 for something
> that would only be in use during charm configuration operations. Fine if
> you have constant churn, but pretty wasteful for the average use case.
> Perhaps better than a new cli for this would be an assumed virtual service
> that is always available for relating, which is the object store that
> is in use for charm storage.

In our discussions, we thought it might be nice to have the persistence 
buckets separate from the main Juju bucket.  You have more control of 
them at a cheap cost.  Maybe that's a small point, and I'm not prepared 
to argue it (but Brad might remember the points better).

> I like that because we can move forward with it as a charm, and if it
> proves widely useful we can move it into juju core.
>
> So, Gary, for your use case, a simple webdav charm would make sense,
> and then add a relation for talking to it in your charm, which would
> then store/retrieve the files as needed.

If I understand you, a webdav charm means that I store my data in 
another transient instance in the same Juju environment.  That doesn't 
buy me anything compelling that I can see yet.

More compelling to me ATM is a stash subordinate charm interface like 
the one Gustavo mentioned. Sure, it could then have a webdav 
implementation that stashed things on some other public IP not in the 
same Juju environment that provides more stable guarantees.

Thanks again for thinking about this,

Gary