OEP-45, ADR 1: Tutor as replacement for edx/configuration #178
Conversation
openedx-webhooks
added
needs triage
open-source-contribution
|
Thanks for the pull request, @arbrandes! I've created OSPR-5305 to keep track of it in JIRA, where we prioritize reviews. Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
arbrandes
force-pushed
the
arbrandes/oep-45-tutor-proposal
branch
from
6567295 to
fc665e5
Compare
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Show resolved
Hide resolved
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
| startup of the MySQL container that requires relaunching the command, and one has to modify the MinIO hostname manually | ||
| to avoid a failure during the initial LMS job. There were further MinIO name resolutions issues that precluded a fully | ||
| working environment: there was no time to ascertain whether the cause is ultimately with Tutor or with the tested | ||
| microk8s setup. |
There was a problem hiding this comment.
I did not face these issues, but if you can reproduce them then it's almost certainly a bug -- which needs to be fixed.
There was a problem hiding this comment.
@arbrandes In a follow-up task, if you can confirm that it comes from Tutor, maybe open a bug on Tutor's tracker with instructions to allow @regisb to reproduce it?
There was a problem hiding this comment.
@regisb, @antoviaque, sure thing, I'll spend some time trying to get to the bottom of why this happens. At the very least, we can already start expanding the Kubernetes docs based on the results.
There was a problem hiding this comment.
For what it's worth at MIT we are planning to use the Hashicorp Nomad system for managing our installation of Tutor if/when it becomes the supported method of deploying Open edX.
| Note that it is perfectly possible to bypass Tutor entirely when it comes to cluster management. One could use its image | ||
| creation engine to build the requisite Docker images, then manage the Kubernetes cluster with something like Helm: there | ||
| are reports of `this exact thing being done | ||
| <https://discuss.openedx.org/t/lets-talk-about-the-native-installation/3269/2>`__). |
There was a problem hiding this comment.
I don't disagree with the sentiment, but if it's the case that Tutor should not be concerning itself with Kubernetes at all, and Kubernetes users should just Tutor to only build images and otherwise use Helm or whatever other high-level Kubernetes management facility they may prefer, shouldn't tutor k8s just be removed?
There was a problem hiding this comment.
shouldn't tutor k8s just be removed?
I have thought about it; but for many users, having a working (albeit less user-friendly) K8s deployment is an insurance policy for the future, so I decided to keep k8s deployment. It might move to a separate plugin in the future, but I will keep supporting it.
There was a problem hiding this comment.
I agree that tutor k8s should remain. What I'm arguing for is to add to it, either in the form of more configurability, or simply documenting an alternative. I imagine, for example, we could contribute Helm charts and accompanying docs and they would live in /contrib, or something like that.
| <https://github.com/overhangio/tutor/blob/master/tutor/commands/local.py#L91>`__. This, however, `does not apply to | ||
| Kubernetes support <https://github.com/overhangio/tutor/blob/master/tutor/commands/k8s.py#L281-L288>`__. While the | ||
| corresponding single-server upgrade procedure can be used as an authoritative reference for how to achieve it manually | ||
| on multi-server deployments, ideally there would be specific documentation on it. |
There was a problem hiding this comment.
The manual instructions printed in the console should actually work for most people.
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Show resolved
Hide resolved
| There is work to be done before it can be considered a full replacement: | ||
|
|
||
| - There must be a documented way to run highly-available, multi-server production deployments, including a way to run | ||
| automated rolling upgrades with no downtime |
There was a problem hiding this comment.
including a way to run automated rolling upgrades with no downtime
This is:
- impossible in the general case: for instance when migrating from one Open edX release to the next.
- very easy in most cases: just upgrade
tutorand runtutor config save && tutor local start -d && tutor local init.
There was a problem hiding this comment.
Alright, maybe zero downtime will not possible between Open Releases, but it evidently should if one is tracking master - it's what edX does, after all, and it should basically amount to running migrations and roll-upgrading containers. After all, all migrations should be backward-compatible, right? ;) I'll amend the statement accordingly.
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
| ``edx/configuration``. While edX is itself moving to `Kubernetes with Helm | ||
| <https://openedx.atlassian.net/wiki/spaces/AC/pages/2107441855/Braindump+on+Configuration+Today+and+Future#Future-with-Containers>`__, | ||
| edX at this time do not intend to make their Helm charts public - though they're open to the idea of publishing and | ||
| maintaining sample versions. |
There was a problem hiding this comment.
The following projects also aim at deploying Docker-based Open edX:
https://github.com/openfun/openedx-docker (cc @sampaccoud)
https://github.com/Abstract-Tech/derex.runner/ (cc @silviot)
There was a problem hiding this comment.
@regisb my 2 cents would be to have a shared official docker image built in a separate repository. Tutor's and openfun/openedx-docker images do very similar installations in the Dockerfile...
The big value behind Tutor is to wrap the whole project in a running environment with a one-click install. This is very valuable for most projects but not for us or other big platforms.
Some people will deploy in Kubernetes, others in OpenShift, or simply with docker-compose... so it makes sense to have several approaches... but they should all be based on the same official docker images.
There was a problem hiding this comment.
@regisb: thanks, I was not aware of those. I'll add them in.
@sampaccoud: while I agree with the sentiment, it is not yet clear how or where these images should be maintained. Ideally, they would be provided by edX themselves. They're open to making the Dockerfiles they include in the IDA repositories more flexible. We should definitely campaign that they do exactly that, while attending to everybody's needs.
Nevertheless, we need to start somewhere. Particularly, to give them an example of what the community needs. I'm going to take a look at openedx-docker as well.
There was a problem hiding this comment.
Thanks for the writeup, @arbrandes! I mostly concur with @regisb's earlier comments and have added a few thoughts of my own.
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Show resolved
Hide resolved
| Note that it is perfectly possible to bypass Tutor entirely when it comes to cluster management. One could use its image | ||
| creation engine to build the requisite Docker images, then manage the Kubernetes cluster with something like Helm: there | ||
| are reports of `this exact thing being done | ||
| <https://discuss.openedx.org/t/lets-talk-about-the-native-installation/3269/2>`__). |
There was a problem hiding this comment.
I don't disagree with the sentiment, but if it's the case that Tutor should not be concerning itself with Kubernetes at all, and Kubernetes users should just Tutor to only build images and otherwise use Helm or whatever other high-level Kubernetes management facility they may prefer, shouldn't tutor k8s just be removed?
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
| either Tutor or ``edx/configuration``: | ||
|
|
||
| - Support the deployment of MFEs | ||
| - There should be a way to reuse the same base LMS image with different themes without having to bake them into the |
There was a problem hiding this comment.
At the risk of asking an underinformed, handwavy question: couldn't this be achieved by using Django STATICFILES_STORAGE on S3 or another external storage service? In other words, isn't this something that could be solved in edx-platform?
There was a problem hiding this comment.
Good idea. You should already be able to run tutor local run lms paver update_assets, with appropriate settings, and have the static assets sent to S3/MinIO. You'll need a tutor plugin to define the proper Django settings, though.
There was a problem hiding this comment.
You mean something like this? :) (I think the only thing that that's missing is setting STATICFILES_STORAGE itself.)
There was a problem hiding this comment.
Sorry, one other thing that that plugin is missing is updates for boto3.
There was a problem hiding this comment.
@arbrandes Thanks for putting together this review! It's really useful to see all the points clearly layed out, to help inform this decision.
And kudos @regisb for building Tutor, and making it the nice open source project that it is. :) I have a few points left to resolve, but it looks like OpenCraft could definitely get behind this decision if we can figure them out. :)
| Tutor's stated purpose is "To make it possible to deploy, administer and upgrade Open edX anywhere, easily." (`source | ||
| <https://docs.tutor.overhang.io/faq.html#what-is-the-purpose-of-tutor>`__). And for single server installs, it clearly | ||
| lives up to it: in terms of ease-of-deployment, it is a step up from ``edx/configuration``. Getting a server up is | ||
| simpler than even using the official Docker devstack. A local test Koa deployment had one up and running in `under 15 |
There was a problem hiding this comment.
What would be the plan for devstack, actually? Would Tutor also be meant to also handle the reference development environment? If not, how would the ongoing changes be reconciled between the two?
There was a problem hiding this comment.
Devstack is, first and foremost, edX's development environment. I don't see a clear path towards the unification of the Tutor dev environment and the Devstack, other than convincing edX developers that Tutor is superior in terms of developer experience.
There was a problem hiding this comment.
This is an important point that we may want to address specifically in either this or a subsequent ADR. It is definitely a separate can of worms, though. A development environment has some needs that are not part of a production one. Such as, for instance, automatic code and asset reloading. I haven't evaluated Tutor with that in mind - yet.
There was a problem hiding this comment.
Do we have a detailed list of the things Tutor doesn't do that it would need to do to be a development environment?
There was a problem hiding this comment.
Yup, and devstack isn't just edX' development environment, it's also the one used by many contributors & providers. If we can all agree on a common development enviroment, that will help pull our resources together, get more contributions focused on one project, and everyone will have less maintenance to do, including edX. @regisb this is a good opportunity to actually do that convincing, while we are looking at Tutor. :)
There was a problem hiding this comment.
@regisb That sounds look good arguments to me 👍 In addition to @arbrandes testing this sprint (thanks!), @nasthagiri mentioned wanting to start a discussion about this - it sounds like great next steps, by getting all people involved to understand the differences, and see what decision makes sense.
There was a problem hiding this comment.
If people want to test Tutor as a devstack, please get in touch to get a free Wizard Edition license, so that you can try out the machine plugin: https://overhang.io/tutor/plugin/machine I think it's a game-changer for Open edX development.
(or even better, you can show your support by buying a license 😛)
Also, I am working on running edx-platform unit tests on Tutor and got pretty good results: only 35 tests are failing (out of 17k) with pytest. I suspect most of those are also failing on the devstack when they are run with pytest. The Docker test image will be published soon, along with instructions on how to run unit tests.
There was a problem hiding this comment.
As promissed, I added a "Devstack Criterion" to the ADR and evaluated Tutor against it. See the latest commit
(e06cc82). Spoiler: the setup that more closely mirrors the official devstack is a tad more involved than the latter, but it works well!
(@regisb, does the advertised "machine plugin" make it a bit easier? Is it open source? Didn't have time to test it. I did send over a PR to fix a runtime issue I faced, in any case.)
Cc @nasthagiri - now that I did my homework, I'm ready to help organize that devstack meeting. More on this tomorrow at the contributor's meeting.
There was a problem hiding this comment.
does the advertised "machine plugin" make it a bit easier?
It does not make the process easier, but it makes you run Docker/docker-compose on a remote server (like Appsembler's Sultan) so image re-building and requirement downloading is much faster.
Is it open source?
yes, it is AGPLv3 but it is not free: https://overhang.io/tutor/plugin/machine
Could we clarify that a prerequisite should be that Tutor be a good development environment, but it is not a prerequisite that Tutor replaces the devstack?
| startup of the MySQL container that requires relaunching the command, and one has to modify the MinIO hostname manually | ||
| to avoid a failure during the initial LMS job. There were further MinIO name resolutions issues that precluded a fully | ||
| working environment: there was no time to ascertain whether the cause is ultimately with Tutor or with the tested | ||
| microk8s setup. |
There was a problem hiding this comment.
@arbrandes In a follow-up task, if you can confirm that it comes from Tutor, maybe open a bug on Tutor's tracker with instructions to allow @regisb to reproduce it?
| clearly expended effort in getting it to work with Kubernetes, if it is to fully replace ``edx/configuration`` as the | ||
| go-to community installation for production use, it is suggested that the Kubernetes documentation be extended with more | ||
| detailed information on how to run and maintain Open edX in such an environment, and that Kubernetes support be made a | ||
| first-class citizen. |
There was a problem hiding this comment.
If the goal is to designate a reference installation for the Open edX project as a whole, having proper support for multi-server setup seem really important. It is a really common use case - Open edX is a MOOC platform, after all. :)
Even if it isn't the main target, or even not part of Tutor itself as discussed below, it is going to be an important feature for most of the providers switching to Tutor, if it becomes the official deployment method. So there needs to be a good solution for this, or we will be missing part of the reference deployment, which would be then left for each setup to rebuild, effectively proprietarizing it, and increasing everyone's maintenance burden. It would be good to get a common reference multiserver setup, regardless of how we achieve this.
|
|
||
| This is clearly an area where contributions are needed. It will likely require one or more volunteers to help maintain | ||
| master and fix breakages, as those would inevitably happen. Continuous deployment and some level of integration testing | ||
| would also be required, as the volunteer(s) would need to be warned as soon as possible about failures. |
There was a problem hiding this comment.
Actually, this is one of the main elements that defining a reference deployment is meant to address, without having people dedicated to swim against the current and go fix breakages created in the upstream version.
Can we clearly agree on having a CI setup running the reference implementation against all changes on master, and make it the responsability of the person/PR breaking it to fix it? Could we have it running as one of the tests on PRs, so only code that doesn't break the reference installation gets merged? Otherwise it's a huge mess every time someone does break something.
On this topic, see what we have started setting up with @nedbat in https://discuss.openedx.org/t/how-do-we-build-continuous-integration-for-the-supported-installation/3065
There was a problem hiding this comment.
As I mentioned elsewhere, Tutor already has a working and performant gitlab-based CI. Currently, the CI workers run on Kubernetes, which means that they are scalable. The only issue I see is the cost of CI. It will be expensive (500-1000€/month) to run a full test suite for every PR. This is a place where Open edX hosting providers can contribute -- either financially, or by running CI workers on their infrastructure. In the latter case, it would make sense to display a "sponsored by" message at the top of every CI run.
In other words, having a CI running on the master branch is both desirable, feasible, and a good opportunity for collaboration.
There was a problem hiding this comment.
@regisb That sounds like a great idea. If we do the switch to Tutor, I would definitely be happy to get OpenCraft to contribute on this.
There was a problem hiding this comment.
I would also be happy to get eduNEXT to collaborate on this once we reach that stage,
There was a problem hiding this comment.
The only issue I see is the cost of CI. It will be expensive (500-1000€/month) to run a full test suite for every PR. This is a place where Open edX hosting providers can contribute -- either financially, or by running CI workers on their infrastructure.
At City Cloud we'd be able to contribute what I think would be the required Kubernetes capacity for GitLab runners. We already contribute CI infrastructure for Open Infrastructure Foundation projects, so this shouldn't be very tough to argue internally, plus my team and I are already quite familiar with operating gitlab-runner instances on Kubernetes (or, for that matter, on dedicated VMs — we use both).
There was a problem hiding this comment.
@regisb As we're nearing agreement on this OEP I'd like to come back to this. What's the best way to move this forward? Can I suggest you send me an email (at your convenience — no rush at all) so we can discuss how to best make this happen?
There was a problem hiding this comment.
Thanks again for oferring your help @fghaas! At this point the following items would need to be prioritized:
- Creating a "nightly" Tutor branch that would run the master branches of Open edX.
- Getting the unit tests to run this nightly branch.
- Bonus: Getting the integration tests to run on this nightly branch.
- Create a CI that will actually run the tests.
Items 1 and 2 are obviously the most difficult steps here. I'm currently talking with edX to see how we can prioritize this together.
There was a problem hiding this comment.
Oh I understand that, but maybe we could start helping out by providing additional GitLab runners for the existing CI pipeline?
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
| unforeseen reason Regis can no longer maintain Tutor, the Open edX community would again be orphaned. Thus, it is | ||
| suggested that some form of co-governance/co-maintenance be instituted. Regis has `tentatively agreed | ||
| <https://discuss.openedx.org/t/lets-talk-about-the-native-installation/3269/5>`__. Hopefully, with more people and | ||
| companies using Tutor, more contributors will be willing to take on this responsibility. |
There was a problem hiding this comment.
Can we specify a bit how this would work, as part of this ADR? @regisb how do you see this working, practically?
There was a problem hiding this comment.
Tutor is open to external contributions, and Tutor users already submit PRs. This PRs are usually reviewed and merged in a timely manner, so I am not quite sure we need to amend this process just yet.
I want to keep full control over what goes in the Tutor core app as well as the supported plugins, so I will remain a bottleneck for PR reviewing and merging. However I must be more transparent when it comes to making important architectural changes. This can take the form of pre-release announcements, ADRs, synchronous conversations or forum topics. For instance, the recent changes introduced in Koa (uwsgi, Caddy, Redis...) would have been discussed prior to release.
My position when it comes to making changes to the core of Tutor is the following: can you implement your changes in a plugin? If yes, you should develop such a plugin and it is your responsibility to maintain it. If not, what changes must we make in Tutor to allow you to implement such a plugin? If those changes are not possible or desirable, then, and only then should you fork Tutor.
Of course, that last scenario is not desirable, and in my experience it occurs very rarely.
Let me phrase the question differently: what organizational changes would the community like to see implemented to gain more confidence in the future of Tutor?
There was a problem hiding this comment.
This seems like the crux of the matter:
I want to keep full control over what goes in the Tutor core app as well as the supported plugins, so I will remain a bottleneck for PR reviewing and merging.
We need more specifics about what is the Tutor core, what are the supported plugins, and what is the community installation. We don't want work on the community installation to be gated by one reviewer, no matter how responsive.
There was a problem hiding this comment.
We don't want work on the community installation to be gated by one reviewer, no matter how responsive.
Let me play devil's advocate here: why don't we want the community installation to be gated by one company? (notice I say "company", not "reviewer"). The only scenarios I see where that might be an issue are when:
- The community installation is suddenly broken: this never happened, because the only external dependencies are docker.io and the tutor packages on pypi.
- A security patch is published and needs to be added urgently to the base Docker image: such issues should (must) be mitigated by being warned in advance of the publication of a security patch.
Am I missing something?
I'm going to suggest adding this topic (and any pending points in this ADR) to the next BTR working group meeting agenda for the 18th. That way we can spend a few minutes figuring out the way forward. @regisb, is that ok?
Sure @arbrandes; you are very much welcome to add items on the BTR meetup agenda. I think that to get a productive conversation you should come with a set of clear expectations. For instance: "we need PRs to be reviewed within X hours" or "we need a backup strategy in case you stop working on it".
There was a problem hiding this comment.
we are proposing that Tutor becomes the official installation method for the Open edX project - so that would make it part of the Open edX project (and a critical part of it, that is!), and even if it is owned by you rather than by an edX team, it is still important to follow the project best practices.
The core committers program is a band-aid patch for a deeper issue, which is that non-edX PRs take too long (if ever) to review. The CC program only partially resolves this issue: many PRs, even trivial ones, take months before they get merged. I would be more than glad to trade my CC badge for a more reactive project stewardship.
Core committers are a best practice in the context of Open edX, but not in the rest of the open source world. There are plenty of great projects out there that strive under the umbrella of a single organization.
Tutor works because at some point I decided to do things differently than the rest of Open edX. I will not rely on a suboptimal governance model simply because it's the default in Open edX.
It's like if OpenCraft said that we wouldn't accept any other core committers on blockstore, despite it being one of the core components of the platform...
Who is responsible for maintaining Blockstore? If you are saying that OpenCraft is taking on this responsibility, then I'll be perfectly fine with the project having no external core contributor. IMHO it would actually be a big win for the whole community.
When all you have is a hammer, all problems look like a nail. Now, why do I think that joining the core contributors program is the wrong hammer for that nail? There are several reasons:
- It moves some knowledge away from the creator and maintainer of the project (aka: me), thus making it more difficult to quickly debug and resolve issues.
- It dilutes the project responsibility: when multiple people are responsible for a task, no one is.
- It reduces the visibility of my company: at the risk of stating the obvious, I am building a business around Tutor, and it is important that this business remains viable, otherwise the project will wither. This will only work if Overhang.IO is widely considered as the creator and manager of the project.
I should mention that there are alternatives to joining the core committers program:
- Core reviewers who review PRs but do not have merge rights
- Product owners who help test features and establish a roadmap
- Plugin maintainers who extend the core software outside the umbrella of the original company
- Support engineers who answer questions on the forums
If Tutor becomes the new native installation (as I hope it does), maybe I'll become swamped in PRs, discussion topics and Github issues. I doubt it, as I am dealing with a small 3k LOC code base which I wrote pretty much all by myself, but if it's the case then I'll be happy to bring more people onboard to help. But today, it's just too soon to commit to this.
it should at least be part of the core committer program yes, and allow other Open edX core committers (which you would pick, based on demonstrated skills & matching philosophy) to have merge rights, as well as the ability to merge PRs independently from you. Though that's a minimum, imho it could be good to use the opportunity to push the concept further, and this could be a discussion - I would be interested in hearing what you would suggest.
Here's what I can commit to: if reactivity to PRs becomes a problem at some point, if there are external contributors with a proven track-record of feature development on Tutor, then joining the core committers program will be one of the solutions I'll consider.
Does this sound reasonable to you?
There was a problem hiding this comment.
The core committers program is a band-aid patch for a deeper issue, which is that non-edX PRs take too long (if ever) to review.
While the CC program is indeed an attempt to remediate PR reviews, I would hesitate to call it a band-aid. I see it more as an acknowledgement that projects such as the Linux Kernel, OpenStack, and Debian (listed in order of increasing community stewardship), get it right.
I know that comparing Tutor, a 3 Kloc project, to OpenStack, at 12 Mloc with thousands of contributors, is hardly fair. But Open edX itself makes more sense, so bear with me for a while. In my ideal world, Open edX would be entirely community driven, just like OpenStack, and financed by the same community via indirect methods such as donations or an organization membership. There would be a whole new class of problems, but some of the ones we see today could be elegantly solved: among them, the time-to-review we're discussing here, and also, for instance, the Release Notes issue we're trying to handle elsewhere.
This is, alas, not the case, nor is it likely to ever come to pass. But, and this is the crux: it shouldn't stop us from picking elements from such projects that make sense to our particular zeitgeist. Specially if the parent organization is willing to hear us out as a community.
And here's the snag: while Tutor is far from suffering from the problems the CC program was created to solve - indeed, it looks like it was created precisely as a way to solve a part of them! - it doesn't send the right message if the community asks for it from edX, but gives Overhang a pass.
I could put forward several practical advantages for everybody, including Overhang, in having such "lieutenants" doing volunteer work in Tutor (speed, agility, resilience, etc). But that is not why I brought this up in the ADR: as @antoviaque says, whatever replaces edx/configuration is critical. We would love to have it give off the same "community signals" we're seeing from edX.
Note that I'm not suggesting that either edX or Overhang give up control of Open edX and Tutor, respectively. And just for completeness, I definitely don't think either should be forked, ever. Like the projects you mention, there are many successful codebases under enlightened company leadership and thriving communities. I happen to think edX is one of them, and Overhang even more so. It's just that having such positions as core committers is, above all, a signal of mutual trust: both that the community trusts Overhang, and that Overhang trusts the community.
Finally, as Xavier said, you'd be the one to pick committers, if any live up to your standards. You'd be free to "fire" them and revert their changes, if they somehow break your trust. I don't see the current Open edX core committers going against the direction set by edX, and I wouldn't expect anything different from Tutor "core committers" - if those are what they end up being called.
There was a problem hiding this comment.
We are running around in circles. I am saying that adding core committers would be detrimental to the project, and you are saying that not having core committers would be sending you a bad signal. In order to move the needle, I drafted a proposal for a maintainers program which actually makes sense in the context of Tutor: overhangio/tutor#395 Please let me know what you think.
There was a problem hiding this comment.
Thank you for the proposal @regisb - I'll review and post a few comments about it calmly next week, but it's really useful to know what would work for you. I agree that we have a better chance to get to a consensus by starting from what we each want and are willing to do, rather than the other way around. Cheers! :)
There was a problem hiding this comment.
@regisb I've done a pass of review on overhangio/tutor#395 and left a few comments there,
|
|
||
| It is estimated that initial versions of the above will take anywhere from three to six months to achieve, if sufficient | ||
| developers commit resources to the endeavor. (Part of the test of whether a community-supported deployment method will | ||
| work hinges precisely on whether this community can pool resources to maintain it!) |
There was a problem hiding this comment.
Yes, this is an important part of the decision - who would be ready to commit on participating to that work?
For OpenCraft, if the remaining outstanding points above can be resolved, we can definitely dedicate time to contribute our share of the work toward that goal.
There was a problem hiding this comment.
My own estimate of the amount of required work is much more optimistic. I think I can implement unit tests and update the "edge" branch in 5-10 days of work, at the very most. (the machine plugin really helps to accelerate the development loop) However, I cannot commit to working on the native -> Tutor upgrade, as I do not have sufficient experience with the native installation. That being said, I will of course provide technical support to the team in charge of developing the upgrade manual.
There was a problem hiding this comment.
Thanks for the details @regisb
What about the other contributors, on this? @felipemontoya @idegtiarov @pdpinch @OmarIthawi @pierre would you be able / want to help?
There was a problem hiding this comment.
Thanks Xavier. I'll ask for help from a teammate with more experienced infrastructure/operations than me.
There was a problem hiding this comment.
I know @blarghmatey is starting to look into Tutor, but I don't think we're ready to commit yet. We also diverged from the native install some time ago, so I don't know that we can help much with that part specifically.
There was a problem hiding this comment.
@antoviaque @arbrandes OpenCraft does a lot of native deployments and migrations between cloud providers, so I think we could help out here.
Specifically, I'd recommend focusing on production deployment migrations where the databases and caching services will remain intact, and we're just using Tutor to deploy the Open edX services.
|
@arbrandes You have done a great job here: the writing is clear and orderly, and you've approached the evaluation methodically and thoroughly. Thanks! |
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
| <#criteria>`__. | ||
|
|
||
| 2. For the following release, Lilac, ``edx/configuration`` will be supported but marked as deprecated, and Tutor will be | ||
| supported for the first time. |
There was a problem hiding this comment.
@nedbat, you suggested adding this to the ADR. I agree. :) Does the wording work for you? (See also the following decision.)
There was a problem hiding this comment.
How will users choose between Tutor and the native installation? Can we suggest that Tutor be the recommended installation method for new users, and that users who already run the native installation keep using it?
There was a problem hiding this comment.
One challenge with that approach is the question of what will the native installation be once the Ansible repository is fully deprecated?
There was a problem hiding this comment.
If the decision is provisional, and we would approach this as an "alpha" release, it would make sense to ask for feedback on it from users willing to become involved (i.e. post their comments about the Tutor approach) or who want to start looking into migrating their setups. If we directly recommend all new users to use Tutor, it makes it harder to take the final decision objectively, as we would already have redirected a significant part of the community to it.
There was a problem hiding this comment.
I don't have the time at the moment to commit to this, but it is on my roadmap to do a test deployment of Tutor in our QA environment over the next couple of months.
There was a problem hiding this comment.
I think my issue is with the term: "alpha": https://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha
Alpha software is not thoroughly tested by the developer before it is released to customers. Alpha software may contain serious errors, and any resulting instability could cause crashes or data loss. Alpha software may not contain all of the features that are planned for the final version.
Tutor has been thoroughly tested and all "serious bugs" which have been reported so far have been fixed. To the best of my knowledge, Tutor does not cause crashes or data loss. Not all features from the native installation are available in Tutor (I'm thinking of Insights, for instance), but these features are explicitely not on the roadmap.: https://docs.tutor.overhang.io/faq.html#what-features-are-missing-from-tutor
Thus, the term "alpha software" does not apply to Tutor. So I'd like to propose the following recommendations:
- Existing users of the native installation should keep running the Ansible playbooks officially supported by edX.
- New users should use Tutor, which should be considered a "release candidate" by the Open edX community.
@blarghmatey: it is a prerequisite of this ADR that someone, at some point, will write migration instructions from the native installation to Tutor. BTW, I think it should be time to look for volunteers. Is this a task for the BTR working group?
There was a problem hiding this comment.
One challenge with that approach is the question of what will the native installation be once the Ansible repository is fully deprecated?
I don't know that we want to support more than one installation approach. If we like Tutor, it will eventually be the only approach, right?
BTW: "Native" originally meant, "directly on an Ubuntu box" as opposed to "with Vagrant". We don't need to keep the word Native.
There was a problem hiding this comment.
@regisb The term alpha doesn't refer to the version of Tutor - but more of using it as the official installation of Open edX for everyone in the community. It has been extensively tested by people using it currently, but not by the rest of the community who would then have to adopt it -- and migrate to it.
There was a problem hiding this comment.
What you are describing here is not "alpha" software, but a release candidate: https://en.m.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate
A release candidate (RC), also known as "going silver", is a beta version with potential to be a stable product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs.
There was a problem hiding this comment.
@regisb Release Candidate could be fine yep :) The main point is to make sure people realize they should only follow this path if they are ready to get involved in ironing out issues with us.
| `````````````````` | ||
|
|
||
| Like the production version, it is not currently possible to run the ``master`` branch of ``edx-platform`` for | ||
| development. |
There was a problem hiding this comment.
Well... it is posible, but it's almost certain that it will require some additional changes. It's probably not just a matter of running tutor config save --set OPENEDX_COMMON_VERSION=master. The probability that additional changes are required increases linearly with time since the last release. Thus, it is currently not officially supported.
There was a problem hiding this comment.
Good point. I'll change "possible" to "supported".
|
|
||
| .. code-block:: | ||
|
|
||
| tutor dev start -d |
There was a problem hiding this comment.
This process is fairly complex -- that's because it is trying to replicate the way things work on the Devstack. And the Devstack-way-of-doing-thing® is not the Tutor-way-of-doing-things® 😛
Now that automatic bind-mounts exist, when I need to develop on edx-platform I typically run the following commands:
tutor dev bindmount lms /openedx/edx-platform
tutor dev runserver --volume=/openedx/edx-platform lms
Then I edit the files from $(tutor local printroot)/volumes/edx-platform.
There was a problem hiding this comment.
the Devstack-way-of-doing-thing® is not the Tutor-way-of-doing-things®
@regisb, I agree completely. And this isn't really a judgement call on which is better. It's just that I specifically set out to get as close to a devstack as I could, as an exercise in comparing them.
To be fair, if we were to try and get the devstack to behave as Tutor... It'd be much, much harder. It is a testament to Tutor's flexibility that the opposite is even possible. :)
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
oeps/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst
Outdated
Show resolved
Hide resolved
arbrandes
force-pushed
the
arbrandes/oep-45-tutor-proposal
branch
from
cc3c363 to
35bb313
Compare
| Status | ||
| ------ | ||
|
|
||
| Draft |
There was a problem hiding this comment.
@arbrandes @nasthagiri As discussed during the contributors meetup yesterday, should we use "Provisional" as a status for this ADR? And maybe indicate a timeline for taking a more definite decision on it?
There was a problem hiding this comment.
I am supportive of this.
|
I would like to move forward with this ADR, in order to have more certainty. We have already started the process for the Lilac release, and some of the tasks require that some development be made in Tutor -- thus implicitly stating that this ADR is accepted. As discussed, I propose that Tutor be the recommended installation method for new Open edX installations. Platforms that need to upgrade from the native installation should keep using the native installation, using whatever process they are used to. |
I think we agreed to move forward yes -- though on a provisional basis? Cf #178 (review) To get to the accepted state, we discussed going through one release first, to be all able to test and see how it goes, before taking a final decision. I also remember that there were three outstanding topics on which we still had to reach a consensus, though maybe some of these have been resolved in the meantime?
@arbrandes Am I forgetting anything?
For the first release, we discussed it at #178 (review) -- we would present Tutor as something we are testing for this release ("release candidate"), but not something we would recommend just for this first release -- especially because we wouldn't have formally accepted the change just yet, we would all be testing the approach. The idea is to go step by step, this is an important decision for the community, with long term repercussions - so we need to strike a balance between speed and cautiousness, especially while we are still figuring things out, and figuring out how to collaborate together. |
|
If we put this ADR in a provisional state, we need to know what it depends on in order to get through to an accepted status. What specific questions do we need to answer, and on what timeline? The Open edX community needs confidence on this topic. If we don't, people are going to install Lilac with the native installation, which will be a pain in the butt for them to upgrade once Maple comes out. Marking this ADR as "provisional" or "pending" will not send a clear signal to the community. I propose to clarify this ADR to state the following :
I would like the get the opinion of the rest of the community on this question: @nasthagiri @felipemontoya @nedbat @pdpinch @BbrSofiane @sambapete As for the outstanding issues you mentioned:
At that point, I can only repeat what I have already stated elsewhere: Tutor is running in production, both with docker-compose and Kubernetes, on high-traffic platforms such as public administrations, major universities and large companies. The most recent and public example of this is the Open edX platform of the Guatemalan ministry of education: https://aws.amazon.com/fr/blogs/publicsector/enabling-remote-education-guatemala-scalable-learning-platform-mineduc-digital/ To put it succinctly: Open edX scales well with Tutor. With the following addendum: and actually it scales much better than the native installation.
The maintainers program has launched and four people have joined already: https://discuss.overhang.io/t/announcing-the-tutor-maintainers-program/1388 Anyone is welcome to apply.
Yes, this is not in the scope of the ADR. But, as many people have already discovered, Tutor is a great development environment for Open edX. |
|
I agree with @regisb . If we have a basic agreement that Tutor is accepted by the community to be a valid installation method (and I don't have any objections so far), then we need to move forward. We can have both options (ansible and Tutor) in a transition period, but we need to start promoting and testing the new one. |
|
This is totally in line with my original proposal of having a transition
release where both the native installation and the community installation
(aka as Tutor) are available and installable.
Le jeu. 15 avr. 2021, à 01 h 31, Régis Behmo ***@***.***> a
écrit :
… If we put this ADR in a provisional state, we need to know what it depends
on in order to get through to an accepted status. What specific questions
do we need to answer, and on what timeline? The Open edX community needs
confidence on this topic. If we don't, people are going to install Lilac
with the native installation, which will be a pain in the butt for them to
upgrade once Maple comes out.
Marking this ADR as "provisional" or "pending" will not send a clear
signal to the community. I propose to clarify this ADR to state the
following :
1. Tutor is one of the two recommended installation methods for newer
Lilac installations (with some provisions: no support for Insights, etc.)
2. If the feature set proposed by Tutor is considered sufficient, the
native installation will be deprecated in favor of Tutor for Maple.
I would like the get the opinion of the rest of the community on this
question: @nasthagiri <https://github.com/nasthagiri> @felipemontoya
<https://github.com/felipemontoya> @nedbat <https://github.com/nedbat>
@pdpinch <https://github.com/pdpinch> @BbrSofiane
<https://github.com/BbrSofiane> @sambapete <https://github.com/sambapete>
As for the outstanding issues you mentioned:
Support of high traffic sites -- @bradenmacdonald
<https://github.com/bradenmacdonald> and @arbrandes
<https://github.com/arbrandes> have done some discovery work on this, but
I'm not sure we have a fully baked and tested solution here?
At that point, I can only repeat what I have already stated elsewhere:
Tutor is running in production, both with docker-compose and Kubernetes, on
high-traffic platforms such as public administrations, major universities
and large companies. The most recent and public example of this is the Open
edX platform of the Guatemalan ministry of education:
https://aws.amazon.com/fr/blogs/publicsector/enabling-remote-education-guatemala-scalable-learning-platform-mineduc-digital/
To put it succinctly: *Open edX scales well with Tutor.*
With the following addendum: and actually it scales much better than the
native installation.
Governance -- I'm not sure where we are standing here? This thread still
seem to be hanging: #178
<#178> (comment)
The maintainers program has launched and four people have joined already:
https://discuss.overhang.io/t/announcing-the-tutor-maintainers-program/1388
Anyone is welcome to apply.
Devstack support -- though I think on this one we said it was not
blocking, as this is separate from
Yes, this is not in the scope of the ADR. But, as many people have already
discovered, *Tutor is a great development environment for Open edX*.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#178 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACD6PLK3XYGC6ELAWSDBNA3TIZ22ZANCNFSM4U3IBOIQ>
.
--
Salutations / Regards ,
Pierre Mailhot, M.Sc., CISSP
514-916-9558
|
|
It's probably worth making it clear to new members of the community. For the people launching new instances of Open edX now it would make more and would lower the barrier of entry if they are directed towards tutor.
+1 to this. |
|
@regisb CC @angonz @sambapete @BbrSofiane @nasthagiri @nedbat @arbrandes To follow up on this, after the discussion during the core committers meetup from last week (openedx/wg-coordination#27) -- we agreed that it was mainly down to how to word the announcement for the release, right? We didn't have time to finish that discussion then, but it looked like it should be possible to agree on a formulation that takes into account all our respective concerns. Namely, to provide guidance to users when they chose their installation method, and make sure they don't end up surprised or in a bad situation for Maple (whichever installation method they choose), while still making sure we aren't skipping steps in our testing, work iteratively, and give the community at large a chance to test and provide feedback on the change before we make it permanent. To base it on what you have suggested above, what about:
How does that sound? It's important to make sure we all get a chance to deploy and maintain Tutor in production first, and see how collaboration on the project works out. Tutor is a great piece of software, and you have done a beautiful job building it -- many of us are still pretty new to it though, and it's a change of scale for the project, so it seems important to not be skipping steps. To also answer some of the other points:
This is great! Kudos for this project. 👍 And I'm also optimistic on this, the experimentations from @bradenmacdonald with Tutor and Kubernetes/Terraform also seem pretty positive, it looks like it will be good to use Tutor in the context of a larger setup. But I don't think any of the scaled setups currently in production have been fully published openly yet, no? If I understand correctly, Tutor in those setups is more used as an image builder, rather than managing the full orchestration of the scaled setup, so there are pieces that are still proprietary to the existing scaled prod setups? Or is there already something similar to @bradenmacdonald 's "Tutoraform" published by them? For many of us in the larger Open edX community (including OpenCraft), we haven't had a chance to use Tutor in production at scale yet, and there can be a lot of work and unknowns to get there.
Ah, that's great to see! I had missed the announcement -- though I know from past discussions with @arbrandes that we plan to participate and contribute there. I also like the principle of the different potential roles, as well as the formalization around TEPs. Nice work! 👍 Where is the best place to discuss & provide feedback on the proposals? The forum threads of the proposals themselves (https://discuss.overhang.io/t/the-tutor-maintainer-handbook/1375 and https://discuss.overhang.io/t/tep-purpose-and-guidelines/1376) are closed, so I'm not sure which thread is meant to host the feedback - I considered using https://discuss.overhang.io/t/announcing-the-tutor-maintainers-program/1388 but I don't see any comments there. Could we have pull requests for this, or a document that allows inline threads, to make it easier to do those reviews async? There are some questions that I had asked in the original PR that I would still be curious to know the answer to -- particularly overhangio/tutor#395 (comment) -- committer rights are an important way to demonstrate trust, and thus encourage commitment and contributions, and don't have the same function as maintainer roles (cf the review of best practices in Producing Open Source Software from Karl Fogel). From the way the maintainer's program is currently described, it doesn't look like maintainers would be trusted enough to get commit rights? Note that I'm not talking about letting maintainers merge whatever they want -- the project can still have rules around what's necessary for something to be merged, like having consensus or a number of 👍 from other maintainers. Giving merge rights simply means that maintainers are trusted enough to respect those rules before merging something. If edX can trust community members to do that, can we also have the main community project for handling releases showing at least the same level of trust?
+1 also -- it's definitely better to have a clear list of items that need to be identified. @arbrandes I remember that some of those outstanding points had been listed during a contributors meetup some time ago -- could you provide a recap of what's left to verify with Tutor, missing features that remain to implement, etc? It would be good to have a proper reference checklist somewhere, that is then kept up to date as things progress (maybe on this PR description, or on a follow-up PR?). Note that one of those points is to get feedback from the community at large (including getting many of us) with the Lilac release, to start using it in production settings, and provide feedback based on that real usage experience. So some points are likely going to come from it, which we don't know about yet. |
|
@antoviaque, the 8 basic criteria are part of the document itself, and so far, there have only been three general areas where work clearly needs to be done in the short-to-mid term, in order of decreasing priority:
@regisb has agreed to take on MFEs and master support, either personally or via the Tutor Maintainer's group. And we've essentially taken on Tutor at scale, via the to-be-renamed Tutorraform project. Instead of a checklist, though, we should just create tickets in the BTR board, then assign and categorize them appropriately. I'll set aside some time to make sure all such tickets are up there, this week. We can then set a post-Lilac milestone for Tutor that will make it easier to filter and see where this part of the project stands. |
I think you wrote a great recap. I'm glad we found some common ground :)
I don't expect any of the very large production platforms to run "vanilla" Tutor -- just like they probably run a fork of edx-platform, and if they ran on top of the native installation they would probably customise the deployment playbooks. But it's definitely possible to run a vanilla Tutor platform at scale on Kubernetes: just increase the number of replicas for the service that you would like to scale, and Kubernetes does the rest. This is not just theory but was observed in practice.
Just create a new post in the community category: https://discuss.overhang.io/c/community/maintainers/10 I'd prefer if we centralized conversations in the forum. I realize that this does not allow for threaded conversations around specific questions, but it allows to bring in more people who are not necessarily developers.
My position has not changed on the topic of core committers : at the moment I do not need and do not want extra core committers.
We can expect that there will be many major differences between the native installation and Tutor. Some of these differences could be considered as missing features, but others might not. For instance, I don't know if people will complain about the absence of a Splunk forwarder, Xqwatcher, Sqoop or Neo4J. |
|
A Tutor user has written an extensive, tremendously useful post describing how they migrated from native Jupiter to Tutor: https://discuss.overhang.io/t/migrating-from-native-install-to-tutor-juniper-tutor-10-x/1533 |
Great :) 👍
Yup, though what I'm not clear about currently is the number of changes that are required. I'm not too worried about it, given that others have already used it, and that @bradenmacdonald has already laid out some of the ground work with the "tutoraform" prototype. We will need to walk the walk and actually try to put it in production to know this fully -- and to have it fully published and open source, as unlike a fork of edx-platform or the configuration playbooks, the necessary customizations aren't all published currently, right?
OK, since my main question about this is this one: overhangio/tutor#395 (comment) I'll simply re-ask it here then, since it comes from the current discussion: what scenarios are you trying to prevent with not providing the merge rights to maintainers? We have managed to find common ground on all the other points -- could we also talk that one through, to understand better what we each want, and find an agreement that works for both sides?
Sounds good to me -- did you get around to do this? |
Yes, this is correct. Since Tutor is not exposed as a service by most providers, they do not have to provide the source code for their modifications, although it's AGPL.
I do not understand: I thought we had already found some middle ground with the creation of the maintainers program? I am ready to talk about this further, but I refuse to have this ADR hinge on this criterion. As far as I know, Opencraft is the only company pushing for core committer rights on the Tutor repos. Ironically, no Opencraft employee has applied to the maintainers program yet. I believe that the maintainers program, in its current form, successfully addresses the question of governance as stated in this ADR. @antoviaque you say you want to reach some middle ground but you are not bringing anything to the table. |
That is definitely a step in the right direction, but I don't think we have finished that conversation - some of my questions from the original discussion in January are still pending, like the question I was quoting in my previous message: "What scenarios are you trying to prevent with not providing the merge rights to maintainers?" overhangio/tutor#395 (comment)
That sounds a bit harsh? It might be worth talking about this, because I would hope we can resolve this in a friendly way, working together rather than being tough on each other. In terms of effort, doesn't the work from @arbrandes on this ADR, the Tutor review, or the one from @bradenmacdonald on Tutoraform count for something? We haven't yet joined the Tutor maintainer program, but I also have had pending questions about it for some time, as I mentioned above -- and yet it is in @arbrandes 's todo list, despite not having had the answers we would like to hear about it yet. I hope those show that we want to collaborate? As for pushing for core committer rights, this isn't specific to Tutor. We had been pushing for this for the edX repos for 6 years too, before Tutor -- because we think it's an important element in an open source project, that demonstrates trust and inclusivity, and that it is good practice for open source projects to have more than one entity as core committer. Tutor is becoming part of the Open edX project, as its main installation method, and it feels like a step back for the project to not have this for one of the main community-based components. I don't mean to block or be hard on this - we have still contributed a lot on Open edX before there was a core committer program, and we could do that with Tutor too. But I would hope we can have a fair conversation about it - and see if there is a way we can get to a solution that works well for everyone? Would you like to meet, so we can discuss this face to face? I'll send you a few times. (And if anyone else wants to join the conversation, just say so). |
The Lilac release is two weeks away and you are single-handedly blocking this ADR on the basis of preposterous arguments. My answer may sound harsh, but that's only because it looks like you are attempting to strong-arm me into providing you core committer rights. You are asking for core committer rights on a repo on which your company has not made a single pull request. I have already told you "no" many times. This is so absurd that I don't know where to start. The scenario that I am trying to prevent is a hostile takeover from a competing company. I am a one-man operation. Your company has, what, 50 developers? Granting you core committer rights would be like giving away the key to the house. The comparison with edX (100+ developers) granting core committer rights to 9 people is grotesque. If having core committer access to the Overhang.IO repositories is a prerequisite for you, then I suggest you make an offer to acquire my company. This is how things are usually done in the business world. I will schedule a meeting with you. Meanwhile, I'm calling on arbiters to help decide on the fate of this ADR: @nasthagiri @nedbat. |
It's on my list for this sprint (in practice, this week). |
Observations
Proposed DecisionBased on the first 3 observations, I support merging this ADR in a The 4th observation seems to be a call for a specific principled approach that goes beyond the criteria listed in the ADR. While further discussion along these lines can still happen in parallel, it need not block further movement as set forth in the ADR. In addition to moving forward, I would also request that we have a face-to-face conversation where we seek to understand each other's needs. We all want what is best for our communities: the wider Open edX community and the newly growing Tutor community. As importantly, we each need to reduce potential risks for our respective businesses. Let's ensure we respect and understand each others' perspectives and be open to working together on a long-term phased approach to a collaborative solution. I'd be happy to facilitate said conversation. AppreciationFinally, I want to appreciate the effort that many people and companies have contributed to this ADR. @arbrandes and OpenCraft have put in a lot of energy to evaluate Tutor and write this ADR. While this ADR is outside of Tutor's codebase, this generative effort by OpenCraft will hopefully lead to growing success for Tutor and Regis's company. In addition, @regisb put forth a proposal for a new Maintainer program for Tutor and put in the energy to bring it to fruition in a short amount of time. He also continues to invest in updating Tutor to satisfy the expanded needs of the community. Others, including @blarghmatey @fghaas @felipemontoya and @pomegranited have contributed their thoughts and expertise to this seminal decision. There are many others I have not listed who are working toward bringing Tutor as a centerpiece of the Open edX platform. Thank you all for this collaborative effort. |
I think the misunderstanding is there -- I wasn't blocking moving forward with merging this ADR. As mentioned before, I'm completely fine merging it with the provisional status -- thank you @nasthagiri for moving this forward btw. We have discussed the way to present the announcement about Tutor for Lilac above, which is still fine to move forward with, independently of the current point about core committers. And I have even said in my last message that I would still be fine contributing and moving forward with making Tutor the official release without a core committer program in place... I just want to keep discussing this, to try to find a way that would work for all of us, like we did with the rest of the Open edX project for years, before there was a core committer program. So in my mind, I'm trying the opposite of strong-harming you -- and instead giving you everything you wanted on this, in the hope that it would show that the intentions are good, and that we would be able to have that conversation on a kind basis. :)
Ah, that also seem like another part of the misunderstanding -- I don't consider core committership as something that would remove or supersede your BDFL status. I've tried to say this above, but I'm completely fine with you keeping that status - you have done a great job with Tutor, and it makes complete sense that you keep leading the project. Having core committers doesn't mean that anyone else would be able to take over the project - core committers are still bound by the project rules, and your veto/last word on non-consensual decisions would guarantee it. Just like edX still has the last word on Open edX, or Guido had it on Python while he was still BDFL, despite both projects having core committers besides the BDFL. I think these differences of perception show that we have a lot to gain from discussing this face to face -- it's easy to misinterpret things in the written form at times. And given what I understand now of the scenario you want to avoid, I'm hopeful we will be able to come to an agreement that we are both comfortable and happy with. |
|
Xavier, I'm happy to hear that the question of core committers is not a blocking issue for this ADR. In this case, can we simply mark the related conversations as resolved? If there is no outstanding issue, then we should mark the ADR as provisional and merge this PR. |
Merging the ADR works yes 👍 Even aside the scope of the core committers conversation, that's the advantage of using the provisional status and of announcing the change as discussed above, we can move forward without having completed everything. Some of those conversations aren't fully resolved, but it does make sense to move them to individual tickets - which is something @arbrandes already has on his list to do as next steps actually - though we don't need to wait for this to be done to merge either. |
This adds an ADR specifying what criteria any replacement for `edx/configuration` should meet, then proceeds to evaluate the Tutor project against them, finally proposing it as a suitable replacement once certain conditions are met.
This adds the "Devstack Criterion" to the ADR, and evaluates Tutor against it.
Record the decision to deprecate `edx/configuration` in Lilac, and remove support for it in Maple.
As decided over several discussions along many months, this is approved in a "provisional" state.
arbrandes
force-pushed
the
arbrandes/oep-45-tutor-proposal
branch
from
35bb313 to
1801a10
Compare
|
Alright, as agreed to above, changed the status to provisional. We're ready to merge. Any core committers watching who would like to do the honors? |
|
Thanks to everyone for the contributions to this discussion. |
|
Thanks, @felipemontoya! For future reference, as discussed above I created the following to track progress on the pending technical issues resulting from this ADR. (It's not clear to me if there's consensus on tracking governance as an issue.) |
|
Thanks @felipemontoya @arbrandes! Glad to see this ADR merged :) And kudos for the great work on Tutor @regisb -- putting aside the discussion about the governance, this is a great step for Open edX. Making it easier for more people to install and maintain their instance of Open edX is important to allow the project to reach more people, and you have done really important and useful work in that direction. So, thanks! :)
I think there is consensus on this - now that this ADR is merged, we can continue the conversation in a dedicated ticket yes. 👍 |
Here it is: openedx/wg-build-test-release#83 |
OEP-45, ADR 1: Tutor as replacement for edx/configuration
Description
This adds an ADR specifying what criteria any replacement for
edx/configurationshould meet, then proceeds to evaluate the Tutor project against them, finally proposing it as a suitable replacement once certain conditions are met.Further information
Forum thread
OEP-45
OEROADMAP-21
BTR-43
DEPR-122