Making changes to a charm¶

Introduction¶

These notes are merely an extract of a painful set of actions performed one day of March 2017.

They are not meant as a comprehensive document on how to make changes to charms, please read the official documentation instead, for example:

Initial steps, becoming a developer¶

In order to be able to commit changes to Git/Gerrit you need to register yourself as a developer. The full procedure is described at the HowToContribute guide.

The main steps involved are:

subscribe to the mailing list
setup your account and sign the Individual Contributor License Agreement
join the OpenStack foundation as Foundation Member (Community member does not grant you commit rights!)
login to your account, chose a username (which is immutable), and add one or more SSH key(s)
install package git-review

Start working on a package¶

Open a bug in Launchpad¶

I opened a bug report in Launchpad, to create a bugID to be used later to reference my work in Gerrit. Okay a bug-report was a bit inappropriate in my case, as I was really publishing code to add some new functionality.

Prepare working area (Gerrit)¶

Please read the Gerrit tutorial to learn the basics of the tool.

The main steps needed to start modifying a charm are:

git clone <package_name>
cd <package_name>
instruct Git and establish the connection with Gerrit, use the same name/email/username you registered in Gerrit
- git config user.name “Name Surname”
- git config user.email “your.email@registered.in.Gerrit”
- git config –global gitreview.username <Gerrit_username>
after some Google’ing I realized I also needed to: git remote add gerrit ssh://<username>@review.openstack.org:29418/openstack/<package_name>.git
let git-review do some initial magic: git review -s
git remote update
git checkout master
git pull - - ff-only origin master
git checkout -b bug/<bugID> where bugID is the number of the bug you opened earlier in Launchpad

Prepare testing area¶

To execute the tests (based on tox) we still need to download the packages pip and tox:

sudo apt-get install python-pip
pip install tox

sudo pip install tox

N.B. The latter command “sudo pip install tox” is needed in order to run the command “make test” with sudo, because it needs root privileges.

At each development cycle¶

cd /path/to/working/area/<package_name>
make changes to the code
verify your code by running tox -e pep8 and act as advised until the tox command is happy
verify your code by running it in pre-production: for example if you are working on <package_name>=charm-keystone to produce your charm called keystone-fed you may run something like:
- charm push . cs:~csd-garr/keystone-fed which will return the new version # of the charm
- charm release cs:~csd-garr/keystone-fed-# –channel stable to publish the charm and make it public
- juju upgrade-charm <your_application> –switch cs:~csd-garr/keystone-fed-#
git add …
git commit -s -a –amend where -s adds submitted_by, -a adds reference to a changeID, –amend attaches to a previous review session (each new review needs to be approved independently, so it’s better to make few larger, linked, commits)
- before writing the commit message, PLEASE read carefully the good practice for Git commit messages especially the bad and good practices. At the very least you should add a reference to the Launchpad bugID by adding a line:
```
$ Related-Bug: #######
```
trigger automated code checking with git review

If you want to re-align with origin-master you can:

git fetch –all
git log –graph –decorate –pretty=oneline –all will show what has happened in the repository while you were modifying your fork
git merge origin/master and pay attention to possible merge errors
git log –graph –decorate –pretty=oneline –all to verify that your fork is now a direct son of origin/master