00:14 <abliss1> should we roll back the ttrss upgrade till we solve the database migration issue?

00:16 <isd> How? there's no rollback mechanism, and if we just bump the appVersion on the old version, it will downgrade grains for people who have successfully upgraded, which will _definitely_ break them.

00:18 <isd> At this point anybody who has it installed on a live server has already downloaded the new version, even if they haven't clicked upgrade yet.

00:18 <isd> I think we need to just fix the issues asap.

00:22 <abliss1> now that we have grain cloning, i wonder if we could offer an option to snapshot the grain before upgrading, and allow the user to fallback to the old grain and the old app version if it doesn't work.

00:22 <abliss1> (isn't there a way to mark the new version experimental or something, so that whoever has already downloaded the newest version can keep it, but anyone who hasn't won't be prompted to?)

00:24 <isd> I mean, the grain cloing is pretty trivial; it just takes a backup and then immediately restores it... so I'm ot sure we're closer than we were before.

00:25 <isd> I think automatic snapshot & rollback is a good idea in general.

00:26 <isd> I have a hazy vision of a backup solution that allows us to take _very_ frequent snapshots.

02:43 <JacobWeisz[m]> We can revoke packages in the market if we want to stop more people from upgrading but I think these are minor edge cases we can fix.

02:44 <JacobWeisz[m]> Ian, I'm wondering if there's something in the log error about "initialize" failing. Is that something we do in the script we should avoid for upgrades?

02:45 <isd> The --initialize thing is red-herring; that happens even when it works.

02:45 <isd> (because we don't check whether it's already set up, relying on mysql --initialize to do the check)

02:46 <JacobWeisz[m]> Okay

02:46 <isd> Also, if we were to revoke a package in the market, would that have any affect if a sandstorm box had already downloaded the update?

02:47 <isd> because at this point it's been a couple days; I assume most boxes with ttrss grains have already downloaded the update, even if users haven't applied it.

02:48 <JacobWeisz[m]> Yeah, I'm not sure if it'd roll back the notifications to upgrade, probably not.

03:20 <isd> I'm kinda stumped without being able to poke at the grain itself.

18:04 <isd> Ug, looks like we're going to have to embed old versions of mysql forever.

20:49 <JacobWeisz[m]> I think that's really sad. We really should figure out a good story for minUpgradeableVersion.

20:50 <JacobWeisz[m]> Ideally one where the user will get the last version their grain is compatible with, and then after their grain is upgraded/run, the next newest compatible version.

20:51 <isd> Yeah.

20:52 <isd> You somehow have to make sure the intermediate version has actually successfully done the upgrade though; if you just upgrade the grain, then upgrade again without running it (or before the migration is complete), it doesn't help.

20:52 <isd> So we need some way for a grain to mark itself as having successfully upgraded to version N

20:54 <isd> But more immediately I need to figure out how to get mysql 5.5 co-existing with 5.7 in the ttrss package.

20:54 <isd> we'd still need 2 versions at a time anyway.

20:54 <JacobWeisz[m]> I almost wish we could just "repair tool" the handful of grains that break from this somehow.

20:55 <JacobWeisz[m]> And yeah, re: your issue, vagrant-spk should just handle this.

21:49 <JacobWeisz[m]> In addition to tracking whether the grain has run on a given version, we also probably need some sort of app index logic. Such that one can query the latest package compatible with a given appVersion.

22:03 <isd> yeah.