1196725 - Add ability to notify devs that another vagrant provision is required

Status: RESOLVED WONTFIX

(Tree Management :: Treeherder, defect, P3)

Description

[Ed Morley [:emorley]]

A few times recently something has changed that has required people with already created vagrant environments to re-provision, or at the least re-run ./bin/peep.py install -r requirements/common.txt -r requirements/dev.txt

eg: the django 1.8 update, switching to using dj-database-url, using whitenoise, some of the environment variable cleanup work.

Unfortunately the failures aren't always clearly due to needing a re-provision, so I was wondering if we thought having an automated way to inform people might be useful?

eg:
1) Upon vagrant provision, some marker is set in the VM with a version number (eg "1")
2) On every login (ie in bashrc) this marker is compared with an in-repo VERSION file; if the versions differ a big banner is shown after login saying to reprovision (or even just to run peep)
3) Upon reprovision, the version marker in the VM is updated with whatever is specified in-repo

(I thought about doing things like MD5ing the requirements files, but I think this is overkill - plus not all changes are backwards incompatible - we can just bump VERSION only when there is a breaking change)

Would this be useful, or have the breakages so far not been a problem?

Comment 1

[Ed Morley [:emorley]]

I think we should do this.

eg:

<jmaher> emorley: any tips on vagrant provision errors: https://pastebin.mozilla.org/8845129 ?
<emorley> jmaher: so I couldn't repro with my pre-existing (and created a few or two ago) vagrant image, I'm trying again now with a clean vagrant image to see if that breaks
<jmaher> my setup is about 4 or 5 weeks old
<emorley> jmaher: I know mauro/will made some DB schema changes recently to try and get the schema we're using closer to what we can get Django to auto-generate for us (so we can use django migrations entirely and not have this manual DB sql nonsense)
<jmaher> yeah, that would be nice
<emorley> I know mauro said some of the errors that mysql gave when using the wrong types (signed vs unsigned or things like that) weren't very clear - maybe this is one of them
<jmaher> and wlach's work on the perf stores as well
<emorley> if there's nothing you need in the DB I'd `vagrant destroy && vagrant up`, and hopefully that will work
<emorley> without django migrations (kept in-repo and have both forward and backward migration commands listed) making sure every previous DB schema is compatible with every future one (such that both old and new vagrant images work, plus stage/prod/heroku all work) is probably hard - albeit the result (ie the breakage now) is annoying in the meantime
<emorley> my new vagrant image (after a destroy and up) works for me locally fwiw, so yours should too (hopefully!)
<jmaher> it would be nice if the installation instructions had dates when major changes happened to db schema with instructions on how to reset
<jmaher> I presume we do not do a lot of db schema changes
<emorley> jmaher: I filed bug 1196725 which I think might be better? (ie rather than relying on people reading docs, have a version number in the vagrant config that's incremented)
<jmaher> emorley: even better

Comment 2

[Jonathan French (:jfrench)]

(In reply to Ed Morley [:emorley] from comment #0)
> if the versions differ a big banner is shown after login saying to reprovision

Maybe it would also be handy to include mention of destroy/up as a secondary option. Or maybe a prompt on login saying "would you like to read more about this process y/n" and if y fire the users' default browser to the suitable location (Common Tasks, Troubleshooting, etc) in RTD.

I suppose we could also notify of these changes in our upcoming blog/twitter/whatever, when relevant changes occur.

Comment 3

[Ed Morley [:emorley]]

(In reply to Jonathan French (:jfrench) from comment #2)
> Maybe it would also be handy to include mention of destroy/up as a secondary
> option. 

Yeah the example in comment 0 was just a subset of what I think we should write.

> Or maybe a prompt on login saying "would you like to read more about
> this process y/n" and if y fire the users' default browser to the suitable
> location (Common Tasks, Troubleshooting, etc) in RTD.

We wouldn't be able to open the user's browser from inside the VM.

> I suppose we could also notify of these changes in our upcoming
> blog/twitter/whatever, when relevant changes occur.

The readers of the blog etc are going to be mostly users of the UI, not developers of Treeherder, so for most it would probably mean nothing and potentially reduce the impact of our other messaging there. Even for Treeherder devs, it's quite possible they may not need to re-provision/destroy/... (depending on the current age or even existence of their VM) - the whole point of having this in code is that we inform people if they need it, but don't bother them if they don't. 

I think having cause and effect (or at least "breakage" and "useful information") as close together as possible is best for UX :-)

Comment 4

[Ed Morley [:emorley]]

Wontfix since this is much less of a problem when using docker-compose (bug 1169263).