My first PR + what's blocking me

Hi all,
Thanks @regis for the BTR call today. I have a small bug fix that I would like to submit. It is about the paver update assets command that will not update certificates assets properly. I have found the way to fix it in the code and can submit it easily.

Basically what is blocking me is the devstack installation. Currently my production stacks run Ironwood. But my contributions should go to the master branch. Therefore, I MUST have (at least) two devstacks up and running, and be able to switch among them easily.
I have followed this guide but it didn’t work. May be because of the mongodb upgrade? May be because I tried to use nfs sync in juniper but it’s not available in ironwood?

If anybody can help having my multiple devstacks up and running I will appreciate!

@andres would you mind submitting a patch without having the devstack?

Hi @omar,

Actually I’m more interested in documenting the whole PR process (I’m working on this Open edX contributor’s guide) than in the patch itself… I believe it is better to submit patches from devstack, where I can test and debug, rather than from the production. What do you think?

Anyway considering that soon I will have to move production to Juniper, I will no longer need Ironwood. So now I am trying to have master and juniper.master devstacks (getting rid of Ironwood).

Hi @andres! Thanks for taking the time to write this :slight_smile: As I said during the meetup, we want you to submit your PR because a) it would resolve a bug b) but it would also onboard a new developer (you) c) without us putting in too much effort :stuck_out_tongue:

So let’s get you started!

First of all, is there an experienced developer who would like to mentor Andres during this process? Ping the usual suspects: @nedbat @sambapete @pdpinch @omar @antoviaque but also @Zachary_Trabookis who recently worked on the Devstack. If not, I’ll volunteer.

Meanwhile, can you please describe what exactly did not work with the multi-devstack setup? A summary of commands and a stacktrace would be great. Also, keep in mind that you always have the option of storing your devstacks in different folders and run them separately, as we all did in the old days.

1 Like

@andres Did you follow these steps to switch between the different releases?

Switch between your Devstack releases by doing the following:

It is important to make sure that you stop all running containers for an existing Open edX devstack prior to setting the OPENEDX_RELEASE environment variable. Those instructions above mention that. At this time you cannot have two separate devstack releases running simultaneously since the similar ports would be used for the containers for each release.

I prefer to use direnv now to configure my environment variables because as I cd into a directory from with the terminal window it redefines my variables based on the release .envrc file. Follow these instructions on setting direnv up.

How do I switch releases using ‘direnv’?

My suspicion is that you didn’t shutdown all the containers from current running release prior to starting up the next release. You can check to see if the containers are running by issuing the following command. Make sure that mongo and mysql containers have fully stopped; I noticed that sometimes they don’t always stop.

(venv)ztraboo@194 devstack.juniper % docker container ls --all --format 'table {{.Names}}\t{{.Status}}'
NAMES                                                STATUS
edx.devstack-juniper.master.mysql                    Up 5 days
edx.devstack-juniper.master.xqueue                   Exited (137) 7 weeks ago
edx.devstack-juniper.master.gradebook                Up 5 days
edx.devstack-juniper.master.frontend-app-publisher   Up 5 days
edx.devstack-juniper.master.edx_notes_api            Up 5 days
edx.devstack-juniper.master.credentials              Up 5 days
edx.devstack-juniper.master.ecommerce                Up 5 days
edx.devstack-juniper.master.studio                   Up 5 days
edx.devstack-juniper.master.lms                      Up 5 days
edx.devstack-juniper.master.forum                    Up 5 days
edx.devstack-juniper.master.discovery                Up 5 days
edx.devstack-juniper.master.elasticsearch            Up 5 days
edx.devstack-juniper.master.devpi                    Up 5 days
edx.devstack-juniper.master.memcached                Up 5 days
edx.devstack-juniper.master.firefox                  Up 5 days
edx.devstack-juniper.master.chrome                   Up 5 days
edx.devstack-juniper.master.mongo                    Up 5 days

Thanks @Zachary_Trabookis for responding!

Well, I decided to start from scratch. And also to discard Ironwood, and focus on having master and juniper.master.

So the first think I did is:

  1. pull master from edx/edx-platform repo
  2. added my fork as remote (aulasneo/edx-platform)
  3. pushed master to my remote
    Then I got this from github:

I’ve found also a mysqldbdump I hadn’t seen before. I don’t know how these actions came to my fork, or if they are needed at all… any idea?

@andres Sounds good about recreating your devstack. Not sure why you’re getting that error from the docker_auth call.

This is where I believe the make target is defined and called.

Someone else can reply here.

@andres This is an interesting side-effect of edx-platform that started to use Github Actions a couple months ago: https://github.com/edx/edx-platform/tree/master/.github/workflows
Obviously, this will not work for you if you don’t have edx’s credentials. I suggest you ignore past warnings and disable Github Actions on your project: https://github.com/aulasneo/edx-platform/actions/

1 Like

Ok, so I finally was able to install two devstacks: master and juniper.master. I gave up trying to run inronwood, and considering it’s short life left it’s not worth investigating.

Now trying to switch from juniper to master, I got the following error:

From github.com:edx/credentials
error: Your local changes to the following files would be overwritten by checkout:
    package-lock.json

The same happened for frontend-app-gradebook when coming back to juniper.
I’ve fixed it stashing the changed file. Shouldn’t it be included in .gitignore?

After that, I got these warnings:

Checking out branch open-release/juniper.master of frontend-app-gradebook
Switched to branch 'open-release/juniper.master'
Info: can't find node in PATH, trying to find a node binary on your system
Can't find Husky, skipping post-checkout hook
You can reinstall it using 'npm install husky --save-dev' or delete this hook
Checking out branch open-release/juniper.master of frontend-app-publisher
Switched to branch 'open-release/juniper.master'
Info: can't find node in PATH, trying to find a node binary on your system
Can't find Husky, skipping post-checkout hook
You can reinstall it using 'npm install husky --save-dev' or delete this hook

Is it serious?

BTW, I have made some updates to the README file with the getting started guide of the devstack repo, related to having multiple releases and switching among them. I will appreciate if someone can check it and validate.

Finally… I got my first PR!! https://github.com/edx/edx-platform/pull/25322

1 Like

Hi @regis, so looks like we are progressing :slight_smile:

Now I got a bit lost with two topics:

  1. I posted my PR to master. How should this PR go to the current named release master (juniper.master now)? Will the core commiter do this? Will I have to do something? Does it happen at certain times in the lifecycle?
  2. You have created this Jira ticket BTR-15. I also saw in the contributor’s guide that there is a CRI Jira project to report issues, but there are no active sprints there. It’s not clear if it is alive or not. However when I submitted the PR, the robot automatically created another ticket. What is the use of having two tickets for the same change? And if there is any use, what is each ticket for? Should I do something in the OSPR ticket?

You should backport your change to Juniper yourself by making a new PR, after the first PR is merged. This is not automatic because few changes should actually be backported to the current release.

We (the BTR working group) are handling tickets via the BTR board. We have no control over auto-generated tickets – I suppose they are used for internal organization, but I have no idea how. And I don’t know how those CRI tickets work either… Maybe you can comment on that @nberdnikov?