Loading…

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Ecosystem [clear filter]
Monday, April 16
 

9:30am

OpenVZ Linux Containers
The talk is about operating system virtualization technology known as OpenVZ. This is an effective way of partitioning a Linux machine into multiple isolated Linux containers. All containers are running on top of one single Linux kernel, which results in excellent density, performance and manageability. The talk gives an overall description of OpenVZ building blocks, such as namespaces, cgroups and various resource controllers. A few features, notably live migration and virtual swap, are described in greater details. Results of some performance measurements against VMware, Xen and KVM are given. Finally, we will provide a status update on merging bits and pieces of OpenVZ kernel to upstream Linux kernel, and share our plans for the future. (Session lead is Kir Kolyshkin)

Monday April 16, 2012 9:30am - 10:25am
Bayview B

11:00am

Ryu Network Operating System
Ryu is an open-sourced Network Operating System (NOS) licensed under Apache License v2. The project URL is http://www.osrg.net/ryu/ . Ryu aims to provide a logically centralized control and well defined API that make it easy for operators to create new network management and control applications. Currently, Ryu supports OpenFlow protocol to modify the behavior of network devices. Ryu plugin for OpenStack was merged into Quantum (virtual network service) Essex. You can create tens of thousands of isolated virtual networks without using VLAN. The project goal is to develop an OSS Network Operating System that has high quality enough for use in large production environment in code quality/functionality/usability, and to become the standard network management component of OpenStack. In this talk, we will explain the overall design and future plans of Ryu, and give some demonstrations. (Session lead is Kazutaka Morita)

Monday April 16, 2012 11:00am - 11:25am
Bayview B

11:30am

Dough: OpenStack Billing Project
Presentation of a billing project for OpenStack projects. github.com/lzyeval/dough The items that we plan to charge our customers are instance usage, floating ip usage, Swift storage usage and throughput, and external network output. We have devised a billing system where the admin can register products of their cloud and periodically charge the user. Properties of a Product are region, item, item_type, payment_type, measure_unit, and price etc. Admin can register its own regions, items(instance, ips, network-io, storage-io), item_types(m1.tiny, m1.large), payment_types(hourly, daily, monthly), and map these four properties to a price and measure_unit. For example, when a user creates a instance from Horizon, a client code informs the billing API server and the billing system subscribes a instance product to the tenant_id. Based on the payment_type the user chose, the billing system will periodically check the status of the product and charge the tenant_id for its use. When the user terminates the instance, Horizon will send a unsubscribe request to the API server and stop charging the tenant from that point on. The billing system consists of three components. 1) API Server, which receives subscribe/unsubscribe and usage query requests. 2) Farmer, which periodically checks all subscriptions and requests billing to the collector. 3) Collector, gets work from the farmer and uses python-novaclient, kanyun-client, swift-client to retrieve usage information of a product the tenant has subscribed and charges money to the accordingly. The database used is MySQL and all communication between components uses ZeroMQ. Currently in testing and all source code is on Github. (Session lead is luozhongyue)

Monday April 16, 2012 11:30am - 11:55am
Bayview B

12:00pm

Atlas-LB and Yahoo's loadbalancer config system
Currently Atlas-LB has adapters for certain kinds of s/w and h/w Load balancers like Zeus and Netscalar. The adapters however, directly configure the LBs. If Atlas LB has to work with more complex data center topologies and complex business rules of different organizations, which have their own workflows for provisioning Load balancers, then it needs to be able to talk to the external workflow provisioning systems. This way, it is easy to design interoperability between Atlas, and other workflow systems. This proposal adds the capability for Atlas-LB to support a workflow load balancer provisioning system at the backend to which it could delegate LB management requests. It accomplishes this by having a new message listener which invokes an asynchronous workflow adapter in Atlas-LB which acts as a proxy to a workflow system. The current listener invokes the adapter synchronously and marks the loadbalancer/Vip as Active or in Error depending on whether the adapter returns successfully or not. For a workflow based system, since the adapter can not complete its task in a short/known amount of time (due to manual steps in the workflow), the adapter has to be asynchronous and the listener should not mark the loadbalancer/Vip as active even if the workflow adapter returns successfully. The successful return of the adapter is taken to mean only the successful creation of a request in the workflow system. (Session lead is Kiran Lonikar)

Monday April 16, 2012 12:00pm - 12:25pm
Bayview B

2:00pm

The Resurrection of Burrow Simple Queue
Once upon a time, we had a little project that was almost incubated. It was going to provide OpenStack with a common, RESTful API for driving simple queues. Unfortunately, it was abandoned and withered on the vine. Recently, with the growing enthusiasm for OpenStack by current AWS users, I've found renewed interest in a simple OpenStack queue project. There has also been interest on the mailing lists for a common RPC mechanism. So I'm bringing burrow back from the dead. At the time of submission, it supports a significant subset Amazon Simple Query Service API and a single simple sqlite3 backend. Development is ongoing, so I expect a both a simple OpenStack REST API, and a direct API that can be used as a nova-rpc backend by the summit. Also, since I don't want to write a queue service, Burrow backs to real queue servers and a RabbitMQ backend should be done by then. (Session lead is ChristopherMacGown)

Monday April 16, 2012 2:00pm - 2:25pm
Bayview B

2:30pm

PyPI, Client Libraries, and CLP
Replacing "Installing OpenStack CI", we'll be brainstorming around our client lib releases and intereaction with PyPI. (Session lead is Monty Taylor)

Monday April 16, 2012 2:30pm - 3:25pm
Bayview B

3:30pm

Common Testing Interface
Over the last cycle we arrived on a common testing interface which jenkins uses to run the various tests on a given repo tree - but it was emergent rather than pre-planned. We should sit down, go through the requirements, make sure we like them, and see what we might want to add. Additionally, planning ahead for what a similar interface might look like for non-python projects (should they arise) would be a nice way to be prepared. (Session lead is Monty Taylor)

Monday April 16, 2012 3:30pm - 3:55pm
Bayview B

4:30pm

Jenkins jclouds plugin
We've been working on the development of a plugin for jenkins that lets us automatically provision build and test nodes as needed - which allows us to take advantage of all of the clouds we have for both speed and resiliency in our build farm. Most of how that's happening is self-contained in the CI team - so letting people know how that's happening and how they can take advantage of it I thought would be helpful. (Session lead is Monty Taylor)

Monday April 16, 2012 4:30pm - 4:55pm
Bayview B

5:00pm

Openstack Notifications System and Yagi.
A brief overview of the Notifications system used by Nova, Glance and other Openstack projects, plus some more in-depth detail on integrating external systems, such as billing and monitoring systems, with Openstack using the Yagi feed-radiator application (https://github.com/Cerberus98/yagi/) to publish notifications in Atom format thru AtomPub or PubSubHubub protocols. (Session lead is Monsyne Dragon)

Monday April 16, 2012 5:00pm - 5:55pm
Bayview B
 
Tuesday, April 17
 

9:00am

Chef and OpenStack
Chef is a configuration management and service automation tool frequently used in the OpenStack community. There have been a number of threads on the mailing list around its usage and the various implementations. It would be nice to get an overview of the landscape and help people coordinate efforts where possible. I will give a brief introductory presentation of the existing Chef cookbooks I'm aware of and the use of knife-openstack with Nova. After that we'll open it up for discussion. (Session lead is mattray)

Tuesday April 17, 2012 9:00am - 9:55am
Bayview B

10:00am

Service relationships
A volume service may be associated with an explicit compute service. There is no way to explicitly indicate this relationship via the service catalog today. Type and names can be duplicated according to the contract and expanding a URL type for a relationship seems like over-kill. There needs to be a collection or grouping of services to indicate which ones play well with each other. (Session lead is Joe Savak)

Tuesday April 17, 2012 10:00am - 10:25am
Bayview B

11:00am

Performance Evaluation for OpenStack
OpenStack has been more popular than ever and more vendors in China today are trying build their own products/solutions based on OpenStack. To achieve product-level quality for Folsom, performance, scalability and power efficiency should be as important as feature readiness and robustness. We'd like to share some of our proof-of-concept performance work on Nova - and we really looking forward to discussion on general approach on how to evaluate and improve OpenStack solution performance (e.g. workload, benchmark methodology, related optimization effort etc) and maybe start some projects work on it. (Session lead is Huang Zhiteng)

Tuesday April 17, 2012 11:00am - 11:55am
Bayview B

12:00pm

Fog and OpenStack Developer Meetup
Fog is the Ruby cloud services library (http://fog.io/) which provides integration with a number of cloud providers, including OpenStack. There are/have been a number of duplicated efforts working with Fog. I propose a developer session to help coordinate future efforts and put names with faces. (Session lead is mattray)

Tuesday April 17, 2012 12:00pm - 12:25pm
Bayview B

2:00pm

Communication - IRC, mailing lists, blogs, forums
Review of our community communication media. Does the current situation with IRC and mailing lists (2+ IRC channels, one mailing-list) work well? Should we split into more IRC channels and/or mailing lists? Enforce prefixes on the ML? Should we *split the single ML into developers topics vs. users topics? What should we do with the forums? Should we move to a Q&A site or stay with Launchpad Answers? Those are some of the possible topics, though we can use our session time for any related topic that the session participants are most interested in. (Session lead is Thierry Carrez)

Tuesday April 17, 2012 2:00pm - 2:25pm
Bayview B

2:30pm

DEVSTACKpy and what it can do for u!
Come learn DEVSTACKpy! The completely Python developer OpenStack deployment and development environment. Run through description of: 1. Its features 2. Its enhancements over devstack.sh 3. How it can be easily used and configured 4. Documentation and code examples Brainstorm the following: 1. Future improvements a. Multi-node dev. installs? b. Rollbacks and more transactional like installs? c. How to keep the different package versions in sync? 2. Any other feedback/questions Demo the following: 1. Simultaneous OpenStack install on Ubuntu 11.10, RHEL 6, Fedora 16 a. Followed by a starting of the base OpenStack components and then an uninstall (on all 3 distros) We can go through the following as well: https://launchpad.net/~devstackpy (our small dev. group) https://github.com/yahoo/Openstack-DevstackPy (if anyone wants to see the code) http://readthedocs.org/docs/devstackpy/ (docs for those interested) (Session lead is Joshua Harlow)

Tuesday April 17, 2012 2:30pm - 3:25pm
Bayview B

3:30pm

Bug handling improvements
We use Launchpad to handle OpenStack bugs. This session will discuss further improvements and changes in the way we use various status / importance / tags, see what we can do to encourage more people to participate into triaging filed bugs. We'll also discuss the fate of abandoned "Wishlist" items that clog some of the bug lists, and how much those should just be turned into blueprints or items on a wiki page. (Session lead is Thierry Carrez)

Tuesday April 17, 2012 3:30pm - 3:55pm
Bayview B

4:30pm

API extensions: the good, the bad, and the ugly
API extensions are a standard way to extend the functionality of APIs and expose them to users. However, some of the OpenStack API extension mechanisms are perceived as clunky and error-prone. I'd like to use this session to brainstorm ways of creating and supporting an extension mechanism that would be simpler and easier to use; if our proposal is good enough, we can implement it as part of Glance's v2 API (per the Glance PTL). (Session lead is Glen Campbell)

Tuesday April 17, 2012 4:30pm - 5:25pm
Bayview B

5:30pm

Demo of Testing OpenStack with Tempest/Devstack
I will demonstrate how to test OpenStack easily with devstack and the Tempest integration suite. Intended to explain the relation between Tempest and devstack with regards to easy testing of OpenStack environments, walk through how Tempest is structured and provide information for contributors interested in participating in the QA team through Tempest. Tempest project: * https://launchpad.net/tempest * https://github.com/openstack/tempest Devstack: * http://devstack.org * https://github.com/openstack-dev/devstack Written walkthrough of what will be demonstrated: * http://www.joinfu.com/2012/03/testing-essex-rc1-with-devstack-and-tempest/ (Session lead is Jay Pipes)

Tuesday April 17, 2012 5:30pm - 5:55pm
Bayview B
 
Wednesday, April 18
 

9:00am

Puppet/OpenStack
This session will serve as a high level introduction to Puppet, focused on how it complements OpenStack. The session will cover the following: - A high level introduction of Puppet - An overview of our project to create Puppet modules for building and managing OpenStack - A call for the consolidation of existing OpenStack/Puppet modules into a master set (Session lead is Dan Bode)

Wednesday April 18, 2012 9:00am - 9:55am
Bayview B

10:00am

Colony
This session will be a presentation to review what has been done in colony so far and the directions the community could take going forward. Colony is a project which federate cloud services. The fisrt target is the federation of object services, like swift. A very brief introduction to colony is at https://github.com/nii-cloud/colony. Colony can be a project which makes Openstack a strong player in enabling federated cloud ecosystems. (Session lead is Shigetoshi Yokoyama)

Wednesday April 18, 2012 10:00am - 10:25am
Bayview B

11:00am

Java bindings for OpenStack
Presentation of the Java bindings for OpenStack that Luis & I have developed, along with some initial applications (a CLI, GWT, Jenkins plugins, Java 7 provider etc) Also a discussion of some of the problems we encountered, trying to use the XML schema etc from a strongly typed language, and possible implications (should we continue to support XML?) (Session lead is justinsb)

Wednesday April 18, 2012 11:00am - 11:25am
Bayview B

11:30am

How to track contributions to the community
Over 300 people from over 50 companies committed code to OpenStack during its, more than 150 companies are involved in the project, thousands of bugs tracked, tens of thousands of email messages, wiki edits, forum discussions... We'll present the current structure of the data collected from community contributions, the standard reports and a first version of a public portal to analyze such data. We should leave enough the time to discuss how to increase size and scope of the community metrics system of CpenStack. What part of this data is useful information for the OpenStack community? Are we collecting the right data? From the business perspective, what kind of data would be useful to track? (Session lead is Stefano Maffulli)

Wednesday April 18, 2012 11:30am - 12:25pm
Bayview B

2:00pm

Reddwarf PaaS building blocks
As more companies move their applications and data to the cloud, it is becoming increasingly difficult to manage and maintain PaaS systems on default virtual servers. RedDwarf aims to simply PaaS management in the cloud while providing a model for extensible service deployment that will be used to deliver not only database services, but also other services in the future. In this session you will get a chance to hear about our progress and future plans and learn how you can become active in the community. Reddwarf has been significantly refactored to bolt on top of nova properly and treat nova as a blackbox system. It has its own state information, its own database, and its own communication infrastructure. I would like to brainstorm on its current state, and how to best create the building blocks of a generic PaaS solution that can be used to build out multiple services. We can talk about the state of the current Reddwarf redux, and where to go with it in the future. Code/Docs can be found here. https://github.com/hub-cap/reddwarf_lite Integration (redstack) is here. https://github.com/hub-cap/reddwarf_lite-integration Client binding here. https://github.com/hub-cap/python-reddwarfclient (Session lead is Michael Basnight)

Wednesday April 18, 2012 2:00pm - 2:55pm
Bayview B

3:00pm

Cloud Foundry, BOSH, and CPIs like OpenStack
Presenter: Vadim Spivak and friends. Last minute addition to the Design Summit. Vadim will provide an technical overview of Cloud Foundry BOSH, the newest open source project from the Cloud Foundry team at VMware. The talk will be illustrated with ample code samples and will include a deep dive into the Cloud Provider Interface (CPI), the API in BOSH used to abstract the underlying infrastructure, including, for example, OpenStack. (Session lead is Lloyd Dewolf)

Wednesday April 18, 2012 3:00pm - 3:55pm
Bayview B

4:30pm

CI and Developer Infrastructure Roadmap for Folsom
We made some huge strides forward for Essex, and would like to continue the trend for Folsom. We'll start by presenting an overview of what we accomplished from a tooling and automation perspective in the last cycle, and then walk through what our current plans are for the next cycle. More importantly though, we'll do that reasonably quickly so that we can solicit feedback on what people need. (Session lead is Monty Taylor)

Wednesday April 18, 2012 4:30pm - 5:25pm
Bayview B

5:30pm

I18N in OpenStack
As of Essex only Nova and Glance use message translations, and the translation effort decreased significantly since Cactus. Do we really want translations, for messages that are usually sysadmin-facing ? If yes, can we standardize I18N across all core projects ? (Session lead is Thierry Carrez)

Wednesday April 18, 2012 5:30pm - 5:55pm
Bayview B