<TimMc>
I'd like to test the new Etherpad in experimental using an existing grain -- but with the option of reverting the grain back to the old Etherpad (and contents) if it gets messed up. How should I do that?
<ocdtrekkie>
Currently the only way is to download backups before installing the app.
<ocdtrekkie>
With some manner of irritation you should be able to hack together an old grain if you mess that up because the app does archive the old data inside the grain.
cwebber has quit [Ping timeout: 240 seconds]
<TimMc>
Hmm... what if I cloned the grain, installed the experimental version, upgraded the grain (or does that upgrade all grains?), tested it out, then reinstalled from the regular marketplace?
<ocdtrekkie>
Okay, so it's complicated. And a peeve of mine.
<ocdtrekkie>
If you install from the market manually as opposed to the notification, as will happen for experimental, it doesn't upgrade your grains.
<ocdtrekkie>
New grains will use the new version, but you have to open the app tab, and click Upgrade Grains to get old grains upgraded, and it does all of them.
<ocdtrekkie>
However, no actual changes to the grain data happen until you launch them for the first time afterwards.
<ocdtrekkie>
So if you open only one grain, only one grain is going to actually run the changes.
<ocdtrekkie>
Eventually I'd like the grain settings page Ian added to let you change the app and/or app version affixed to a single grain on the server, but we don't have any UI for that.
<TimMc>
Hmm... and I also can't control whether other users are going to open grains during the testing interval.
<ocdtrekkie>
Yeah
<ocdtrekkie>
I believe if you were to install the app, but not upgrade grains, and then restore backups of grains you downloaded, they would restore with the latest package.
<ocdtrekkie>
So maybe download grains you wanna test, install experimental, do not upgrade grains, and restore copies of grains you downloaded.
<TimMc>
I guess I could also remove the forwarding entry in the router while I do testing. :-D
<ocdtrekkie>
Unless you rely on hairpinning for your DNS, that would also work.
<TimMc>
*nod*
<TimMc>
That would be solvable with an /etc/hosts entry.
<ocdtrekkie>
I think my restoring backups when installed is the safest though, as it guarantees your production grains aren't impacted. And restoring is just deleting.
<TimMc>
So the uploaded backup would "restore" into the new etherpad version? Interesting.
<TimMc>
I'm also curious as to what happens if you uninstall an app that has grains.
<TimMc>
Just tried it with Groove Basin. Looks like the grains stick around and are still usable, but you just can't make more grains from that app until it is "installed" again.
<ocdtrekkie>
Because the packages for apps are stored centrally for all users and only cleaned up when no grains still need them.
* TimMc
nods
<TimMc>
Hmm, something doesn't line up. If I install a new version of an app, shouldn't that only affect me?
<xet7>
Usually in WeKan, updating to new version uses migrations to upgrade database schema to newest version, it should work for any old version of WeKan. Although, at experimental is version that is broken, because newest Meteor requires newer MongoDB than is available in Sandstorm.
<xet7>
I'll figure out how to fix it
<xet7>
But I don't know how other Sandstorm apps do updates
<xet7>
I only code WeKan
<xet7>
Probably in WordPress/SQLite it just does upgrades using some similar upgrade code
<xet7>
to upgrade schema if required
<ocdtrekkie>
TimMc it only affects you but it's added to your server's pile of shared app packages.
<ocdtrekkie>
Think of installing an app as adding a shortcut to create grains with a specific package in said cache.
<ocdtrekkie>
You might install a newer Etherpad, but another user's Etherpad shortcut still links to an older package version.
<ocdtrekkie>
xet7: Basically I think this is just the first time we've had a breaking release of Meteor.
<ocdtrekkie>
Ideally meteor-spk should be upgraded to handle the migration for you so that you don't have to think about it, but we haven't yet figured out how to implement it for Sandstorm either.
<ocdtrekkie>
And of course, the new Mongo is not using an OSI approved license either, so some people will be upset about that.
<xet7>
Sandstorm WeKan has been broken many times. It's just sometimes we figure out how to fix it.
<xet7>
Yes, most likely I'll change WeKan to use SQLite. I kind of have one week remaining to deadline about how to get WeKan to use SQLite, I'll see how it goes ;)
<ocdtrekkie>
I think almost all databases should probably just be SQLite.
<xet7>
Yes
<xet7>
At some Hacker News article someone wrote that they are migrating from PostgreSQL at AWS to SQLite, because managing postgres has become too expensive, and they would like to have ability to self-host and have per-customer databases
<ocdtrekkie>
But does Meteor work with SQLite as the database?
<xet7>
Well, not yet, but Node.js has npm modules for SQLite. Node can run those Meteor parts that are required for WeKan login etc, and then use SQLite etc for other parts
<TimMc>
The OSI license silliness is so frustrating.
<TimMc>
There are so much better and more factual reasons to not use Mongo. :-)
<TimMc>
OK, so if I install experimental Etherpad and use it on an unshared grain, that shouldn't affect any other user in any way except that if *they* wanted to use it, it would "install" faster?
<TimMc>
Got a red error box on first load after trying to restore an Etherpad grain from backup: http://sprunge.us/rvwANl
<TimMc>
I'll open an issue with logs.
<TimMc>
(Emailed logs to list.)
<isd>
Ah, do you have ALLOW_LEGACY_RELAXED_CSP=false in your config? And using Firefox? If so that's a known issue.
<TimMc>
Just discovered the CSP errors. :-)
<TimMc>
Man, this works so much better than the old version.