1102239 - Advertise the BMO docker project on the BMO wiki

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Developer Box, defect)

Description

[Ed Morley [:emorley]]

IMO not having an easy way for Bugzilla contributors to test their changes is hurting the Bugzilla community. eg I gave up on working on bug 1036834 after setting up a local environment exceeded my personal "scratch-an-itch in some spare time" threshold.

Bug 1077510 is filed for checking in a VM development solution of whatever sort to the Bugzilla repo.

However in the meantime, it would be a great start if we just had docs for the current solution in the version control tools repo - since whilst it is intended for testing, dkl says he uses it fine for his everyday BMO development. If/when the v-c-t code is checked into the Bugzilla repo in bug 1077510, these docs can be trivially updated with the revised steps.

dkl: Would you be up for documenting this? :-)

Comment 1

[:glob ✱]

we'd be better off using dkl's docker image, which the v-c-t image was based off, and is designed for development -- https://github.com/dklawren/docker-bugzilla

Comment 2

[Ed Morley [:emorley]]

Ah I didn't know about that repo, I thought dkl meant the v-c-t one.

In which case this bug is really "advertise https://github.com/dklawren/docker-bugzilla in the short term before bug 1077510 adds it to the repo".

Comment 3

[Ed Morley [:emorley]]

eg I asked about a VM/dev environment not too long ago and someone (mcote?) linked to https://etherpad.mozilla.org/bugzilla-quick-start which was much less useful than https://github.com/dklawren/docker-bugzilla :-)

Comment 4

[David Lawrence [:dkl]]

Well there is currently https://wiki.mozilla.org/BMO/DeveloperBox but it is no longer relevant as the vagrant box has been removed from my people account after the last data leakage.

I will add some information to the upstream Bugzilla wiki pages that describe how to use the docker-bugzilla image I created for now. Will be at https://wiki.mozilla.org/Bugzilla:Docker once I have completed it. This will work for those just wanting to hack upstream latest Bugzilla code.

What I *want* to do soon is:

1. Refactor my docker images a bit pulling in some of the finer points of gps' version. I want to separate concerns and have the database and web servers be separate containers. Currently a single container is doing it all.

2. Clean up my work docker image (that builds on the upstream one) and package it up for general use. It will be just an empty database but running the master branch of BMO code. We cannot populate it with any data due to privacy concerns etc. I will then put this all in github/dklawren/docker-bugzilla-bmo (just the build scripts)

3. Update https://wiki.mozilla.org/BMO/DeveloperBox describing how to checkout the github registry, build the image and then use it for BMO development.

4. I will probably not host it in the Docker Registry like I do the upstream one as that would be a grey area probably with legal.

Sound good?

dkl

Comment 5

[Ed Morley [:emorley]]

Yeah that sounds good :-)

I'm trying to get started using the steps at https://github.com/dklawren/docker-bugzilla/blob/master/README.md

However these aren't sufficient for people using boot2docker to be able to edit the source on the host and hit refresh and see changes. The boot2docker and boot2docker-cli documentation leaves a lot to be desired, but here's what I've figured out after several hours of frustrating reading of PRs, inaccurate readmes and stackoverflow posts:

* There's been a recently added "--vbox-share" option added, but it's not listed in the readme (issue filed) and it doesn't work as expected (will file an issue shortly).
* Instead, to share a source directory on the host, that isn't within your (automatically mounted) user directory (eg C:\src) - the steps are as follows:
1) Either use the Virtualbox UI to add a shared folder mapping (eg "C:\src" to "c/src"), or use VBoxmanage.exe:
$ /c/Program\ Files/Oracle/VirtualBox/VBoxManage sharedfolder add boot2docker-vm -name c/src -hostpath /c/src
2) boot2docker up && boot2docker ssh
3) Inside the boot2docker VM:
$ sudo mkdir /c/src
$ sudo mount -t vboxsf -o uid=1000,gid=50 c/src /c/src/
4) If all worked, /c/src/ in the Boot2Docker VM should map to C:\src in the host.

Now theoretically, all we have to do is use docker's "-v" option to "Mount a Host Directory as a Data Volume":
https://docs.docker.com/userguide/dockervolumes/

However, using this run command:
$ docker run -d -t --name bugzilla --hostname bugzilla --publish 8080:80 --publish 2222:22 -v /c/src/bugzilla/:/home/bugzilla/devel/htdocs/bugzilla dklawren/docker-bugzilla

...means visiting http://192.168.59.103:8080/bugzilla/ gives an "unable to connect", which wasn't present when omitting "-v".

This is apparently because the volume option is equivalent to mount, ie: the existing directory will be overwritten. Helpfully again, the dockervolumes docs don't mention this (issue filed for fixing the docs), suggested workarounds at:
https://github.com/docker/docker/issues/4361#issuecomment-36317097

Now I'm presume this could be fixed by a reworking of the Dockerfile/base image to use a separate data volume - but I'm not familiar enough with Docker for it to be worth starting along that route for now.

My hacky workaround for now, was to instead create the mount at another point and copy the files across, ie:
$ docker run -d -t --name bugzilla --hostname bugzilla --publish 8080:80 --publish 2222:22 -v /c/src/bugzilla/:/home/bugzilla/devel/htdocs/bz dklawren/docker-bugzilla
$ ssh bugzilla@localhost -p2222
(password: bugzilla)
$ cd devel/htdocs/bugzilla/
$ sudo cp -rfL . ../bz

And then use:
http://192.168.59.103:8080/bz/

I can then edit the source files at C:\src\bugzilla and have the changes take effect in the VM.

This is still quite a lot more involved than a simple |vagrant up| that TBPL/OrangeFactor/... can do from the srcdir on the host, but at least I have something that works now. Thank you for creating the docker image :-)

Comment 6

[Ed Morley [:emorley]]

One extra step:

Due to the way that Virtualbox shared folders/docker/... interact with NTFS file permissions, when performing a git diff on the host machine, I was having spurious file permission changes showing up (that couldn't be gotten rid of using chmod inside the boot2docker VM or the Bugzilla container itself, or even a |git reset --hard HEAD|). Instead using |git config core.filemode false| hides the issue (from http://stackoverflow.com/a/1257613).

Eugh.

Comment 7

[Ed Morley [:emorley]]

Bugzilla's .gitignore also needs some additional entries (another advantage of checking this into the bugzilla or bmo repo):

[/c/src/bugzilla]$ git status
On branch master
Your branch is behind 'origin/master' by 71 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        Build
        MYMETA.json
        MYMETA.yml
        _build/

Comment 8

[Ed Morley [:emorley]]

Filed the following:
https://github.com/boot2docker/boot2docker/issues/647
https://github.com/boot2docker/boot2docker-cli/issues/313
https://github.com/boot2docker/boot2docker-cli/issues/314
https://github.com/docker/docker/issues/9296
https://github.com/docker/docker/issues/9297

Comment 9

[Ed Morley [:emorley]]

This was done a while ago:
https://wiki.mozilla.org/BMO/DeveloperBox