Upgrade action should mount the previous bundle

[silvin-lubecki]

The current bundle is mounted in the invocation image, as stated in #196 . So during upgrade we only have access to the new bundle, not the previous.
But I think some invocation images would need the previous bundle to compute a diff (ex: are there new services? Did the port changed? Should we delete a service ? etc..) and apply specific actions.
As the previous bundle is stored with the Claim, we should be able to mount it next to the current bundle.

[carolynvs]

It would be incredibly helpful to have the entire claim available to the bundle on subsequent actions (not just upgrade). That would give the bundle, previous outputs and parameters used.

[technosophos]

The currrent version of the spec says:

The claim MUST be mounted at the path /cnab/claim.json inside of the bundle. The version of this claim that is to be mounted is the version prior to this operation beginning. In other words, when a bundle is installed, it creates the original installation claim. On the first upgrade, the claim describing the installation is located at /cnab/claim.json. This allows the invocation image to inspect the former state and compare it to the desired new state.

So what we want is something like /cnab/current/claim.json and /cnab/last/claim.json?

[vdice]

My initial opinion/reaction was that mounting just the one claim in its current form to /cnab/claim.json, as is now mentioned in the spec, is sufficient. Then, if deemed appropriate, various states would be tracked in this one, updated claim (perhaps preserving a record of state for all previously run actions). However, if we go the route of capturing and preserving state across all actions, this one claim has the possibility to grow quite large.

On the other hand, I wonder if mounting a claim for each action in the appropriate sub-folder may be a preferable option. As opposed to above, each claim would be an immutable record of state tied to an action. I could see them being mounted to locations such as /cnab/install/claim.json, /cnab/mycustomaction/claim.json, etc. (this is going a step further than current vs last). This would have the advantage of smaller claim file sizes, but perhaps more complex code to store/fetch/process any/all claims in a given action.

[silvin-lubecki]

@vdice I like your idea of splitting into multiple directories, but what would be the claims mounted? The last claim of that action? Or the last successfully applied action claim?

[vdice]

@silvin-lubecki oh right, I see I missed that fundamental point of the original issue... good question. Hmmm... what do others think?

[technosophos]

I should have been clearer in my last message.

The design of the claims system originally was that if there was a previous version of a claim, it would be accessible. Then the action would occur. Then a new version of the claim would be stored.

So on install, no claim exists (because there is no previous claim). At the end of the install action, a new claim is created.

But say we upgrade that installation. The upgrade then has access to the claim generated by the install action. That way, it can retrieve the state that install stored.

As I understand it, what @carolynvs is asking for is that the new (not-yet-saved) claim also be accessible. I'm trying to gauge whether this is generally useful and how we might do it.

On top of all of that, @silvin-lubecki 's original request I guess had nothing really to do with claims, so maybe this whole thing is veering off-topic.

So to get all the way back on topic... @silvin-lubecki, the current draft of the Claims spec now has bundle as one of the fields. This will have the bundle.json (in its entirety). And per the spec, it will always be the last bundle.json that was used. Is that good enough to satisfy your initial requirements?

[carolynvs]

I was asking that the previous claim be mounted, i.e. if we just did an install and are now doing an upgrade, mount the claim from the install. At the time of my comment, this was not in the spec or implemented in any runtime.

I wanted to be able to access outputs generated from the install action, or see parameters used during install.

[silvin-lubecki]

@technosophos yes that would satisfy my initial requirements, but if I understand the specs correctly, we will always mount the last claim, resulting from the last action, whatever it was successful or not.
So if I try to update my app and fail, say because I made a mistake with one parameter, then fix it and try to update again, the claim mounted would the one with the mistake right, not the one resulting from the installation or the last successful update. So I might have hard time to process a diff between the current bundle I want to apply and the previous one.