{"id":554,"date":"2011-02-28T15:48:46","date_gmt":"2011-02-28T21:48:46","guid":{"rendered":"http:\/\/www.openstack.org\/blog\/?p=554"},"modified":"2011-02-28T15:48:46","modified_gmt":"2011-02-28T21:48:46","slug":"10-steps-to-initiating-an-openstack-cloud-service","status":"publish","type":"post","link":"https:\/\/www.openstack.org\/blog\/10-steps-to-initiating-an-openstack-cloud-service\/","title":{"rendered":"10 Steps to Initiating an OpenStack Cloud Service"},"content":{"rendered":"

This blog post originates from Eric Day at http:\/\/oddments.org\/?p=591<\/a>. I have copied it here for your reference:<\/p>\n

OpenStack currently consists of three main components: Nova (Compute), Swift (Object Storage), and Glance (Image Service). There are some other projects such as a dashboard and mobile apps as well. You can see the full list here<\/a>. This is great start, but in order for OpenStack to compete long term other infrastructure and platform services will need to be brought in. I\u2019d like to talk about the process I\u2019m taking with a new message queue service.<\/p>\n

Step 1 \u2013 Idea<\/strong><\/p>\n

The first step is to figure out what is missing. What new service would compliment the software already available? What hasn\u2019t been solved yet? What are users asking for? A message queue seemed like an appropriate next step as most applications that need to scale out and be highly available will make use of a queue at some point (sometimes not in the most obvious form). It will also allow other cloud services to be built on top of it. In fact, the current OpenStack projects could even leverage a queue service for new features.<\/p>\n

Step 2 \u2013 Initial requirements<\/strong><\/p>\n

Before you write up a proposal and send it out, it might be a good idea to gather some initial requirements and figure out what it may look like. Don\u2019t worry about details as the community will help flush this out later. Some of the major requirements when thinking about OpenStack projects are horizontal scalability, multi-tenancy, modular API, REST API, zones and locality awareness, and no single points of failure (high availability). This is a pretty heavy set of requirements before even getting into service specifics, but this will help you think about how to approach a service. You may have to diverge away from traditional thinking for a particular service. For example, what worked in a rack or a data center may not work in the cloud. You need to account for this up front and state behavioral differences from what folks may expect. For the queue service, this meant not taking a traditional approach you see in some queue protocols and services, and instead integrating ideas from distributed services.<\/p>\n

A multi-tenant cloud is a very different environment from what many people are used to and usually requires a different approach to solve problems. If folks tell you you\u2019re re-inventing the wheel, take their concerns into consideration, but also realize you may not be. You may be writing a jet engine.<\/p>\n

Step 3 \u2013 Wiki and Mailing List Proposal<\/strong><\/p>\n

Once you have a good idea and a rough outline, you\u2019ll probably want to run it by a couple people for feedback before sending it to everyone. You\u2019ll then want to create a new wiki page on the OpenStack wiki<\/a> and send a note to the public mailing list<\/a> that mentions the wiki page and asks for community feedback. For example, the queue service proposal I wrote can be found here<\/a>. There is an enormous amount of collective experience and brain power on the mailing list which will help point out any issues with the proposal. The service you initially propose may look nothing like the service you actually build. It\u2019s also quite possible the service you propose is not a good fit for the cloud or OpenStack. The community will help iron all these details out.<\/p>\n

Step 4 \u2013 Wait<\/strong><\/p>\n

It can take folks a while to catch up on public mailing lists, so be patient. Let people know about the proposal by other means (blog, tweet, irc, \u2026) and help facilitate the conversation as people respond.<\/p>\n

Step 5 \u2013 Prototype<\/strong><\/p>\n

Once you feel the community is content with the proposal and it\u2019s a viable idea (don\u2019t expect consensus), prototype it! This shows the community you are serious and this exercise will help work out more issues in the proposal. Let the community know about it and again wait for any feedback. This doesn\u2019t need to be anything fancy, for the queue service I put this together<\/a> over a weekend.<\/p>\n

Step 6 \u2013 Name and Language<\/strong><\/p>\n

Now comes the difficult part, choosing a project name. I\u2019d suggest not using the mailing list for this as it will be a lot of noise for a matter that isn\u2019t too important. Ask a couple folks who may also be interested for ideas and make sure it\u2019s not already taken (search on github, Launchpad, Google, etc). For the queue service we decided on \u201cBurrow\u201d.<\/p>\n

You\u2019ll also need to figure out the most appropriate language. For middleware and services, Python is a good default. If efficiency is a concern, look at Erlang or C\/C++. Be sure to send another mail to the list and ask for feedback. With the queue service I initially proposed C++ with Erlang as an alternative since efficiency is a major concern (especially around utilizing multiple cores), and the community came back mixed but with more enthusiasm for Erlang.<\/p>\n

Step 7 \u2013 Bootstrap the Project on Launchpad<\/strong><\/p>\n

We\u2019re using Launchpad for OpenStack project management. You\u2019ll need to create a project and a number of groups to manage it. For example, the queue project can be found here<\/a>. The groups have the following roles (replace burrow with your project name):<\/p>\n