As my GNOME OPW internship comes to a close, I think about those who come after me. I hope that OpenStack continues to have places for GNOME OPW interns in the future. In support of that vision, I would like to offer some suggestions for GNOME OPW applicants to help you get the most out of your internship. Most of these suggestions I have employed myself and have been extremely happy with the results.

Be Yourself

As you go through the process of researching the different companies offering internships and selecting a company and mentor to apply to work with, be yourself. I think outloud and I ask a lot of questions, I need to find out early which people and companies like that approach and which feel that it is inappropriate for their goals. I need to attract those who encourage me to follow my comfortable working style and the best way for me to do that is to employ that working style and be myself. Yes there are some who won’t want to work with me. There will also be some who track me down and ensure I work with them. When I do find the people who I want to work with and who want to work with me, there will be no surprises for either of us, since I was upfront about how I work.

Be Honest

Be honest about your time commitments and about your experiences. Part of being honest is saying what you have accomplished. Yes, we all wish we knew more than we did, that is a driving motivation for wanting to work in a technical field. Be honest identifying what Open Source Applications you do use and have used in the past. Be honest about what you have built, what you have created, what you have researched and what you have supported. Don’t over-inflate what you have done but don’t pave over it either. Diminishing your accomplishments actually creates detrimental energy for all of us. So be honest, and state what you have done.

Be Curious

Ask questions. One of my best tools for learning is to identify myself as an intern. During my intership that was my standard line, “Hello I am an intern and I am just learning. I would like to know more about X. Do you have some time or can you suggest a direction for a newcomer to get more familiar with X?” People like interns, at least the people I choose to work with like interns. The title of intern, for me, indicates a willingness to learn. I use that as a way of introducing myself and have met a lot of really supportive people as a result. Sometimes if the person I am speaking with has time, they will ask me questions about the internship and about the GNOME OPW program. Frequently this has led to statements from the person I am talking to that they are glad that there are more women coming into the field. This does make me feel good. So ask questions, and find the company and the mentors that are happy to get a question from an intern.

Communicate Your Status

I used a number of tools to communicate my status. Irc and gists are my favourite. Here is an early gist I composed as a combination whiteboard and note gatherer. I used the titles of the files to organize the output I copied from my terminal, the url to the bug report and some notes about what I tried and the obstacles I encountered. Putting my thoughts in a place that allows me to organize them and also share the url with my mentor or with others, really helped me to communicate my status on a regular basis so my mentor knew what I was doing.

Find a Group that Welcomes You

It doesn’t take much to say “Hello”. As you research the different companies offering internships join their irc channel and introduce yourself. I suggest something like, “Hello, I am considering applying to your company for an internship through GNOME OPW. I wanted to say Hello.” and then see what kind of response you get. Some people might not know what GNOME OPW is and may invite you to share a link to the GNOME OPW page in which case you may have just started a conversation. Try a few different organizations. Find the one that suits you best. Personally I am really impressed with the organizations that have members that take the time to return a friendly “Hello”. Our OpenStack channel for mentor/intern conversation is irc.freenode.org #openstack-opw, please do drop by and say hello.

Have a Goal

Have a goal for yourself that is larger than the internship. It doesn’t matter what your goal is but having one helps you to have your own personal perspective on what the internship means to you. It can help you when you encounter obstacles (which you will) and guide you if you need to make a decision and possibly change direction during your internship. Have a goal and clearly state it to your potential mentor. Your mentor can help you achieve your personal goal, but only if they know about it.

Meet As Many People As You Can

Meet people in the GNOME OPW program, meet people in the organization you apply to and meet people in other organizations that have internships. During the early weeks of my internship I created an IRC channel (irc.freenode.org #openstack-opw) for mentors, interns and mentors-at-large (supportive folks who weren’t a direct mentor but offered lots of support and guidance to all of us as the program proceeded). As I met new people, I invited them into the channel including two mentors with GNOME OPW that don’t work with OpenStack. There are many ways to collaborate with people and with organizations. Encouraging communication between companies with a shared experience (GNOME OPW) can be really helpful for the larger goal of continuing to ensure there is a strong base of support for future interns.

Complete the Patch Submission Requirement

Your application will not be considered without it. Last round, 1/3 of applicants did not submit a patch thereby excluding themselves before they could even be considered. It is possible to submit a patch on short notice, but submit a patch. Your application won’t be considered without it.

Have Fun

There will be times of frustration and times of great pride. Allow yourself to experience both. Have fun while you work. Bring a sense of enjoyment with you and you will find others who do the same.

This concludes the points I wanted to convey to future internship applicants.

Since this is going to be one of my final posts as intern I need to do some acknowledging.

Thank You!

I would like to say a huge thank you to my mentor, Iccha Sethi. I will be the first to admit that I am not the easiest person to lead and Iccha worked with me all the way through the application process, getting me set up with a development environment and submitting my patches. She listened, heard what was important to me, worked with me when I fell down and celebrated my accomplishments with me. Thank you Iccha!

I am so glad I had peers working through my internship, and I am so glad they were Laura Alves and Victoria Martinez de la Cruz. I appreciate your kindness, your determination and am proud of all you have achieved in your internship. I look forward to continue working with you both.

This program never would have come together if not for the hard work of Anne Gentle and Stefano Maffulli (otherwise known as reed), thanks so much for everything you have done for me both personally and as an intern with the GNOME OPW program.

Anne and Julie Pichon were mentors in the program and I thank you for both your help and support. It has been truly wonderful to work with so many intelligent creative women. Thank you for all that you do.

Thank you Marina Zhurakhinskaya. I am so glad you and Karen put so much energy into making this program work. It has been my pleasure to work with you.

I would also like to acknowledge some of the people who helped me along the way: markmc, russellb, pabelanger, jog0, bcwaldon, ewindisch, pleia2, flaper87, marktraceur, jfuerth, samanah, mordred, jeblair, fungi, clarkb, and zaro. Thank you so much for just being you, for helping when you could and providing support and guidance. I have enjoyed working with you all so much over the internship. Thank you.

Now for the good news. I get to keep working with you.

I have accepted at a position with a company allowing me to continue working on OpenStack. I plan to start with eNovance next week. I am looking forward to my new job and am thrilled that it means I get to keep working with all of you on OpenStack.

Thank you so much for all of your support!
Anita Kuno

From the time I created the topic branch until the time patchset #2 was approved and getting verified, the file the patch applied to had changed. I got the message from Jenkins to “Please rebase your change and upload a new patchset.”

I have been getting confident submitting patches, receiving reviews, editing my patches and resubmitting but having to rebase my patch and upload a new patchset was new for me.

I looked at some documentation, on our OpenStack workflow and also on git rebase. I decided to go with: git status #I was on my clean topic branch
git checkout master
git pull
git checkout my-topic-branch
git rebase master

This patch only dealt with one file, tools/pip-requires. I consulted with a collegue and was advised to use the following steps which worked:
vi tools/pip-requires #resolve the conflict in the file and save the changes
git add tools/pip-requires && git rebase --continue
This got me the following message, “Applying: Added PyRSS2Gen and python-swiftclient to pip-requires to satisfy the openstackwatch dependency.”
git status was clean
git review submitted the new patchset to gerrit.

An easy addition to the workflow but since it was the first time I had to do it I figured it was worth a quick post.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

Every OpenStack contributor wants their patches reviewed and I am the same. Getting good feedback or an approval helps to achieve the mission the patch was created for in the first place, to add a feature or fix a bug. One of the best ways to get your patch reviewed is by reviewing patches submitted by others. People recognize the name of their patch reviewers and are appreciative. If people know you, your submitted patch might get their attention faster than if they don’t know you. Providing good reviews for patches also helps you to write good patches with concise patch titles and accurate descriptions, all part of a good patch.

Let’s take a look at a few points that might help you get started reviewing patches.

First of all, you will never know enough to totally feel confident before you begin reviewing patches, you just have to do it. If you are waiting to feel confident before you begin, you will never get the practice you need to feel confident.

Anyone who is signed in to review.openstack.org can review a patch.

If you have received reviews in the past on your own patches, consider the most helpful comments you received and try to offer the same kind of support to the creator of patches you review. All of us are learning, and helpful review comments can really provide a lot of guidance for patch composers as they work to create an effective patch.

To get started, select a project in OpenStack that appeals to you. If you haven’t selected a project that you like yet, join irc.freenode.org and ask for some guidance in selecting a project to learn to review in either the #openstack-dev or #openstack-101 channels. (The #openstack-dev channel is for all contributors and the #openstack-101 channel is for new contributors.)

Then look for patches to that project on review.openstack.org and read some of the prior reviews to patches. Look particularly for inline comments.

Here are some examples of inline comments to my patches that I found particularly helpful:
This inline comment is a question. It provides a line of code for me to insert, with correct syntax, if I agree with the question as it is asked. This comment identifies the place in the code where the suggested code should be inserted, that is part of the usefulness of inline comments. Finding the right location in the existing code, for the code that I wish to submit, to be inserted is some of the most helpful feedback I can get.

This inline comment provides some feedback in the form of a short part of a stacktrace on the placement of my current code. It then follows up with a suggestion for a better place for my edit to be located. Getting a downvote is helpful, getting a downvote with guidance on how to achieve an upvote is the best kind of downvote.

In this patch I offered some comments on patch set #1 regarding some grammar in the commit message. It may seem like an inconsequential comment, but many contributors to OpenStack do not have English as a first language and a gently worded grammar suggestion is often appreciated. So in this case, my only contribution was some grammar suggestions but it was a contribution good enough for me to review the patch.

Finding nice small patches to review, like this one, can help you gain some confidence. There are still many patches that I just can’t begin to review, this one, is an example. Also this one. This patch is motivated from such a history in the code I haven’t had time to comprehend all that came before so I have no review to offer at this time.

Here is a comment I offered on a minor syntax correction. I used an inline comment to identify the line of code that needed editing, I explained the edit and offered a link to an example of code and then offered a correct code line for the patch composer to copy. These are the kinds of things that help me to improve my patches as I get them ready for approval, so it makes sense to me to offer them to others. Providing patch reviews like this may seem like a lot of work, but the feeling when I get reviews of this nature, with this much supportive detail in them, on my patches makes the work worthwhile.

Find small patches, offer what you can and identify what you are evaluating in the comments. Right now on some patches I can only offer an evaluation of syntax consistency so I state that in my comments.

I hope this post has been helpful to you and I encourage you to start doing some patch reviews if you haven’t already.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

I have finished two-thirds of my internship. Let’s take a look at what I can measure.

I have compiled the following stats on my OpenStack accomplishments to date:
blueprints - 1
merged patches - 13
abandoned patches - 3
patches in review - 2
bug reports filed - 3
bugs fixed - 4
bugs closed - 6
reviews - 20
launchpad karma - 309
blog - 18 posts
projects: 13 - OpenStack/Api-Site, OpenStack-CI, OpenStack-Infra/Config, OpenStack-Infra/Git-review, Openstack-Infra/Puppet-dashboard, Openstack-Infra/Jeepyb, Cinderclient, Glance, Glanceclient, Nova, Novaclient, Horizon, Oslo

Is this what I expected? I don’t know how to answer that question. I didn’t really have any kind of number for patched submitted or reviewed when I started the intership, so I guess all I can say is I don’t know what I expected.

I am happy with the number of projects/repos that I have contributed code to, since my overall goal for myself was to get as broad a picture as possible of the various projects and how they interrelate in the time allotted for the internship. I am happy to read the list of projects I learned enough about so that I could make an acceptable contribution.

I have been working with the Infra team the last few weeks and I have noted that my rate of bug fixing patches has gone down in that time but my rate of posting reviews has gone up and my rate of merged patches has stayed about the same. So Infra, for me, has a different workflow compared to the other project work I was doing. I find I am looking at bugs less and spending time on building functionality and contributing to reviews. This seems to fit the workflow and needs of the Infra team, so it is all good as far as I am concerned.

What else can I say I have learned and accomplished? I have a much deeper understanding of git then when I began my internship. I have more knowledge in this area than I have blogged about yet, since figuring out a way to convey that understanding with graphics and words takes some time. I also have a better understanding of the OpenStack release cycle now than I did before my internship, so now a lot of parts of the OpenStack workflow make more sense to me.

I have learned about puppet resources, started on salt, learned about how huge nova is and also seen firsthand the uniqueness of some of the various projects. I have not yet worked with the code for some projects, like swift for example, and only have a cursory understanding of its functionality from a lovely conversation in #openstack-101.

Up until this point my focus has been very wide, looking to consume as much information as I could cram in during my intership. Now I think I need to re-focus and look to the connections I have already made, conclude the items I agreed to shepherd through the process and consolidate my time so that what I do now can serve as a useful bridge for what comes next. Hopefully what comes next for me is a long and mutually beneficial relationship with the OpenStack community.

Thanks so much for your continued patience and support.

Thanks for helping this GNOME OPW intern,
Anita Kuno.

Last weekend we updated the OpenStack Individual Contributor Liscense Agreement and all OpenStack contributors needed to sign a new individual agreement (those for which the individual agreement applies).

We graphed the data of the total number of signed forms for each time the total increased by one newly signed form.

The time in epoch seconds has been converted to human readable format using UTC as a time zone.

As we looked at the data, fungi had the following to say:
“The rate is more linear than I anticipated… I was expecting it to level out faster than it is. At a glance, I can see that not many people signed over the weekend, that more signed on Monday than other days (possibly representing ~daily committers), but that the two-day and three-day committers seem to be in somewhat similar proportion. Also, the smoothness suggests that the contributor base are spread out across timezones fairly evenly, or at least their work patterns are spread out around the clock even if they are possibly less evenly distributed geographically.”

I couldn’t have said it better myself.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

The fix? Go here and sign the new contributor agreement.

You will also need to ensure you are a member of the OpenStack Foundation. Use the same email you used to sign up with Gerrit.

Multiple emails? Go here and use your ‘Preferred Email’ to sign up with the Foundation.

Already a Foundation member and got this message, “You may not be a member of the foundation registered under this email address”? Ensure your ‘Preferred Email’ listed in your Gerrit settings is also listed as the primary email address in your Foundation profile.

Attempted to submit a patch for review and got this message, “fatal: ICLA contributor agreement requires current contact information”? Go to this page and ensure one of Mailing Address, Country, Phone Number or Fax Number has a value.

Why is the contribtor agreement expired?

Still not working? irc.freenode.net #openstack-infra

Thanks,
Anita Kuno.

Git Init

I learned upon inspection that the following files contained either text or scripts supportive of git but not directly required for this exercise so I deleted them to streamline the visuals.

I removed:
.git/hooks
.git/info
.git/description

This left me with the following directory structure:

Creating a file does not change the git directory. Adding a file does.

Git Add

So after the first file is staged, the file .git/index is created. Also the directory .git/objects/44 is created and has a file named with a hash. But there is no log yet.

Git Commit

The file COMMITEDIT_MSG is created, containing the first edit message. Two more objects are created, each with a directory and file.

The logs directory is created with the file HEAD containing the information for the commit: the parent, the current id, user.name, creation time and the status. The logs directory also has the path refs/heads leading to file master, which contains the same information as .git/logs/HEAD There is also a new file, master, in .git/refs/heads the content of which is the hash pointing to the initial commit. So right now, of the files I can read, what is pointing to the commit?
.git/refs/heads/master
.git/logs/HEAD
.git/logs/refs/heads/master
The file .git/index might be pointing to the initial commit as well, I don’t know because I can’t read it.

Git Checkout -b Topic

No new objects are created when a new branch is created. Two new files are created, one under .git/refs/heads/name_of_branch, in this case, feature, and one under .git/logs/refs/heads/name_of_branch.

Both files contain the hash of the initial commit, the file under the logs directory also contains the hash of the the parent commit, id of the current commit, user.name of the branch creator as well as the time of creation for the branch, and the type of action it is, in this case: branch: Created from HEAD.

Git Add

The only thing that is created when a file is added to staging is an object, with its directory and file.

Git Commit

So two new objects were created, they each have a directory and a file.

The git log command shows me the log for the branch I am in, in this case the topic branch named ‘feature’.

Git Checkout Master

Git Add

Git Commit

I now have 9 objects.

The git log command shows me the log for the branch I am in at the time of running the command.

Git Merge

Make sure you know where you are with git status prior to merging!

Two objects got created, and a new file called .git/ORIG_HEAD.

After the merge, executing git log from the master branch shows all my commits made in both the master branch and the merged topic branch named feature in the chronological order in which they were created.

I hope you get something useful from this post.

Thank you for supporting this GNOME OPW intern,
Anita Kuno.

We are at that moment in the release cycle where knowing at least a little bit about the release cycle is in order. I do better when I have an image or symbol to work with so I created the above graphic.

I went with the image of a nautilus shell for two reasons. One, it is pretty and I like it as a visual and two, it is an interesting symbol of a process that is continually growing and expanding but also has to house the nautilus and keep it safe while constant construction is occurring.

The main spiral represents the master branch of the code, the red arrow indicating the direction of its progress based upon the path it has traveled until that point. The curved intermediate walls (called sutures, I believe) represent the release-branches. The release of Grizzly is coming up in April and is represented above by the green wall/release-branch. Prior to Grizzly was Folsom, in blue, and Essex, in orange.

We just went through code freeze and I do believe breaking off the master branch to create the first release candidate is imminent. After the release candidate is broken off, pushing patches for bug fixes gets interesting.

When in doubt of how to submit patches with gerrit, contact the project leader for the project in question. My basic understanding is that the bugs submitted against the release candidate need the patch applied first to the master branch and the backported to the milestone-proposed branch. Again, talk to the project lead to ensure you are using the correct gerrit commands for the patch to apply to the correct branch: master or milestone-proposed.

I will be working my way through this process for the first time, so this post might go through an edit or two as my understanding matures.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

When I first started developing with my Devstack installation I was told to use ./run_tests.sh to run the test suite and that was good enough for me. Then I began to see some other commands to run tests, tox -epy27, tox -epep8 and I ran the commands but didn’t fully understand why some commands are better than others.

Then I had to run some tests in /opt/stack/nova and every command I ran failed. Why? I didn’t know. But now I do.

Recently there has been a move in the repos to testr from nosetests. I got caught in this and have learned a bit about how to dig myself out of this hole.

First of all I am running Ubuntu 12.04 and when I first installed the OS I also installed: apt-get install git libxml2-dev libxslt1-dev and after installing devstack I installed tox with pip install tox. I also had python 2.7 on my machine and wanted to install 2.6 for testing which I did with apt-get install python-software-properties, add-apt-repository ppa:j5-dev/python2.6, apt-get update, apt-get install python2.6 python2.6-dev. I also learned I needed the mysql development libraries which I got with apt-get install mysql-client libmysqlclient-dev.

So I followed my current workflow upon cd’ing into a new directory: git status, git pull, rm -rf .venv, sudo python setup.py install. Then I tried both ./run_tests.sh which failed and tox which failed.

I found out that the “Error: pg_config executable not found.” in my output was due to missing the libpq-dev in Ubuntu (rhel is postgresql-devel).

I also learned that this error output “Please install a more recent version first, using ‘easy_install -U distribute’.” suggesting that running easy_install -U distribute might solve the problem didn’t for me. Distribute is bundled by virtualenv which is used by tox. The solution? Upgrade tox with pip install tox --upgrade.

Also when running tox if I got an error “invalid command ‘testr’” I learned that tox -r will create an updated test environment using testr and the tests passed for me. So if I run tox -r I don’t need to remove the virtual environment with rm -rf .venv since the -r flag to tox will rebuild venv from stratch.

So right now my workflow is to run tests with tox which runs tests against python 2.6 and 2.7 (since I have both installed) and pep8 or tox -epy26 for just testing against python 2.6, tox -epy27 for testing just against python 2.7 and tox -epep8 for just running the pep8 tests. If you are inclined, taking a peek into tox.ini will show you the configuration for the different environments. Some tox environments are not run by default but can be helpful for debugging and cleanup, an example would be pyflakes.

I hope this information is helpful to you.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

Yesterday marked the end of my first 4 weeks as an intern working on OpenStack. I have merged code for 1 feature and 2 bug fixes. I also wrote code that I abandoned which was necessary to close a bug. It may not sound like much but I am pretty happy with what I have accomplished.

I would like to thank my mentor, Iccha Sethi, for helping me so much by requiring my status updates, helping me set deadlines, encouraging me to reach out to others and challenging me to learn new skills. Thank you, Iccha. I also want to thank the other interns Laura Alves and Victoria Martínez de la Cruz for being so wonderful to work with and so supportive as I learn these new skills. Laura’s mentor Anne Gentle and Vicky’s mentor Julie Pichon are wonderfully helpful to all of us, thank you to them. We also have some mentors-at-large in the form of Mark McLoughlin, Russell Bryant and Brian Waldon, thank you to you. We all learn so much every time you explain the nuance of a situation, which we couldn’t get from a manual.

If you, as reader of this blog post, feel like joining in supporting our learning, you too are welcome to join us in #openstack-opw on the freenode server.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.