@braden@lpm0073@andres@gabor@keithgg@regis@jhony_avella@Felipe To accelerate a bit the process, should we do a synchronous meeting, with the goal of deciding on the definition of a shared project scope for this, that we would all agree to adopt and maintain together?
Here is a poll to find a time to do this – if you would like to participate, please add your availability Try to select the maximum amount of slots, to help to find a common time:
It looks like we have two slots where everyone who has answered is available – let’s do July 26th at 16:00UTC? That’s right after the contributors meetup.
@Felipe will look into Helm charts - shared helm charts to deploy Open edX on Kubernetes looks like a good option to collaborate with. He will post his review of it within the next couple of weeks
If this confirms that it would be worth using to try to work together, @Felipe and @braden will work out a concrete proposal document together, for shared helm charts to deploy Open edX on Kubernetes, which will then be reviewed by the group.
We should definitely plan for a follow-up meeting – but maybe after we have completed the async steps decided during the meeting, and done at least one async pass of review on the document that will result from it? Synchronous meetings can be useful to resolve discussions that take a lot of back & forth – but for meetings to be useful there should be work & async discussions between them?
@Felipe@braden When do you think you will get a first draft up for review?
The inmediate next step was actually on me. Here is un update:
After our meeting I started my helm investigation enthusiastically and I think I have reached a point where its clear that writing helm charts for the openedx project is something that we at edunext would be very interested in.
Now, I suppose that we can write some plan together @braden. I’d use this place to leave some ideas that I think would be ideal to tackle or general concerns I have.
For the project
we need to make it flexible and modular
many composable libraries?
put everything behind flags?
get started with the project already adopting oep-55
make it in a provider agnostic place? e.g the openedx org
use the core contributors program to handle participation
would we target this to eventually be a reference installation as per oep-45?
Learning from the configuration project
owner file or equivalent. I think this was the largest issue we found, trying to modify a role who’s maintainer or main user was not clear
public roadmap from the start
we will not be able to merge and maintain every thing that operators might want. The project should make it easy to extend this in other ways
sometimes the preprocessing of the values was the key element of a feature, but this was only a secure data thing that was never published. E.g: embargo CIDRs
Best practices
everything we have come to expect of an openedx project:
conventional commit
lots of CI actions to update, test on PRs
high test coverage. How is this achieved in helm
what are HELM specific best practices that we should adhere to?
I’ll be happy to work sync or async in the next step.