<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 13, 2016 at 6:03 PM James Beedy <<a href="mailto:jamesbeedy@gmail.com">jamesbeedy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">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.<div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg">A few general questions concerning resources:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">* Can I access different versions of a resource through api/cli?</div><div class="gmail_msg">    * 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)?</div></div></div></div></blockquote><div><br></div><div>So you have api access at the charmstore level. You can see the latest resource and any specific revision that's in the store. </div><div><br></div><div>Docs: <a href="https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#get-idmetaresources">https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md#get-idmetaresources</a></div><br class="inbox-inbox-Apple-interchange-newline"><div>e.g.</div><div><a href="https://api.jujucharms.com/charmstore/v5/meta/resources?id=~containers/kubernetes-worker">https://api.jujucharms.com/charmstore/v5/meta/resources?id=~containers/kubernetes-worker</a><br></div><div><a href="https://api.jujucharms.com/charmstore/v5/meta/resources/kubernetes/3?id=~containers/kubernetes-worker">https://api.jujucharms.com/charmstore/v5/meta/resources/kubernetes/3?id=~containers/kubernetes-worker</a><br></div><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">* 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`)?</div></div></div></div></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">* 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?</div></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>Rick</div><div><br></div></div></div>