Versioned Resources

[Rick Harding]

On Sun, Nov 13, 2016 at 6:03 PM James Beedy <jamesbeedy at gmail.com> wrote:

> Do we have access to managing separate versions of a resource
> pragmatically? To give some context, I'm trying to implement rollback
> functionality for resources deployed in our applications. Implementing
> rollback is proving difficult because I don't seem to know how to access
> different resource versions from the reactive framework.
>
> A few general questions concerning resources:
>
> * Can I access different versions of a resource through api/cli?
>     * e.g. what if I want to roll back to a different version of a
> resource pragmatically (do I have to do this manually, or can I access
> different versions somehow through charmhelpers or other lib)?
>

So you have api access at the charmstore level. You can see the latest
resource and any specific revision that's in the store.

Docs:
https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#get-idmetaresources

e.g.
https://api.jujucharms.com/charmstore/v5/meta/resources?id=~containers/kubernetes-worker
https://api.jujucharms.com/charmstore/v5/meta/resources/kubernetes/3?id=~containers/kubernetes-worker

What we don't have is that level of access from what's in the model. You
can get the current information about the revision of the unit, but there's
not a direct call to be able to do something like a rollback. It's a
forward only situation. You could reupload the resource with an attach.
We'll have to think about this use case and see if we should tweak the API
towards this end.


> * Does `juju attach <application-name> <resource-name>=<resource>` upload
> the resource to the controller, or to all application units, or both (is
> this just done in one single swoop through on `juju attach`)?
>

It uploads it to the controller. What is nice is that it is deduped there,
so if you reupload a previous resource, the revision in the controller will
go forward, but you don't get 2x the storage there. After the controller
get it, it triggers an upgrade-charm hook on the units that should cause
them to go get the new revision and update. You can use the juju resources
command to track what revision the units are at as it populates through all
the units.


> * Is pushing a charm to the store with a new version of the resource, then
> upgrading the charm on the controller:model seem like a best practice here
> for rev'ing resources and keeping controller:model resource in sync with
> the charm store resource?
>

It's meant to be the best way to help have repeatable deployments by only
releasing the charm with the revision of the resource that works best with
it. It's best if the goal is to help provide the published tuple of charm
revision and resource revisions that work best together.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20161113/623f4638/attachment.html>