Tag: Projects


Call for Proposals Open Source @ OpenStack Summit

March 31st, 2014 — 6:25am

UPDATE: Friday, April 18 is the deadline for submissions. 

At this year’s OpenStack Summit we’re going to be offering space to Open Source projects that are important to the OpenStack community. We’re calling it Open Source @ OpenStack, and it’s an opportunity for these projects to hold small design summits with their community members. We’re impressed by the number of projects that have grown in the OpenStack ecosystem, and want to continue the practice we started with StackForge of fostering these projects.

We have space and time available for half day sessions on Tuesday and Wednesday, both morning and afternoon. The purpose of the space is to get developers in the same room so they can plan their development for the Juno release cycle. Rather than being a time to market a particular company or technology, it should be an opportunity communication and goal setting. To achieve these goals, we would like participating projects to use the following guidelines:

  • The project needs to be directly related to OpenStack in some way.
  • The project must be open source, with source code available and actively developed.
  • The work needs to be non-commercial and vendor neutral, although a vendor that sponsors a project can organize the meeting.
  • Sessions must be open to anyone who wants to attend. This should be not just an opportunity for core developers to meet, but to also give a venue for people interested in your project to get more information.
  • Meeting notes from the design session should be made publicly available.
  • The group organizers and participants must adhere to the OpenStack Summit Code of Conduct.

If you have a project that you think qualifies for this space, we invite you to submit a proposal for Open Source @ OpenStack. Update: Friday, April 18 is the deadline for submissions. 

Please include:

  • The name of your project.
  • A description of the project and how it relates to OpenStack.
  • The names and contact information for the organizers commiting to hosting the session.
  • Relevant links to project sites such as repositories, bug trackers, and documentation.
  • An estimate of the number of developers you expect to attend your design meeting.
  • A plan for how you intend to use the time and space.

We want to thank everyone for the time and effort they put into supporting OpenStack.

Comment » | Communication, community, Development, Event

10 Steps to Initiating an OpenStack Cloud Service

February 28th, 2011 — 3:48pm

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

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. 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’d like to talk about the process I’m taking with a new message queue service.

Step 1 – Idea

The first step is to figure out what is missing. What new service would compliment the software already available? What hasn’t 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.

Step 2 – Initial requirements

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

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’re re-inventing the wheel, take their concerns into consideration, but also realize you may not be. You may be writing a jet engine.

Step 3 – Wiki and Mailing List Proposal

Once you have a good idea and a rough outline, you’ll probably want to run it by a couple people for feedback before sending it to everyone. You’ll then want to create a new wiki page on the OpenStack wiki and send a note to the public mailing list that mentions the wiki page and asks for community feedback. For example, the queue service proposal I wrote can be found here. 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’s 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.

Step 4 – Wait

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, …) and help facilitate the conversation as people respond.

Step 5 – Prototype

Once you feel the community is content with the proposal and it’s a viable idea (don’t 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’t need to be anything fancy, for the queue service I put this together over a weekend.

Step 6 – Name and Language

Now comes the difficult part, choosing a project name. I’d suggest not using the mailing list for this as it will be a lot of noise for a matter that isn’t too important. Ask a couple folks who may also be interested for ideas and make sure it’s not already taken (search on github, Launchpad, Google, etc). For the queue service we decided on “Burrow”.

You’ll 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.

Step 7 – Bootstrap the Project on Launchpad

We’re using Launchpad for OpenStack project management. You’ll need to create a project and a number of groups to manage it. For example, the queue project can be found here. The groups have the following roles (replace burrow with your project name):

  • burrow – Public group that anyone can join. This currently includes members on the main OpenStack mailing list, but we’re setup this way in case we need to break projects out into their own list.
  • burrow-drivers – The group responsible for maintaining the project, managing blueprints, and making releases.
  • burrow-core – The group responsible for performing code reviews.
  • burrow-bugs – The group responsible for managing bugs.

Step 8 – Lock onto Releases and Milestone Schedule

While not important right away, it might be a good idea to start working with the OpenStack release cycle. Releases are currently every three months with milestones setup in each release for feature freeze, bug freeze, and releases. See the release page for more details. Launchpad makes it fairly simple to manage this, you’ll just want to create a new series (for example, “cactus” right now), and a couple milestones within that series for the freezing and release. Ask on the mailing list or on IRC if you need any help, but a good rule of thumb is to follow what other established projects do (like Nova).

Step 9 – Code!

Get to work and try to recruit other developers to help you. Keep the community updated with progress by using IRC, mailing list, planet.openstack.org, and tweets.

Step 10 – Submit to the Project Oversight Committee

Up until this point your project has not been an official OpenStack project. It is a well thought-out idea driven by the community that probably has a good chance though. You’ll need to make a proposal to the POC using this page once the project can stand on it’s own. You probably don’t need a final version, but you need something that is functional and more robust than a prototype. The POC meets weekly, although it may take more time (and some conversations) to decide if your project is ready. The queue service I’ve been driving has not been proposed since it’s not ready, so you may want to take all this with a grain of salt. It is my hope to have the first version ready to propose in April as part of the Cactus release.

Final Thoughts

This process will vary and can certainly be refined. I’m stating what I’ve done with a new project, but existing projects will obviously need to take a different route. The main idea to keep in mind though is that any OpenStack project should be seen as community driven, not just by an individual or company. One or more individuals may carry out a large part of the work of the community initially, but community concerns and feedback should always be taken with the utmost importance.

Comment » | Communication, Development, Tools

Back to top