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

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.

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 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.

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.

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.

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.

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.

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.

For some reason, when I turned to debugging one day I couldn’t get it to work and I couldn’t figure out why (I will explain the solution at the conclusion of this post). Fortunately I had a great guide in the form of russellb who likes to use logging and just happened to be willing to make a bit of time for me. What follows is what I learned about logging.

Logging

Logging is useful to see the status of something either as it is running or after it has run. If you are using Devstack (as I am) you already have access to continual logging of processes via the screen tool. When Devstack installs it sets up a window for each process, so executing a variation of screen -r stack gets you in to view the process logs as each process runs and updates the log. (Remember to exit screen with Ctrl+a d to detach the shell from screen while leaving screen running.) Now I am learning to parse these logs slowly but the point is they exist, which I needed pointed out to me so I am glad I know now.

Next is setting up logging to provide output for a local process I am working on understanding and addressing. The simplest example involves adding import logging to the top of the file, creating an instance of logging with LOG = logging.getLogger(__name__) outside of any of the classes and then an individual log statement inside the class and function you wish to explore LOG.debug('class.function was called").

Examples are gold to me, so lets work with this as a series of incremental examples.

First the bare minimum to get some logging working:

If this were the contents of a file entitled logging_example_01.py, you could expect the following output:

Let’s see what other kind of logging statements are available.

Here is the expected output:

As you can see, critical, warning and error logging messages were output and debug and info messages were skipped.

How do we get the debug and info messages output? We have to change the logging level.

By passing level=logging.INFO as an argument to basicConfig() we set the logging level to INFO.

Alas, our debug message still is not output. We change the logging level once again, this time to DEBUG.

Now we see all of our logging messages:

We are ready to put this knowledge to use in an OpenStack project file.

I was working with glanceclient Image.delete so let’s look at putting logging in that file. With the imported files add a line with import logging. Below the constants SORT_DIR_VALUES and SORT_KEY_VALUES add LOG = logging.getLogger(__name__). We don’t need the logging.basicConfig() line of code since this is taken care of for us elsewhere. This is the set up, finally the execution with the logging statement. Within the Image class inside the delete() function add LOG.debug('ImageManager.delete was called').

After I make these edits and save the file I have to reinstall the client with sudo python setup.py install otherwise my edits will not take effect. Then I can run glance --debug image-delete <image_id> and my log message will be output, amongst the rest of the debugging information.

This is what I understand about logging so far, and it is very helpful to have this as a tool.

Debugging

The only code I need for debugging is import pdb set at the top of the file with the other imports (alphabetically) and pdb.set_trace() wherever I want the trace to start. But here is the key, which I didn’t know until I was learning logging with russellb, after I edit the file to include the import and set_trace() I have to reinstall the client with sudo python setup.py install otherwise no debugging happens. Also after I remove the debugging code I must again reinstall the client to have my working code reflect the code in the files.

If you reached the end, I thank you. Here is a cat picture for you to enjoy.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

My first inclination was to find a command for OpenStack along the lines of source ~/.bashrc but there was no command I could find.

It wasn’t until I pulled from a git repo that had moved to testtools that I recognized that sudo python setup.py install, executed within the root directory of the project, rebooted the shell to update the version of shell.py that it was sourcing.

I don’t know if this is the only way to reboot the shell when working on changes to shell.py, but so far it seems to be an effective way.

Since I got caught this week moving back to the master branch with a clean git status but with stale responses to shell help, I now incorporate sudo python setup.py install as part of my workflow. I already executed git status and ./run_tests.sh everywhere I went and I just throw in sudo python setup.py install if ever I have less than full confidence that the shell responses are reflective of the shell.py code in the repo in which I am located.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

Why am I visualizing novaclient this way? Well since I am just getting my bearings regarding the code the first thing I need to do is look for landmarks. It was really confusing seeing python-novaclient/novaclient in the path at first and seeing nova/nova in the nova project really threw me at first but I am starting to understand the purpose behind the file structure.

My big landmarks are the directories: python-novalclient, novaclient and openstack or v1. The openstack directory is at the same level as v1 (directly underneath novaclient) and the common directory is underneath the openstack directory, so why have I visualized it this way? Well for the sake of simplicity I like to visualize one path of flow and functionally v1 is imported by files within common and openstack so I consider openstack-common to be one entity and for it to be above the code flow of v1. The v1 stands for version 1 and in the projects with a second version of code to interact with the API, the directory is called v2. When novaclient has a v2 directory it will be at the same level in my mental model as v1, so a fork.

I cherry picked file names to place in this graphic. Why, because there are so many of them. At a certain point it becomes too much data to see the pattern and I mostly wanted to illustrate the mental pattern I am working with right now. I picked the files I have spent the most time in so far.

This graphic might seem simplistic or silly but it took me about 2 weeks to adopt this mental picture and another week to be able to communicate it. Not directly contributing to code but knowing where to look is a very valuable skill. I feel in some regards I am learning how to narrow down my search when looking for the location of a specific function.

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

While playing with the debugger set-up in my previous post, I saw that it took me through authenticate() in a rather tidy fashion so I thought I would spend a little time here.

I won’t walk through the entire function, just the first part. We will be looking at the consequences of stepping through parts of the code below. This is from novaclient/client.py:

With the help of the debugger I will be looking at the values of the various arguments and variables both before and after they are defined, and in the case of key and index as their value changes.

So the debugger heads into authenticate(). Before the first line (#301) is executed, I check the values of self and self.authenticate().

Then I check the value of has_keyring: before line #302 runs.

Lines #303 - #305 take a list of values and assigns them to the variable keys. I check the value of keys, which I learn is undefined before the code runs (makes sense) and also the individual values of all the attributes in the list.

After lines #303 - #305 have run, I check the value of keys.

Next we move into lines #306 and #307 which run in a loop 4 times before breaking out to execute line #308. I check the value of key and index during the process. These variables begin as undefined and then their value changes as the code runs through the for loop.

Then back into lines #306 and #307 3 more times before breaking out to execute line #308.

Then we loop through lines #306 - #308 one last time.

We go back up to line #306 but we have enumerated over every element in the list, so then we execute lines #309 and #310, checking the values of the variables as we go.

We have come to the last line of code in this examination, line #325. We check the values before it is executed and after execution it takes us into the function urlsplit() in the python library urlparse.py.

I hope that stepping through the authenticate function with me has been useful for you. I learned a lot creating this post. For learning a code base, I feel that using a debugger can be a very powerful tool.

We didn’t go through the entire authenticate function, but the part that we did takes the various attributes of the HTTPClient object and creates a url to be parsed. I found the investigation rather fun.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

The first thing I had to do was select a debugger. I went with pdb, the python debugger that comes with python, simply because it was the easiest. I knew I needed to get the debugger working with OpenStack and I felt that the integration step would be my trickiest part so I elected for the simplest version of a debugger I could find and it appears that my decision to go with pdb was the right decision for me.

Then I had to learn how to use the debugger in a vanilla set-up. Since I didn’t know how the python debugger worked before I began, I spent some time with a few tutorial blog posts and am glad that I did. First I went here to go through the debugging A B C’s. I found it to be an easy tutorial and a great introduction. This tutorial showed me how to drop into the debugger by calling both the debugger and a file name from the command line.

I knew I wanted to access the debugger from the console so this was a great next tutorial. It creates a class in a file and then calls an instance of the class from the console with pdb.run(). It also calls the debugger after an exception with pdb.pm(). I liked the look of pdb.pm() since it could be invoked after an error or exception but every time I tried it, regardless of the pdb command I used, the debugger exited rather than stepping through the code. Initially I thought it was due to a mistake I made, but after further investigation I now believe that this seems to be the intended action of pdb.pm() though I have no idea why.

So while the second tutorial was helpful to show me that using the debugger from the console/interpreter was possible, I didn’t have the exact syntax I needed for my situation. Next I worked with this tutorial, rather long but for my purposes it gave me what I needed. The first part was the most helpful for me, I found the code for the last exercise - the advanced portion - didn’t match the output the tutorial displayed. I tried to locate the author but was unsuccessful.

So I decided to go with pdb import at the top of the file I wanted to start to step through and pdb.set_trace() at the location in the code where I wanted to drop into the debugger. Look at line #7 and line #43 in the code below. Line #44 was the beginning of the code I edited, which I wanted to evaluate, so I placed pdb.set_trace() on the line prior.

Next I needed to create an instance of novaclient in the python console. So I opened a console in my OpenStack development environment, imported the class for the client and created an instance.
python
import novaclient.v1_1.client
client = novaclient.v1_1.client.Client('admin', '<admin_password>', 'admin', 'http://50.56.25.223:5000/v2.0') Your ip will be different than mine but :5000/v2.0 should work for you, that is until it changes. So check the date on this blog post.

Then I requested the client fetch me an image by passing in the id of an existing image, which I had gotten with nova image-list earlier.
client.images.get('9e44f0ee-083d-40a4-804c-534d66fb15ac')

Now without pdb.set_trace() in the images.py code, the output to client.images.get(image id) is something like this:
<Image: cirros-0.3.0-x86_64-uec>

But with pdb.set_trace() in the images.py file, I got:

… and I’m in the debugger. Which was my goal.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

I find that posting my status is my way of inviting comment without depending upon it. If my mentor has questions about what I am doing or how I am progressing, hopefully my status updates can help her keep tabs on me. If she has any thing to offer, a new direction, a suggestion, some support, she can post in response to an update. By continually posting my status without being asked, I allow her to check in as she has time, without having to wait for her to ask. It gives me the responsibility of scheduling my time productively and selecting tasks I can do on my own while incorporating feedback as it arrives.

It is serving a good secondary purpose. It is helping me to track when I am stuck and when I am not. If I am able to articulate my status, I probably am making productive use of my time. If I can’t answer the question “What are you doing?” with anything other than the response “foundering” it is probably time to seek some guidance.

The one caveat that I would add is the 3 day rule, in any new undertaking or situation I give myself 3 days to just be in the environment, with permission to not know anything and just listen and read and search and look and get my bearings. After 3 days, something just happens and some things which were completely unstructured just fall into place.

So I find that volunteering and posting my status, continually throughout the day for my mentor, contributes to a good work flow between us.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

The Devstack project sets up an OpenStack development environment rather quickly (the downloads take a while) with one script. Devstack.

Devstack has been tested on both Ubuntu Server 12.04 and Fedora 17. I have tried it on both and am most familiar with Ubuntu Server so that is the environment I will address going forward. The only thing I have noticed with Fedora is the necessity to disable selinux after the OS is installed.

So install Ubuntu Server 12.04 as an openssh server. Once installation is finished and you have rebooted and signed in, I like to execute the following: sudo apt-get install git libxml2-dev libxslt1-dev eatmydata lynx irssi vim-gtk. The two libs are necessary to run some of the OpenStack module tests and aren’t installed with Devstack. Git is required for Devstack to install properly, eatmydata is useful when running the OpenStack tests. I like to have lynx and irssi around in case I need them. Vim-gtk has a few more features than the default Ubuntu vim so I grab that too.

After apt-get is finished, I generate some keys and then configure my git: git config -- global user.editor "Vim", and also user.name "My Name", and user.email "Must Match Email in Gerrit".

Then I get Devstack: git clone git://github.com/openstack-dev/devstack.git and then cd devstack; cp samples/localrc .; vi localrc and add the following lines to localrc:
FLOATING_RANGE=192.168.1.224/27
FIXED_RANGE=10.0.0.0/24
FIXED_NETWORK_SIZE=256
FLAT_INTERFACE=eth0
then close localrc and run ./stack.sh. Full Guide Here

Usually Devstack installs successfully but the last couple of installations have exited with non-specific failure messages although everything seems to be running.

After Devstack is finished, execute source ~/devstack/openrc.

I test my installation by executing nova image-list, if I get a list of images I am usually in good shape.

The other thing I do is execute screen -r stack and see if all 17 processes have windows. Less then 17 processes and I may have to stop devstack with ./unstack.sh and restart with ./stack.sh. Detach screen with Ctrl-a d since you want screen to continue running.

This is basically the format I follow to install Devstack on Ubuntu Server 12.04.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

At the moment, I am working with IRC as my main form of communication and I have a private dialog window open with my mentor during my workdays. At the conclusion of every workday I copy the text of our interactions and save it to a Tomboy note. Tomboy notes are very flexible and I really like that I can search all of my notes from the main Tomboy page. Iccha, my mentor, often tells me commands or file paths in IRC that are helpful. Being able to search my notes for that command again or access a conversation or url from the day previous is really quite easy. Using a private dialog in IRC and and saving the text to Tomboy notes is working well for me.

I have a google document shared with my mentor and myself and I try to keep it updated as often as I can. I try for once or twice a day. It is a good place for summaries, ideas that carry over from day to day and urls for extra reading. It is nice because the viewers of the document can be administered and I can access the document easily from my browser.

I have been using a blank text file as a whiteboard in my local environment as a place to write pseudo code and collect my thoughts. Yesterday I expanded that idea to this gist. I like that the gist is private within github but I can also share the url with whomever I would like to access the information, readers of this blog for instance. I am still getting the hang of using comments on bug reports to communicate so I created this gist to explain my work and my thought processes to the creator of the bug and get his input going forward. Since it gives an up-to-date status of my understanding, after creating it, my mental energy was free to move onto other things, like blogging while waiting to communicate with the originator of the bug report. I like to have my mental work in tidy packages so that I can view a new and separate task with my full attention. Creating this gist as a whiteboard really served that purpose for me.

Taking notes will evolve as I go along and I am glad to learn new methods to make the best use of how I like to organize my mental space.

Thanks for supporting this GNOME OPW intern,
Anita Kuno.

Shruti (who blogs here) lives in India and is currently a student. She found out about the GNOME Outreach Program for Women through her love of OpenStack (via Facebook) and had contacted the same mentor as myself, Iccha. Iccha introduced us via email and we have been working together as a team since that introduction.

It was funny the way it worked out, we met each other the day prior to American Thanksgiving, which Iccha being in the US celebrates and neither Shruti or I do (I’m in Canada). So there we were, neither Shruti or I really knowing what we were doing, trying to get devstack working. Off to IRC we go.

I had previously met jpich on IRC and introduced her and Shruti. We had a lively interaction understanding various error messages and reading documentation trying to get operational environments on our respective systems.

Now had Shruti or I approached a different mentor or had Iccha not introduced us, I may have spent my time flailing away by myself waiting for Iccha to resurface after her holidays. By introducing us to each other and leaving us to figure it out on our own, we filled in the gaps ourselves and continued to work away, asking questions, having doubts, making mistakes, reading documentation and having success. Success is nicer when you have someone to share it with.

I’m not sure if this is quite the way the GNOME Outreach Program for Women is supposed to work, but this is how it is working for us. We have a daily email thread where Shruti and I share with Iccha our initial topic for the day with intended next steps. This allows for feedback and suggestions from the other two. When one of us is unavailable perhaps the other can offer something supportive if only an ascii smile.

We have good conversations with other OpenStack mentors and OpenStackers not involved in the program at all. Turns out they are genuinely nice even if they don’t know we are applicants.

I also think we encourage each other. Having another applicant to work with is a better gauge of accomplishment than comparing ones work with the mentor. I think it heartens me to work with another applicant and I am glad it is Shruti. She is friendly and intelligent and a hard worker.

I really like the energy we have created between and amongst us during the application process and I hope we can continue to grow and expand it during the execution of the program.

Thanks for reading,
Anita Kuno.

About a year ago, I wandered into the Mozilla channel and received a lot of support when I identified myself as someone wanting to learn how to contribute. I had at least two people in the channel giving me their full attention and support. And yet I failed. I wasn’t able to navigate the process and I couldn’t put any more energy into trying. Life intervened and the necessity to feed dependants and take care of daily activities eliminated the brief burst of energy I had. I never made it back into the Mozilla channel after that first visit.

I am a big open source software consumer and I love to make useful contributions to products I believe are worthy. It wasn’t for lack of desire on my part or lack of welcome on the behalf of those in the Mozilla channel. It was all the other stuff that had to be dealt with to get to the point of committing a patch.

So what is different now? How was I able to commit a patch to OpenStack when I couldn’t figure it out with Mozilla? Well there are a couple differences, let me discuss them.

Money. Yeah, I don’t want to be crass, but money makes a difference. The GNOME Outreach Program for Women provides a stipend which when I devote my 40 hours per week to the project, I can buy groceries. I don’t have to do the work and figure out to buy groceries, I can focus on the work knowing I can also eat at the same time. Might sound not worth discussing to some, but to me it is a mainstay in any kind of learning/internship/apprenticeship program in which I have participated and I have participated in a few. So money isn’t the reason but it does make a contribution possible, for me at least.

Identified mentors available via IRC, email and Google Hangout (I think other venues are possible but these are the ones suggested and implemented thus far). Also the mentors checked in with me. Iccha knew I was considering applying and followed up with me, asking me questions about what I would like, offering me links and information, setting up times to meet with me. So for the brief time I was sitting on the fence, a mentor knew my status and helped me to make up my mind. That too counts for a lot.

The duration of the interaction also helps, I didn’t need to get everything done in one day. Many of the projects require specialized environments for executing and testing code and these environments don’t get installed by a n00b in one sitting. Having someone come to me and purposefully decide to help me as I tried and made mistakes and reinstalled and tried again made the difference for me to persist through multiple failures to ensure that I had an environment to edit code and successfully submit a patch.

Open source software is all about code but it also has a very large framework consisting of individuals who have a very specific way of working. By working together over several days, certainly at least a week if not two, I am starting to learn the people and the process. The edit itself took less than 5 seconds. Setting up the environment and learning the culture in order to enable me to edit the code and submit the patch with confidence? At least a week. Creating an environment filled with great people allowing me to take the week I needed is the difference between this successful commit and my prior failed attempt.

Thanks for reading,
Anita Kuno.