Juju and snappy implementation spike - feedback please

[John Meinel]

>
> ...
>


>
> The big difference to me is that $SNAP_USER_DATA will roll back if the
> snap is rolled back. I'm not sure what happens if the snap is removed and
> reinstalled. Given end users should no longer need to be messing around
> with the dotfiles, I think the rollback behaviour is what should drive your
> decision. Is it nice behaviour? Or will it mess things up because rollback
> will cause things to get out of sync with the deployments?
>
>
>
So the conceptual "we can make changes to how juju.conf is written and have
it roll forward" sound nice, but in actuality we're quite used to not doing
that, and the problem of "I upgrade Juju, and bootstrapped a new
Controller, and then reverted my Juju version, and can no longer access the
old controller", actually puts versioned config into the bad column.

But snaps have "common" to handle that sort of case, where each version of
a single snap series can use the same data store.

What I haven't heard a specific answer for is, I want to run
"juju-wallyworld" or "juju-menno" or official "juju" and have them all see
the same controllers and accounts. And honestly, if I was running
firefox-custom-build I really don't think I'd want a different set of
bookmarks.

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160809/fdb3c72f/attachment.html>