Start Contributing to OpenStack - The Easy Way #docker

One of the most daunting and complicated things people find when trying to provide feedback and suggestions to the OpenStack community, projects and code – is the nuts and bolts of actually getting this done.

There are a number of tutorials around. The official kind - HowTo for FirstTimers, Documentation HowTo, Gerrit Workflow.

Scott Lowe also posted a good tutorial on Setting up the Tools for Contributing to OpenStack Documentation. But the process itself is still clunky, complicated and for someone who has never used git or gerrit before – highly intimidating.

That is why I embarked on providing a really simple way of starting to contribute to the OpenStack code. I was planning on writing a step-by-step on how exactly this should be done – but Scott’s post was more than enough – so need to repeat what has already been said.

Despite that there are still some missing pieces in there which I would like to fill in here in this post.

Before we get started there are a few requirements/bits of information that you must have, and some things that you need to do before hand - in order for this process to work.

They are as follows:

  1. A launchpad account
  2. An Openstack Foundation account. (Use the same email address for both step 1 and step 2).
  3. A signed Contributor License Agreement (CLA).
  4. A gerrit http password.
  5. Somewhere to run Docker (I wrote a post about this - The Quickest Way to Get Started with Docker)

Let me walk you through each of the steps.

1. A Launchpad Account

Sign up for a launchpad account – http://www.launchpad.net


Register for a new account – you will need to provide some information of course

Create account

You will need to of course verify your email address. Go to your inbox and click on that link in the email you have received and validate your address


2. Join the OpenStack Foundation

Sign up for an Openstack Foundation account – https://www.openstack.org/join

Join OpenStack

And fill in the details



*Remember* – use the same email address you used to sign up for the launchpad account.

3. Sign the CLA

Go to https://review.openstack.org/ and sign in with your Launchpad ID (from Step 1)


If you have not logged out of the Launchpad – you should be presented with a screen like the one below.


Some of the information will already be populated for you. You will need to choose a unique username.


We will not choose an SSH key at the moment. Scroll to the bottom of the screen and choose New Contributor Agreement.


You should choose the ICLA


Review the agreement and understand what you are signing and then fill in the details below.


If everything is Kosher then you will be presented with the following screen to confirm


4. A gerrit http password

Remember the username you chose from the previous step? this is the one you should use.

http password

On that same Settings screen, choose HTTP password and enter your username and Generate Password.

http password2

http password3

Don’t worry – the password has already been changed – the minute I published this post.

And we have finished all the registration and administrative things.

Just to recap – you will need these details for later (you need to replace them with your relevant details instead)

  1. Your Name – Maish Saidel-Keesing
  2. Email Address – maishsk@XXXX.com
  3. Gerrit Username – maish_sk
  4. HTTP Password - zwZW0X5NAGVP

Running the Container

Now that we have all the parts – it is really simple to get started.

The steps are as follows:

docker pull maishsk/openstack-git-env

This will retrieve the container from the Docker Hub. Once the container has been retrieved you can launch the container.

A few points to note beforehand.

  1. The container will always start a bash shell. The aim of this environment is to allow you to contribute to the OpenStack Project – so it has to be interactive.
  2. You have to provide 4 variable to the run command – it has to be all four – otherwise the container will not launch.
  3. The container will automatically upload an SSH key to gerrit – to allow you to connect and contribute your code upstream. It does not remove the SSH keys when done – this you will have to do manually.

The command to launch the container would is as follows – and remember you need to take the values from above.

docker run --name="git-container" \-e GIT_USERNAME="\"Maish Saidel-Keesing\"" \
-e GIT_EMAIL="maishsk@XXXX.com" -e GERRIT_USERNAME=maish_sk \
-t maishsk/openstack-git-env

A few words about the variables

--name="git-container" – this is just to identify the launched container easily
-e GIT_USERNAME="\"Maish Saidel-Keesing\"" – the quotes have to be escaped \"
-e GIT_EMAIL=maishsk@XXXX.com
Don’t forget to put in your real email address!

Once the container is launched – provided you have followed all the steps correctly and the variables are also correct - you will see some output printed to the screen with the SSH key that was just created and you will also be able to see that key in the gerrit web interface as well.

run container

ssh key

You can see that the comment on the web is the same as the hostname of the container.

Embedded below is a screencast of the launching of the container.

In the next post – I will show you how to actually contribute some code.

If you have any feedback, comments or questions, please feel free to leave them below.


Automating Blog Retweets

I love IFTTT – it is a simple way to automate things.

If This Then That. If something happens – then do something else. I am already using a number of IFTTT recipes to help me in automating my daily life.

I do not use Wordpress – Blogger suits my needs very well, It has its upsides and downsides.

When I publish a blog post – I like to update my social networks with the announcement. At the moment this is manual process. And I had enough.

I went to my friend IFTTT to help me out.

A new recipe that finds a new tweet by me.


and then push it to buffer


Two major issues here. One I only want to push certain tweets – not everything.

That could be solved by changing the trigger to a tweet by me with a hashtag


But my biggest problem was that I have not control of when the tweet should be scheduled something which I can do with the buffer interface as you can see below.

buffer schedule

Zapier to the rescue.

The basic account is free for 5 zaps (recipes in IFTTT language) and 100 tasks per month.

My first tweet is always done manually after I publish the post. The format is always as follows:

New Blog Post | <Blog_post_title> – <URL>

So the logic behind my automation was as follows

process flow

It will look for a text – and also check if this is already a retweet of my previous post – otherwise I will get an endless loop. Then schedule it for a specific time.

Zapier does not enable me to do multiple actions – which is OK – so I created another 2 zaps for the additional times I wanted to schedule the tweets.

This is what the zap looks like

step 1

step 2

step 3

step 4

step 5

Hope this is useful.

Just a small note as to why I re-tweet multiple times. because of time zone differences and exposure – that is all.


Presenting - the Ignite way

Today I gave a presentation – actually two – but they were very different.

How many of you have heard about Ignite?

Ignite is the name for a particular type of event that is held throughout the world—organized by volunteers—at which participants speak about their ideas and personal or professional passions according to a specific format. The event holds the motto, “Enlighten us, but make it quick!” Anyone can throw an Ignite event. The presentations are meant to "ignite" the audience on a subject, whereby awareness, thought, and action are generated on the subjects presented.

Ignite is a presentation format that is shorter than the Pecha Kucha format, a presentation style in which 20 slides are shown for 20 seconds each, but longer than lightning talks, which are short presentations from five to 10 minutes in length. At an Ignite event, each speaker has a time limit of five minutes, and must use 20 slides with each slide advancing automatically after 15 seconds. This forces speakers to maintain a rapid pace. At a just-comprehensible clip of 160 words a minute, Ignite speakers can utter about 40 words per slide, making a total of 800 words for the complete talk.

Personally, I think this is one of the hardest methodologies to present.

You only have 15 seconds per slide – that means you need to get your point across in a very short time. Precise, and concise. The clock waits for no man

Visual slides are advised, it helps you get your point across. And bullet points should be kept to a minimum.

I thoroughly enjoyed doing this presentation. It took only five minutes – but preparation on the ideas, the delivery and content took over 2 hours.

A great challenge and something that I would totally do again.

Embedded below is the presentation (specifically in PPT format – since all the animations and timing are built into the presentation).



Devs are from Mars, Ops are from Venus

I will be delivering a talk at the upcoming DevOpsDays Tel Aviv which will be on this coming Sunday and Monday.

devopdays banner

DevOps is one of my personal interests, especially educating of the other side of the table, the developers, as I do not see myself as one but rather an Operations kind of guy.

I will also be delivering an Ignite session about Using Social Media As a Tool in Your Daily Work.

I will be presenting with John Willis, Michael Ducy, Aviran Mordo, Sagy Rozman, Nir Cohen, Orit Yaron, Dror Bereznitsky, Eyal Edri and Oded Ramraz.

The full schedule is here.

Devs are from Mars

If you cannot join in person - the event is being streamed live and of course the presentations and recordings will be available after event as well.

Hope to see you next week – it will sure be interesting.

Live stream is embedded below


How Operators Can Get Involved in Kilo #OpenStackSummit

I participated on Monday in the Ops Summit: How to get involved in Kilo, and as these sessions are not recorded I wanted to convey the messages that were conveyed at the session.


But first, the Ops Summit is a mini 2-day set of sessions that were introduced at the previous summit to get the feedback of the people actually using OpenStack and their problems and issues that they are encountering. A great and formidable initiative on the part of the Foundation – still it is one that I think should be done before you start developing code, but that is only my humble opinion.

There were a lot of the PTL’s and TC members there, showing that they are serious and listening to the community – not the developer community, but rather the Operators.

I raised the following question in the session.

Being an operator – a guy that uses, deploys, manages, troubleshoots and supports OpenStack. I do not have developer experience, I do not have a team of developers at my disposal.

How would you (“Openstack”) want us to contribute?

The feedback was that they would like hear the problems we are having, submit the user stories, the issues, the pain points back to the developer community. This can be done by submitting bugs, by asking the questions on http://ask.openstack.org/ or on the IRC channels.

Tell your stories, publish what you have achieved, and even post the problem that you encountered, and answer your own question if you solved it. The http://ask.openstack.org/ receives a lot of Google traffic so it makes things easier for others to find.

Another item that was raised was that the TC would like to see more Operator feedback on the specs that are being added for each cycle. There is a new portal where all the proposed blueprints are being published – in a nice and collated fashion.


They are organized per project and will point you to blueprint in question. They ask that you leave your feedback. I actually find this to be misleading. Where do I leave feedback? On that page? On the blueprint? On the Gerrit discussion?

There was some feedback towards the PTL’s and the TC from the audience regarding the fact when people do submit blueprints and bug fixes (especially newbies) the probability of receiving negative reviews (-1’s) on the submission – for what ever reason - is very high. Something that perhaps could be addressed and make the process more “welcoming”.

The one thing that I found was missing – and again it is a recurring theme here that I am coming across, throughout the summit. And I think that this is a major flaw in the way these things are being done at the moment.

No-one said – give us feedback as to what you are interested in getting into OpenStack,
before we actually start writing the code.

Not after the code has been written.

This does not mean that it will be implemented – but at least you are developing for a use case. An actual use case.

Will someone use what is being written? Is the code actually going to be useable? If not what is missing to make it an adopted feature?

More on this in following posts.


Putting Some Ops in the Dev - OpenStack Summit

I am currently writing this post from the plane on the way to the summit in Paris. For those of you who are living under a rock, or were completely unaware, this is the biannual "pilgrimage" of all thing OpenStack. This coincides with the Juno release that was went GA less than 3 weeks ago.

openstack_summitThis is only my second summit, I have but I am really looking forward to bumping into some familiar faces, and making new acquaintances.

It is not the first time I have said this, but I think that OpenStack is at a crucial impasse, at a time where some hard decisions have to be made, before it reaches a point of no return.

A new Technical Committee was elected recently, and already there are rumblings as to what should be the criteria for those who can voter, why is the the participation so low and is this a trend that we were going to have to get used to. To all those above, I do not have a clear answer, although I would like to add one thought.

The technical committee is elected by the ATC's (Active Technical Contributors). That is the way it should be, those who are actively putting in their time, their code into the projects, should be the one's who decide who they want as their representative. I think this was the first time where all candidates were presented with a set of questions which tried to show their point of view of how things should be going forward.

Personally, I have met one or two of them, with others exchanged an email or two, an IRC chat or two, and others I know of them just from what I read on the mailing lists.

I think there is one very important thing that is missing, and hopefully, something that will change going forward. All of the candidates, they come from the technical contribution side. They know their stuff, they know the community, but I am not sure I can say that they have large deployment experience, they have not experienced 1st hand, in the flesh, the problems, the challenges, the frustrations that those who are deploying OpenStack in the field have.

The biggest problem here is that the number of Operator's (this is what is the acceptable term is in the OpenStack community) that actually contribute code into OpenStack is minimal or close to zero.

There are numerous reasons for that, and some might say that this is not the way it should be, but I am skeptical if and when this will change. Until that happens there will never be an 'operator' perspective, or an 'Operational way of thinking' as part of the technical committee.

And again, some might this is the way it should be.

I do not. I think that is in the best interest of the foundation and of the OpenStack community as a whole to have someone with that background, with that frame of mind as part of the committee that is leading us all.

Unfortunately, this is what I see as a classical disconnect between development and operations, the antithesis of DevOps, where they should work as one, and not have the Operations people and the 'Enterprise' join in as an afterthought. That unfortunately is the case as it is today.

I hope that I can get this point through to as many people as possible at the summit.

Please feel free to come and sit down and chat with me, I would always be interested in hearing your thoughts and ideas. I am pretty easy to recognize, I gather there will not be many people at the summit with a kippah.

Of course you can always leave your thoughts and comments below as well.