dw_dev | Dreamhack reinstallation dilemma

Entry tags:

Dreamhack reinstallation dilemma

As most people here will know, I'm the maintainer of the Dreamhacks service which allows you to have a Dreamwidth development environment quickly and easily.

Some people will also know that lately the reinstallation script hasn't been working for some time. It's been broken ever since the move to git and GitHub, and I recently put a check in there so that anybody trying to use it won't accidentally end up with an unuseable 'hack. (By the way, if anybody does have an unuseable 'hack because of this, please feel free to let me know and I'll gladly reinstall you by hand!)

Although it should be fairly easy to get the reinstaller script working again, I've been running into some issues that I'm not entirely sure how to address. If you have a Dreamhack account, please read inside the cut as this could quite possibly affect you.

The point of the reinstaller script back in the Mercurial days was so that if you end up with a 'hack that you didn't know how to fix, it would be possible to easily get back to a working state by reinstalling your Dreamhack account as if you were a completely new user, without you having to worry about bothering anybody. You'd lose your work in the process unless you had backed it up, but you'd be pretty much guaranteed a working 'hack and being able to get back to somewhere you knew. A lot of people used it and I've heard from a lot of people that it was really helpful.

It worked because the previous setup procedure for Dreamhacks meant getting a completely fresh copy of the code straight from the official repository, so unless any bugs had been committed into the official codebase, it would be guaranteed to work as expected.

However, this isn't the case any more - the setup process for Dreamhacks now involves forking the official repository and setting up the Dreamhack to pull from that repository instead. As a result, if you've already pushed the commits that broke your Dreamhack to your own repository, a reinstall wouldn't help because it'd just pull the broken commits straight back down. It may not even fix a broken repository, depending on the situation; all in all, there's no guarantee any more that the reinstall process would get you to a known state any more. It would all depend on what you had pushed to the repo before you reinstalled.

I have an idea for how this might be fixable, but it would require a fair amount of code on my part and I want to be sure that it's worth it, so I thought I'd come to you guys for ideas!

My own idea involves something I've been planning for a while anyway - the ability to link Dreamhack SSH accounts with GitHub via OAuth. It would take some work, but with this in place it would be possible to have a reinstallation process that could (after making VERY clear what it would do) delete your dw-free/dw-nonfree repositories on GitHub and re-fork them automatically, either as part of the process or (more likely) as a separate script which you could run beforehand. The reinstallation could then proceed using these newly re-forked repositories, and the end result would be almost exactly the same as what you would have had under the old script - code that comes straight from the horse's mouth, as it were, and an almost-sure guarantee that you would get a working 'hack out of it, bar any bugs in the official codebase.

It's probable that something like this would be best implemented as two scripts - the reinstallation script as it is right now (or at least as it would be if it were working) that uses your current GitHub repositories, and a script you could run beforehand if you wanted to to do the deleting/re-forking. I think this would be the best way, personally, because the main reason to have the reinstall process is to make it quick, easy, and not require many spoons. While having two commands to run does take some more spoons, I believe that it's worth it to stop people from accidentally wiping out all their work (since people wouldn't normally expect a reinstallation on the Dreamhack machine to affect GitHub).

However, these are just my ideas. It's quite possible that people here have better ideas, and that's why I'm here. Do you have any ideas about how the reinstallation script should work? Is the process I've outlined too easy to accidentally activate, too difficult to work with, or something else? Things like that. The Dreamhack machine is your resource and I want to make it as easy as I can to hack on the code while not getting in your way. How can I do that in this case?

Flat | Top-Level Comments Only

I don't have any suggestions, but I do think this all sounds good. Thank you. <3

That's certainly a very solid, awesome way of doing it, and would be best from a user-experience-and-ease point of view. If you have the time and energy, that'd be awesome.

That said, there are certainly easier ways to do it, and I think it would be perfectly reasonable to give users a set of commands to run. Something like... when you trigger a reinstallation, it first prompts you to reset your forks with some sort of "hi! to do this, this will DELETE YOUR CHANGES ON GITHUB! you have to do..." and then give them some git commands to run.

So the process would actually check out official dw-free/dw-nonfree repositories, then it would prompt the user to force push those up to their own github forks.

I think that'd be perfectly acceptable, too.

I agree with this. I think "nuking your DH and reinstalling" should be for "I have broken everything so badly that it's easier to just delete everything and start over", and if the problem is "my github account is in some horrible state that i could fix via painstaking work but that would be annoying, but my actual hack is pretty much fine", we can provide a set of commands for them to do/steps for them to take that would fix it. (Which, yes, might involve deleting forks and reforking.)

I'd be really nervous about the dreamhack reinstall script nuking your GH fork and stuff. I can see a lot of situations where you wouldn't want that to happen.

Well, in my proposed method, it would be optional as to whether you GH fork was nuked and re-forked, since it would be implemented as two separate scripts. You wouldn't have to run the nuke-and-refork script if you didn't want it done.

Does that make things any better?

I'm not at all familiar with the Dreamhack environments, so I may be way off here. But it feels to me that deleting and re-forking repositories is the wrong solution, if nothing else so because it throws away history. If I understand correctly what you're trying to do, it should be able to do it by playing around with branches.

First, a repo can have more than one remote. When you clone from a remote repo (like, for example, one on Github), git automatically creates an "origin" remote pointing back to where you cloned from. But that's just a convenience, there's nothing magic about it. You can add new ones just fine. With forked repos on Github, it's often useful to add one pointing back a the repo one forked from. In this case, that might be something like...

git remote add ur_source https://github.com/dreamwidth/dw-free.git

You can then fetch from that, base branches off of it, and if I understand the problem correctly that should do fine as the pristine starting point.

I think (but I haven't actually tested) that a reset process might go something like this, assuming ur_source is set already and the messed-up work is done on the local master branch:

1) Fetch from ur_source.
2) Rename the current master branch (git branch -m) to something predictable and auto-generated, just to keep history.
3) Create a new master branch based on remotes/ur_source/master.
4) Set the new master to track the old remotes/origin/master.
5) Push back to Github with --mirror to force it to look like the local repo.
6) Proceed working on the new master branch.

One possible drawback is that any local branches made from the messed-up master would still be based on that, and have the problems intact. I'm not sure if that would be a problem or not. Nor am I sure if all this works at all, I just think it should. It shouldn't take that long to give it a manual try, if you think it looks like it might be useful.

Thanks! You're right, deleting and re-forking will throw away history. Let me explain a little bit about what's happening here, though, to make it a bit clearer as to why I think this is beneficial in this case.

Firstly, a bit of background: A lot of our developers are fairly new to git, and in fact to programming in general. One of the aims of the Dreamhack box is to provide a playground to encourage messing around with the code without fear that anything you do will mess up your Dreamhack beyond repair, because if you're not sure whether you might mess things up, it can really get in the way of experimentation. Yes, people can always ask me for help (and I'm always open to helping people!), but it's a fact of human nature that you generally don't want to bother other people with problems that you consider to have been your own fault, especially if it's something that sounds like it should be major, like reinstalling your account or unbreaking your Dreamhack.

When it worked, the reinstaller script could be triggered by running a single command. Within a minute, the reinstaller would warn you what it was going to do. Within another minute, it logged you off the system, killed all your processes, deleted your user account and everything associated with it, and then set you back up again as if you were a completely new user. In total, it took about 5-10 minutes, and you would be back up and running again, being guaranteed a working Dreamhack without having to talk to a soul. That sort of guarantee is invaluable in a "playground" environment such as this. (I'd call it a sandbox, but it isn't a sandbox in the true technical sense of the word, hence "playground" instead.)

OTOH, while you're almost certain to be able to get back to a working state with git in the way you describe, there are several reasons why that might not be the best method. From a technical perspective, the local git repository may be corrupted in such a fashion that it just doesn't work as expected. From a psychological perspective, because git never throws away commits, you'll still know that your old "baggage" is still in there somewhere, which might throw you off. You would also need to make sure your old branches were deleted, otherwise you might accidentally refer to them in a future command and end up with something wholly unlike what you expected.

Deleting and re-forking on GitHub, then reinstalling the local user account, is by far the easiest way to deal with these problems. (Why not just clone the re-forked repository back to the user account? Because it's not just repository problems that can affect your Dreamhack. Each Dreamhack has their own Apache configuration file which can be edited as need be, and it's possible - though unlikely - that if you were editing the config, or removed the file totally, you could break your Dreamhack that way. While it would be easy enough to fix - and in fact I may just make a script to make it easy to replace your Apache config file if need be - it's another thing that can go wrong.)

All told, it's about three things - a guarantee that it's going to work as you expect it to, a psychological guarantee that you're not going to have anything left that could mess it up, and the knowledge that you don't have to tell anybody if you don't have the spoons for human interaction; you can just reinstall and continue hacking.

Hopefully that helps clear up why I think doing this is the best way in this case!

Edited (Removing the assertion that deleting and re-forking on GitHub is the "best" way to deal with the problem; after all, finding the "best" way is what this whole post is about.) 2013-06-26 21:27 (UTC)

Can I just say, I really appreciate how the spec discussion for this takes into account psychological issues for newbies!

Yesyesyes! Me too.

Sounds like solid reasons, yes. And thanks for explaining rather than just agreeing that I was way off :-)

What about doing something along the lines of:

rm -rf $LJHOME
git clone https://github.com/dreamwidth/dw-free.git $LJHOME
cd $LJHOME
git remote rename origin dreamwidth
git remote add origin https://github.com/[username]/dw-free.git

And then prompt the user whether or not to pull from their origin? If they try it and pull, and the hack is still broken, they can run it again and not pull, and telling it not to pull will also tell them how to go about recreating their forks?

Edited 2013-06-26 20:58 (UTC)

That could work (with appropriate --set-upstream branch commands, etc), but it's possible that there might be problems that are outside of the repository. I talk about that in my reply to cdybedahl above, among other things.

It's definitely something I'll consider if it turns out to be something which works out better though!

Edited 2013-06-26 21:24 (UTC)

My gut feeling on this is that it might be automating a bit too much.
It seems that there are two nearly separate things going on,

1. Nuking and re-forking the github repo
2. Producing a clean Dreamhack account with a clone of this repo.

Part 2 is something that we should absolutely have an updated script for.
Part 1... I'm not sure that it isn't best just to ask the user to do this. They already know how to fork from the main DW repo, because they had to do that when they started. So it should be very straightfoward to delete their own repo and re-fork. We could even provide instructions... but my gut instinct is that automating that away adds a lot of complexity (need for OAuth and so on) without much gain, and also risks making it harder for people to learn / understand what is going on.

Just my 2p - I'm probably not quite the target audience :-)

Well, part 1 and 2 would be being provided by two separate scripts in my proposal. The reinstall script itself would only cover part 2, while part 1 would be a separate script which you could optionally run (or not) before doing the reinstall process.

As for needing OAuth, I've been wanting OAuth support for some time now, because that allows for a whole load of other things too, like the possibility to have a script to let you create pull requests directly from the command line without needing to go to the website. So it wouldn't just be for this project.

Do these points make it any different for you?

Well, if you want oauth anyway, that's certainly one less factor against.

I guess this is part of the "how much do we insulate people from git" discussion - and for me I kinda feel that if users don't know how to delete a repo on github and fork a repo on github (the latter being something they must have done anyway), they probably ought to learn?

Not a big deal, just a thought:-)

Fair point!

For me, I'm not coming at it from a "trying to insulate people from git" discussion as much as a "how to do this in a manner that conserves spoons". Deleting and re-forking on GitHub is fairly easy, true, and as you mention they would have knowledge of the forking part of it anyway. In fact, I've been going back-and-forth in my mind about how necessary the separate script is myself (vs. manually deleting and re-forking if you need to do that).

Certainly, I think more discussion is needed on this. I've given an overview of where I personally am coming from in a previous comment, and while nuking/re-forking is definitely destructive and not what most people would recommend, I think that it does have its advantages. Is it the best option? I'm still not entirely sure, but I'm leaning towards "Yes". (As a separate optional script, like I say.)

As I understand your comment, the thing here is that this is not primarily a technical problem. The primary problem (or perhaps it's better to call it a task) is psychological. There are, as has been pointed out, several ways of solving the problem technically, with various sets of of pros and cons. Your suggested way, deleting and re-forking on Github, may not be the most elegant from a technical point of view, but I think it's the best from a psychological angle. I started out looking at this with my work eyes, where "never lose information!" is a high priority. But that's not relevant here. Here, it's a question of letting a user go "toss this mess and start over". From that point of view, nuke-and-refork is clearly superior to at least my suggested way of juggling branches. Partly because it's a more robust way of getting out of any possible git problem, but also -- and more importantly -- because it's a lot easier to understand, and that's important for a user who's feeling unsure. You can explain it in one short sentence ("We remove EVERYTHING and start over"). My method? Not so much with that, no.

Also, given this, I think that just having one script is the better choice. With the goal of making an unsure user feel safe(r), fewer options is better.

I like the idea of having two separate scripts, one for just wiping your Dreamhack, and one for wiping your whole fork.

I do like the idea of separating the two things into two separate procedures. My gut feeling is that most Hideously Awful Mistakes do not involve pushing the Hideous Awfulness to github, but I may be wrong there? I suspect that most newbies to git - like me - will be so scared to do Something Awful to git that we don't push things there if there's a chance it's not right...

I don't particularly have any opinion in the part about whether the first section should be a script or not. I don't think there's value in making it NOT be a script - newbies just cut-and-paste the commands anyway, without always stopping to understand. But on the other hand I don't particularly *mind* cutting-and-pasting so either would be fine as long as it gets the job done.

But anyway I wanted to post here just to say I have almost nothing on my 'hack that isn't 'stock' and I'm happy to mess around so if you're looking for a user to test things let me know :) I love that stuff!

Adding for reference: Bug 1541.

Hi Sophie, sorry for the delay, I've only just gotten official permission from my employer to get involved. I tried the reinstall script (a while back) and have an unusable 'hack, I'd be very grateful if you reinstall it.

Hi! Sorry for my own delay, too. :)

I'll gladly reinstall you. Do you have a GitHub account? If not, you'll need one before I can reinstall you. Once you have a GitHub account, you'll also need to fork Dreamwidth's dw-free" and "dw-nonfree" repositories. To do this, after you've created your account, you'll need to go to each of these pages linked above and click "Fork" at the top right.

After doing this, you'll have your own copy of the code. Then, to reinstall I'll need to know your GitHub username, so I can set your account up with your repositories specifically. (I don't need your password.)

Also, do you have anything you want to keep from your account? The process will wipe any patches or anything you have there, so if you have anything you want to keep, you'll need to take care of that first.

Hi, thanks for getting back to me :)

My github account is also 'chebe'. I've forked the two repos (dw-free might be a bit old, hope that doesn't matter).

I don't need to keep anything there, go ahead, blast away!

*excited*

I can work with the repos you have, but there's been a database change since then and you'd need to update it after it's been installed. If you haven't made any changes to your forked repos yet, it may just be easier to delete it from GitHub and to re-fork it before the install is done. If you have made changes, then it'll be better to update it directly using git before we reinstall the Dreamhack. (In fact, if you already have git available then it'll be easier in any case to do it that way - and you'll learn how to do that as part of working with your Dreamhack anyway - but since many people don't have git on their computers, I'll explain the delete-and-refork way.)

To delete the repositories from GitHub, you'll need to go to the Settings tab on your repositories at:

* https://github.com/chebe/dw-free
* https://github.com/chebe/dw-nonfree

Click on the "Settings" tab on the right, and then once at the Settings page, at the bottom you'll find a red box marked "Danger Zone", with one of the options being to delete the repository. Click that button and then type "chebe/dw-free" to confirm (and "chebe/dw-nonfree" for the other one, of course). Then, you can fork the repositories again using the instructions in the other comment.

Let me know how you want to continue and if there are any problems!

*nods* Not at my dev machine, so I deleted and recreated. Thanks for the walkthrough. Continue at will!

Hi, thanks again for your help. Just another question. I was trying to create a branch and I got a permission denied error. It happens when I try to do anything with git. I had a look and all the git stuff is owned by root. Do we need to change permissions, or chown? Or am I missing a step?

Hi!

Yep, you're missing a step - you need to be somewhere within the ~/dw/ ($LJHOME) directory before you can do any git commands. The git repository you were looking at is the repository for the Dreamhack machine itself, not your Dreamhack installation.

A lot of people are getting caught out by this so I'm tempted to see if I can make something that can help in this case.

Ah yes, perfect. Thanks again. Maybe just add a line to Version Control saying you should be in $LJHOME?

Just realised I never replied to this when I made that change about a week ago! It's the "Important note" section at the top now. :)

Edited (Removing redundant sentence.) 2013-09-17 11:09 (UTC)

Flat | Top-Level Comments Only

Dreamhack reinstallation dilemma

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject