Open usernamenumber opened 9 years ago
Installing edX using the configuration repo should be fairly easy, I suggest we fork the configuration repo and do some customization to run edX for now ... Then I think integrating this repo into a configuration repo fork would be easier than going the other way around.
what do you think ?
It may be possible to use the edX playbooks without forking them (and then having to maintain our fork), by running their roles and playbooks without modification other than maybe overriding some of their variables, which can be done without modifying the role/playbook files.
I've done some research on this, and I see a couple of ways this could (hopefully) work:
If we want to base our systems on a standard edX install, we can create a top-level playbook that just includes a mix of their playbooks and ours. For example, suppose we added the edX configuration repo as a subtree or submodule under /edx
in our provisioning repo. Then, in the root of our repo, added playbook that looks like this:
---
# edX, which also includes, mongo, nginx, and other stuff we want
- include: edx/playbooks/vagrant-fullstack.yml
vars:
# Optionally, I think we could override vars in the edx playbook here,
# but I'd have to experiment-- not certain that it gets precedence.
# Everything else we want that isn't included in the above
- include: ansible/main.yml
This wouldn't work on ARM, of course, but at least for now we can just use the image Arturo has made, which already includes edX, and use only our playbook when deploying to ARM.
If we need more flexibility, we can set a custom roles_path that includes the edx roles as well as our own, then pull in the individual roles that we want.
Thoughts on these?
Some further notes on ways to approach this. I think our ideal implementation would...
/usr/local/tunapanda/provision/ext/edx/
roles_path
in our ansible.cfg
allows our playbooks and roles to use edX roles if it is checked out here. when: ansible_architecture == "armv7l"
(not all ARM architectures will be v7l
, of course, but the cubietruck should be)Since for now we're focused on using edx pre-installed on the cubietruck, I've split this off into its own branch so we don't have a broken edX playbook lying around in master.
https://github.com/tunapanda/provision/tree/usernamenumber/edx_integration
This is worthwhile not only because it allows us to host edX courses, but because the edX configuration playbooks provide playbooks for several other important services, like mongodb nginx, etc.
...in fact, something to consider: at least in the short-term, maybe it would be worthwhile for deployments that include edX to just start with an edX install, and then run our playbooks afterward to build on that.
One way or another, the ability to host edX courses is part of the MVP for the initial test deployment.