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!
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.Aulasneo! Thanks for taking the time to write this 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
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.
@Andres.Aulasneo 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
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.
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?
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?
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 
