Persistence in charms

[Gustavo Niemeyer]

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?

> Unless I misunderstand, they cannot abstract away the environment--lxc or
> ec2 or maas.  In our discussions, we think charms ought to be able to say
> "stash this file" and "give me back this file" without having to worry about
> whether the stashing happened in an S3 bucket, a directory somewhere in the
> LXC host's filesystem, or whatever the maas equivalent is.

Right, that sounds like a perfect fit for a well defined "stash"
relation that charms can depend on.

> The approach to this that I like best would be for Juju to simply provide a
> mounted directory in a known/documented location that promises to be a
> persistent store for the machine, if such has been configured. The charm
> simply looks for that directory, and uses it as it wishes. That could be
> easy to use, powerful, and fairly easy to implement (I suspect).  It would
> not even require writing any hooks.

People will have different requirements for the storage depending on
what they're doing. I don't think we should try solve that problem
internally for everybody in a constrained way.

> Alternatively, we could have something like the two commands you mentioned,
> but put-file would not return anything, and get-file would simply take the
> same name.  For instance, if you wanted to stash

get-file was discussed at UDS in a different context. It aims to solve
a different problem than the one you're looking at.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.