Hawthorn Docker Devstack

[Uman Shahzad]

Hi,

I'm wondering if edX has plans to support a separate Hawthorn branch for the docker devstack repo?

Right now doing development for Ginkgo instances with the docker devstack is basically impossible unless you had saved images for all services when they were on or close to the Ginkgo branch, and probably other things besides the images like the commit in the devstack repo itself.

Going forward, it'd be lovely if we can have a Hawthorn branch on the devstack repo where the images downloaded from Docker Hub are tagged for Hawthorn separately from the latest master images.

If this won't be done upstream, I'm willing to do it on my own and share that with the community, but that could lead to some unnecessary fragmentation.

Thanks,

--

Uman

@OpenCraft

[Jeremy Bowman]

We do plan to create Hawthorn-tagged Docker images for all the Open edX services, built from the appropriate branch in each repository.  We hope to have that done for the upcoming Hawthorn beta release, here's the JIRA ticket for tracking that: https://openedx.atlassian.net/browse/OPEN-2219 .

One of the things that makes it difficult to use Ginkgo with the Docker devstack repo is that each of the services needed a number of configuration changes made after the Ginkgo release to work correctly in that environment, which was beyond the scope of changes we normally consider appropriate for an already released version of Open edX.  Moving forward, each release should have everything needed to launch and maintain a Docker-based devstack for it, including a release-specific branch of the devstack repo.

Jeremy

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CA%2B_6%3DJ6-7TeQ3bNTbQUPX%2B%3DFGYC5-BUaemKCE_3vp8R7U7kQPQ%40mail.gmail.com.

--

Jeremy Bowman

Principal Software Engineer

edX

141 Portland St.

Cambridge, MA 02139

jbo...@edx.org

[Uman Shahzad]

Awesome, thanks a lot! This'll be tremendously useful.

Makes sense on the Ginkgo issues. Very glad we'll have a working docker-based devstack for Hawthorn, though.

--

Uman

@OpenCraft

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CABQueNm_w7hr5W1D-eoi4AA1RsYyvL%3Dkw0NKO0%2Bkcf-deBf%2B-w%40mail.gmail.com.

[Régis Behmo]

Are the Dockerfiles for this devstack already available somewhere? Do you plan on making them available?

Régis

[Jeremy Bowman]

The Dockerfiles are under the docker/build directory of the configuration repository, there's also some documentation about them there: https://github.com/edx/configuration/tree/master/docker

The code for connecting them and using them together as a development environment is in the devstack repository, along with more documentation: https://github.com/edx/devstack/

When Hawthorn is released, the official developer-facing documentation for devstack will be updated to recommend this instead of Vagrant.  The current Docker-based devstack code is being used by developers at edX and elsewhere working on the master branches of the Open edX repositories; it's being actively polished and improved, so please let us know if you hit any problems using it or find any notable gaps in the documentation.

Jeremy

On Wed, Apr 18, 2018 at 1:44 AM, Régis Behmo <re...@behmo.com> wrote:

Are the Dockerfiles for this devstack already available somewhere? Do you plan on making them available?

Régis

--

You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/656635de-a595-4a55-ba5d-ad81d846d225%40googlegroups.com.

[Régis Behmo]

Thanks for your answer Jeremy! I couldn't find the Dockerfiles because my local edx/configuration repository was at an old version.

It's really too bad that building the standard devstack will now require both the Ansible playbooks and Docker containers. I know I am not forced to use them (and I won't) but my intuition is that this is going to make Open edX even harder to use than it already is for new developers.