Grokking OpenStack

OpenStack - little pieces

This Was Posted Today

I can’t believe I am writing this post. I promised myself I would never write this post. I would keep my head down and work hard and make a difference and I would never have to write this story. I can’t believe I am writing this story.

I just read this post. I can’t believe this is still happening. My excuse for this kind of behaviour when it happened to me that it was the 80’s and people didn’t know any better. I guess the more things change the more they stay the same.

Teachers had always taken an interest in me, my peers not so much. Ever since they started those tests in grade 3, the teachers took a real interest in me.

It really came out in high school. My Mother was a high school teacher (small town, one high school), so all the teachers new me from the start.

Around the end of grade 10 my Biology teacher talked to my Mom about getting me to enroll in Grade 11 computer science class. I had never thought about it, but he had convinced my Mom and my Mom convinced me. I was allowed to take my music and drama classes so I agreed.

Grade 11 computer science, me, the teacher and about 9 guys. I knew them all - Mike, Sean, Tom, Jeff, Dennis - I forget who else. Been going to school with most of them since kindergarten. I thought it was going to be fun. They knew my marks, they knew I had gotten an award for my marks at Christmas exams in Grade 9. (That is a different story, I didn’t even know there was an award until a classmate marched down the hall announcing I had gotten it like I had purposely tried to injure her.) I didn’t have anything to prove to my classmates, I was looking forward to computer science.

Now to get a sense of it, keep in mind I had all my classes with these guys - Math, English, Chemistry, Phys. Ed, all my classes. In Math class for the last two years, when the teacher left the room everyone at the back (I liked to sit at the back) turned around to me to get me to explain what the teacher said. In English it was Peter, who used to sit beside me, he had a handle on Shakespeare and poetry I never had - but they turned to me in Math.

So - computer science, it was a small class - this was going to be fun.

I can’t remember the exact chronology - it has been over 25 years - but early on we did binary math. And I remember the class. The science teacher, who was teaching the computer science class, was explaining the positions in binary. All of a sudden a light went off and I got it. I went up to the board and started telling the teacher what the positions meant and talking about the positions he hadn’t gotten to yet. Then I faced the guys and explained it to them. The teacher was smiling and the guys gave me the deer in headlights look. I didn’t think anything of this since this had been happening in Math for a few years so I just kept explaining until they got it. Mike got it next - very excited - and then started telling the guys and then the rest of them got it.

I was so happy, I understood binary. This made sense to me now.

Next we did electronics and bus boards. I loved building things and this was so fun. I remember the little white plastic board and the resisters and capacitors. I remember learning about them and really understanding - it made so much sense. We each had a bus board and some parts and a module to work through.

Then I was sick one day - couldn’t go to school. We were on a system where we took our classes for the full year and had every class everyday.

I returned to school the next day. I walked into computer science class and all the guys turned to me as I walked in. The were kind of grinning. I asked them, “What?”

They showed me a melted bus board. Tom and Jeff had put in some of the components the wrong way yesterday and the board caught fire. They told me how they all jumped back and pushed the board off the desk and Jeff stomped on it with his shoe. You could still see the tread of the shoe in the cooled once-melted plastic. I didn’t think anything of it, this was not unusual behaviour for these two. They kept laughing and looking at me, “Yeah, it was your board.”

How could this be my board, I was not at school. Even if they used my board, this was not fair - they had ruined it.

The teacher was straight faced. They couldn’t get anymore boards, I would have to share.

I sat out the rest of the module as an audience for Mike. So he got to play with LEDs and make them show digits and make them blink and I got to watch him work.

I was able to do my work in Math, able to do my work in all my other classes, but in computer science I learned to be an audience.

In my work now, I am trying hard to make up for lost time. I work with good people, very smart, very hard working and they have been very welcoming toward me. I tell myself not to let what happened in high school bother me, it was so long ago. I have an opportunity to learn some things now and I have learned a lot.

But I can’t be silent if I see this is still happening. I have worked so hard to make a difference in my life and in the lives of those who would let me. I read this story and I realize that it doesn’t make any difference at all.

They say that for every negative person in your life you have to have 9 times that many good experiences just to break even. I feel like I’m not doing enough. I can never stop those who would hurt or belittle others, there are just too many of them. All I can hope to do is be one of the 9 people this person meets in their life, just so they can break even.

Thanks for reading,
Anita.

Installing Devstack With Vagrant

Devstack - The OpenStack Development Environment

Who should install Devstack?

Those who wish to contribute to OpenStack code.

Those wishing to install OpenStack for production should install OpenStack from distribution packages or a tarball. Devstack is not recommended for production.

What is Devstack?

Devstack is a repository of code which will install and start an OpenStack developement and testing environment.

Where can I find the Devstack code?

Read up on the Devstack project and browse the code.

Why should I install Devstack?

Devstack is the environment used to run the tests on all new OpenStack code patches. New code has to pass these tests before they are merged to trunk. Using Devstack as a development environment helps contributors understand the entire life cycye of OpenStack code.

How do I install Devstack?

What do I need?

You need an isolated environment to install Devstack - a vm, a container or a separate hard drive - an environment that can be set up, taken down, over written and reinstalled without affecting the rest of your development environment.

In this post, I will give instructions for installing Devstack using vagrant - but you can install Devstack anywhere you want. I highly recommend you select an environment isolated from your local development environment - but the choice is yours.

  • install virtualbox (4.2.12 or 4.2.16 but not 4.2.14)
  • install vagrant (I used the debs for both virtualbox and vagrant)

I am using virtualbox 4.2.16 and vagrant 1.2.7 for this post.

  • mkdir devstack_vagrant
  • cd devstack_vagrant
  • vagrant box add precise32 http://files.vagrantup.com/precise32.box
  • vagrant init precise32

These commands will download a 32bit image of ubuntu precise from http://files.vagrantup.com. If you have the ability to use a 64bit image for virtualization (you may need to toggle your bios settings on a 64bit machine), you can replace the reference to 32 above with 64. So, vagrant box add precise64 http://files.vagrantup.com/precise64.box followed by vagrant init precise64.

We are using ubuntu precise on purpose since the majority of our testing for OpenStack code uses Devstack on an ubuntu precise server. You can use whatever server image you want, but if Devstack doesn’t install properly on it, I will suggest you try ubuntu precise.

  • open the Vagrantfile created by the vagrant init command in an editor, for example vi Vagrantfile
  • increase the amount of RAM allocated to the vm by editing the following lines to match the code below:
Vagrantfile
1
2
3
4
5
6
7
config.vm.provider :virtualbox do |vb|
#   # Don't boot with headless mode
#   vb.gui = true
#
#   # Use VBoxManage to customize the VM. For example to change memory:
  vb.customize ["modifyvm", :id, "--memory", "2048"]
end
  • save and close the file

Devstack requires at least 1.2G of RAM to run. Use the most you can afford with your setup. the code above allocates 2G of RAM to this vagrant vm.

  • vagrant up && vagrant ssh

This brings up the vm and opens a shell into the server image.

Since I use this set of instructions myself to create vms for development, the next command I usually run is:

  • ssh-keygen -t <rsa|dsa> posting the public key to my gerrit account, enabling me to submit patches to gerrit from the vm

Then I update apt-get and install dependencies then git clone devstack and cd inside:

sudo apt-get update && sudo apt-get -y install git vim-gtk libxml2-dev libxslt1-dev libpq-dev python-pip libsqlite3-dev && sudo apt-get -y build-dep python-mysqldb && sudo pip install git-review tox && git clone git://git.openstack.org/openstack-dev/devstack && cd devstack

I set my username, email and editor choice in git with:

  • git config --user.name "<user name>"
  • git config --user.email "<gerrit email>"
  • git config --user.editor "<editor>"

I am in the devstack root directory so I can run:

  • mv samples/localrc .

to get a copy of localrc in the root directory.

Then I run:

  • ./stack.sh

to have devstack download all the OpenStack development repositories and start the services.

You will have to be connected to the internet, at least the first time you run devstack, in order for all the repositories and their dependencies to be installed. Devstack will take a fair amount of time to install, your time will depend on your internect connection and the amount of RAM you have allocated to your vm.

After devstack has finished installing, source the openrc file to enable credentials:

  • source ~devstack/openrc

If you need to be the admin user, source the file with the admin argument:

  • source ~devstack/openrc admin

To stop devstack, run ./unstack.sh inside the devstack root directory.

To exit the vagrant vm, type exit. This closes the ssh shell to the vm and puts you back in your host session.

To stop the vagrant vm, type vagrant suspend or vagrant halt.

To remove the vagrant vm, type vagrant destroy. Don’t just remove the vagrant directory with rm -rf <vagrant directory>, you need to reclaim the memory allocated for the vm.

To restart a vagrant vm, type vagrant up.


If you want to use vagrant’s shell provisioning you can copy this for your Vagrantfile:

Vagrantfile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "precise64"
  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "2048"]
  end
  config.vm.provision :shell do |shell|
    shell.inline = "apt-get update && apt-get -y install git vim-gtk libxml2-dev libxslt1-dev libpq-dev python-pip libsqlite3-dev && apt-get -y build-dep python-mysqldb && pip install git-review tox && git clone git://git.openstack.org/openstack-dev/devstack && chown -R vagrant:vagrant devstack"
  end
end

If you choose to use the above Vagrantfile, use the following commands:

  • vagrant up This will take a while to run, since this updates apt-get, installs the dependancies and then clones devstack
  • vagrant ssh

Subsequent commands to start the vm will have to specify not provisioning the vm:

  • vagrant up --no-provision

If you brought down the vagrant vm with vagrant suspend, you can bring it up again with vagrant resume, rather than using vagrant up --no-provision.


There is much to learn about using devstack, but this concludes the installation.

Thanks for reading,
Anita Kuno.

Suggestions for GNOME OPW Applicants

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

Please Rebase Your Change and Upload a New Patchset

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.

Reviewing an OpenStack Patch

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.

Internship Is 2/3 Complete - How Am I Doing?

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.

OpenStack Updated Individual Contributor License Agreements

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.

Fatal: CLA (Echosign) Contributor Agreement Is Expired

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.

The Structure and Habits of Git

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.

OpenStack Release Cycle - N00b’s Eyeview

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.