OpenStack Summit Fall 2012

Triage of doc bugs and how to get enough information to accurately answer and update them. This would be a discussion on how the process works, what we need to do to improve the process, and how best to engage those with the knowledge in order to do the fixes in a timely manner. We're currently at 112 bugs overall and need to get this back down to a reasonable number.

This session will start by describing the state and direction of the project and will end by a workshop on how and what to improve in the future.

More details at http://wiki.openstack.org/EfficientMetering/GrizzlySummit/StateOfMetering

Crowbar was the first open source OpenStack-focused deployment framework and been gaining significant traction as the foundation of both Dell and SUSE private clouds.  Crowbar makes deployments fast, repeatable and maintainable.  This session will give an update about Crowbar’s progress and capabilities such as late-binding deployment and sophisticated network configurations.  We’ll take time to explain where Crowbar is going because we’re expanding to include OpenStack upgrades, improved networking modeling, expanded cmdb support, heterogeneous operating systems, and pull from source.

Linux brought us main stream open source software.  OpenStack gave us open source cloud but we aren't done yet.  Open Compute has arrived.  The Open Compute Project is an open source hardware platform that will change the way we design and deploy data centers.  From software definition to supply chain management to efficiency, Open Compute will prove to be a game changer in the scale out data center.

Are you trying to stand up a large-scale multi-tenant cloud infrastructure without all of the hassles, complexity or cost of other “leading” commercial approaches? SolidFire and Canonical have joined forces to deliver a production-ready deployment of OpenStack Compute (Nova) and OpenStack Block Storage (Cinder). This SSD-based reference architecture provides a comprehensive blueprint for any OpenStack deployer looking to stand up cloud compute and block storage environment with predictable performance, fine-grain quality-of-service and significantly enhanced ease-of-use characteristics.

Attend this session to learn about this reference architecture in more detail, including information on deployment tools, tips and tricks, targeted use cases, benchmark results and key enabling technologies.

This session will explain how to use ceilometer to measure interesting things in a deployed environment and discuss creating custom notification listeners and pollsters.

More details at http://wiki.openstack.org/EfficientMetering/GrizzlySummit/CustomizingCeilometer

SDKs are a vital resource for any ecosystem and SDKs for OpenStack are proliferating. We should discuss what we can do to handle this from a documentation perspective.

Some of the topics/questions to address are:

1. What SDKs are you using and why?
2. How do we track SDKs that support OpenStack?
3. Where do we track SDKs that support OpenStack?
4. What criteria do we use to allow an SDK to claim OpenStack support?
5. When documenting the SDK API at the function level, do you duplicate info from api.openstack.org or do you just link to it? Are there other options?
6. What's missing from the documentation of the SDKs you're using?

In this session we will discuss these issues and any others that participants think are relevant. We will try to reach some kind of consensus and a pick a path forward.

http://etherpad.openstack.org/sdk-documentation

Live streaming on https://openstack.webex.com/openstack/onstage/g.php?t=a&d=923124308

Although many workloads are moving to virtual machines, there are circumstances where dedicated physical servers are required.  To meet these different requirements, the provider typically manages these services in heterogeneous environments, using Cloud Automation for VMs and provisioning physical servers manually.   In this session we share a solution for seamless provisioning and management of physical servers together with virtual machines in a unified OpenStack environment controlled through a single dashboard.  The implementation utilizes the existing Nova Compute APIs  to provision physical servers as well as the associated storage and networking, thus enabling physical machines to be provisioned and managed using the same methods as VMs.  The solution is implemented on AMD's family of SeaMicro Fabric Servers which integrate up to 256 servers, high performance networking, and shared storage in a single 10RU platform.  The  design challenges, capabilities, and next steps will be shared in this presentation. 

We will discuss how the open source Cloud Foundry project is used by Appfog to extend OpenStack to create true hybrid clouds. Inter-cloud connections and workload portability across various instances of OpenStack will be dived into. Demonstrations of how developers can simply create applications in their language of choice, deploy to instances of public OpenStack-based Clouds (i.e. HP Public Cloud, Rackspace, etc.), and easily move workloads from one cloud to another will be shown.

Synopsis: There is no easy answer or magic solution for Architecting your private cloud. OpenStack is flexible and can be designed in many ways so architecting your cloud correctly is extremely important. The goal of this talk is to provide guidance on how to start thinking about your private cloud architecture.  We will cover the following in this talk:

1. Build with the end in mind
2. To Swift or not to Swift
3. Architecture examples and thoughts for the following environment sizes:
a. 1-20 physical nodes
b. 20-100 physical nodes
4. Performance Considerations and Bottlenecks
4. Lessons Learned
5. Q/A and Community Input

Over the past few months, numerous request have been made to the Ceilometer project to extend its scope from just metering to more monitoring or alerting. This causes quite a few challenges but as we are instrumenting more and more openstack component to extract data from them, it makes sense to think on how we could extend our capabilities over time. We'll review 2 proposal: adding cloudwatch and alerting functionalities.

More details at http://wiki.openstack.org/EfficientMetering/GrizzlySummit/BeyondMetering

OpenStack documents has a serials of documents for administrators and API users. All these documents need to be translated during I18N.
Unlike code, there is no "froze date" of documents. The continues development of documents brings difficulties to the translation management.
This speech introduces the process and the technologies used in the translation management during OpenStack document internationalization. It also includes a demo to create a Chinese version of manuals.

Live streaming on https://openstack.webex.com/openstack/onstage/g.php?t=a&d=923124308

Let’s eliminate the lag between coding and deploying!  As we drive towards DevOps continuous deployment, it makes sense that our deployment scripts should be able to bypass packaging and pull directly from source code.  That’s exactly what the Crowbar team has created as an option for Folsom deployments.  This is a central use case for feature development because your testing code that is ahead of trunk; however, we see the same use cases for deployments that have bug fixes, proprietary features, pre-release features or any drift from trunk.  This feature is the path to get maximum control of your OpenStack deployment.

Comcast has been building out its private cloud to host its next-generation Cloud TV platform (http://techcrunch.com/2012/05/21/comcast-x1/), and as part of that effort the Comcast Silicon Valley Innovation Center has developed and in the process of open sourcing a compatible version of Amazon's Simple Notification Service (SNS) and Simple Queue Service (SQS) that we plan to contribute to or integrate with OpenStack. We've built these services on top of Redis (http://redis.io/) and Cassandra (http://cassandra.apache.org/) for multi-data-center availability and extreme scalability and very low latency.

I'd like to present the work we've done to date and get feedback from the OpenStack community. By the time of this conference our code will be open sourced on GitHub and available to the community.

Synopsis: Once your cloud is operational, day to day tasks are minimal however issues do arise. This talk is to designed to give operators ideas on what to monitor, tools available and some example procedures for common tasks.


1. Monitoring and Reporting
2. Tools used by the Rackspace Private Cloud support team
3. Performance and Scale considerations
4. Automated configuration Management
5. Examples of common day to day operational tasks
6. Lessons Learned
7. Q/A and Community Input

A Lightning talk is a short presentation, no longer than 5 minutes. Unlike other presentations at the OpenStack Summit. the lightning talks are unstructured and can be about anything: from code, to running, to any hobby you may have. You can use slides but the 5 minutes need to take into account setting up of your equipment.

You sign up for giving the talk the same day you'll want to deliver it. Participate to the opening sessions every day for more details.

Be creative and have fun.

Overview of the template format currently implemented in heat. Overview of the API heat provides for operating on templates. In this design session, expect 75% of time spent in open community design session on improvements to API and template model.

Session Lead will be Steven Dake.

With one production service already available at Rackspace and another on in the works at HP, cloud database services are quickly changing the landscape around OpenStack Compute.  Join Rackspace and HP for a lively discussion on how we are adding value to OpenStack with database services (Project RedDwarf).  As more companies move their applications and data to the cloud, it is becoming increasingly difficult to manage and maintain database systems on default virtual servers. RedDwarf simplifies database 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 RedDwarf’s progress and future plans and learn how you can become active in the community.

Hyper-V server is a powerful and free virtualization platform developed by Microsoft.   Hyper-V Nova Compute functionalty has been restored and merged into the Nova Compute code base in time for this Folsom release, thanks to the combined effort of Microsoft, Cloudbase Solutions and the great developers in our community.

In this session we'll demonstrate how to setup a Hyper-V 2012 based Folsom infrastructure for running Linux, Windows and FreeBSD instances.

Highlighting Hyper-V server’s great features  like Live Migration, Snapshotting, and Replica all within an Folsom Compute infrastructure.

Horizon is an excellent general Dashboard for Openstack but it's not a solution that fits for everyone.

At Morphlabs we had specific needs for our Private Cloud solution that didn't quite fit with Horizon. In this presentation I'll cover our decisions for building our own, the tools we've used and discoveries made along the way.

CloudWatch is a fundamental dependency of heat that provides monitoring and alarm features. In this design session, a brief description of cloudwatch is given as well as the current heat cloudwatch architecture. Expect 75% of time spent on open community design session discussion architecture and implementation feedback.

Session lead will be Angus Salkeld.

This is a brainstorm session to discuss Openstack API:

• Support – track the clients and versions that we support . How to keep track and communicate to Openstack community
• Documentation
• Testing –  brainstorm and agreement on version support, clients ,and data formats that are used for testing and also backward compatability , changes of API implementation, deprecating API process, Core products after integration and functional testing

The Ceilometer project was started 6 months ago on the realisation that all public cloud provider wanting to use OpenStack would need to rewrite exactly the same code to properly meter the use of their infrastructure.  Ceilometer stated goal is not to provide a full billing solution.  It deliberately limits itself to the first phase: collecting the information needed to establish billing lines. 

The project description states:

"Ceilometer aims to deliver a unique point of contact for billing systems to aquire all counters they need to establish customer billing, accross all current and future OpenStack components. The delivery of counters must be tracable and auditable, the counters must be easily extensible to support new projects, and agents doing data collections should be independent of the overall system."

A first version of Ceilometer will be released in parallel to Folsom's release, and the project has been submited as an incubation project in OpenStack.

This session aims at providing an overview of what the project offers today, how to deploy it and how it can be connected to rating and billing engines.

Due to its open nature and rapidly growing user base, OpenStack has become a hotbed and testing ground for disruptive innovations in cloud-computing virtualization, networking, and storage technologies. Rather than modify core OpenStack components directly, these technologies are introduced by extending or enhancing component functionality via the creation of new services and API extensions.

In this talk we will present a real-world case study of one such extension, which allows the "streamed" launching of VMs from a snapshotted "golden image", thus skipping the boot process and providing more rapid transition from the "off" state to the "ready to perform work" state. We will detail the key architectural questions that must be answered in the creation of such an extension, the development challenges that we encountered, and we will walk through the architecture and design of our extension itself. Additionally, we will address some of the business challenges that arise from building commercial software atop an open source project.

Overview of currently resolved heat roadmap items. Overview of current community derived roadmap items. Expect 75% of time spent brainstorming future roadmap items and identifying future changes necessary for Heat.

Session lead will be Steven Dake.

This collaborative session focuses on creating/maintaining community OpenStack deployment Puppet modules.  The goal of community modules is that they can  become the upstream source for OpenStack deployments and shared best practices.  In this session, we will review the current state of the code, flag items to be resolved, identify upcoming features and discuss design impacts required to implement those features.   Even if you’re not contributing to the upstream effort, this is a great place to join in the discussion around best practices and OpenStack operations.

Ceph is an open source distributed object store, network block device, and file system. Ceph can be used for object storage through its S3-compatible REST interface. It can also provide storage for network block devices, with the thin provisioning and copy-on-write cloning features necessary to support large-scale virtualization. With the Folsom release, Cinder makes block storage for backing VMs a first class feature in OpenStack. Block devices can be created from images stored in Glance, and with RBD behind both, new VMs can be created faster while using less space. This session will cover the current status of the integration, and discuss the technical implications and the advantages of block storage within the OpenStack cloud operating system.

Built on the materials from the popular Mirantis OpenStack BootCamp and delivered by the same instructors, this compact workshop will give you all the information you need to understand OpenStack and impress your peers with technical depth. The workshop is aimed at OpenStack newbies and semi-technical that just want to know what the hell is OpenStack all about.

Starting with a brief introduction to the problems OpenStack was designed to solve, we'll dive into vivid illustrations of how various components of OpenStack fit together by visually traversing the
request flow of provisioning a VM in NOVA and storing an object in Swift. Participants will work in groups to complete exercises and checkpoint each others understanding of the material. We'll close the session with a brief gloss over key lessons from real life deployments, HA deployment options and feature comparison with VMware and CloudStack.

Upgrade orchestrations are essential! We're both delighted and frustrated by OpenStack's pace of innovation because by the time we get the current release working then new hotness arrives. Last year, it was enough to just install OpenStack, but now we think it's required to have an upgrade plan. As the founders of Crowbar, we are leaders in the cookbook design for OpenStack and have a lot of experience with orchestration for OpenStack deployments. This community discussion about our proposed upgrade pattern reviews our recommendations and orchestration design. If you're interested in cookbooks that are testable and minimize complexity then this session is for you! We want orchestrations between versions that can focus on the specific use-cases around the migration scenarios like incremental, fastest-possible, change of operating system, or VM migration. If you agree that migrations between versions are also very important then look no farther!

This talk provides an overview of Heat, a peek inside the CloudFormation template language, and a live demonstration of heat technologies.  Heat provides an Apache 2 licensed CloudFormation orchestration engine that orchestrates cloud infrastructure resources such as storage, networking, instances, and applications into a repeatable running environment for OpenStack IAAS platforms.  Heat also provides several advanced features such as authentication, nested stacks, high availability, and auto-scaling which are demonstrated.

The audience will learn how Heat applies to OpenStack cloud environments using repeatable orchestration templates.  OpenStack Summit attendees can learn about the emerging CloudFormation template standard and its impact on Linux and open source cloud communities.  A speaker experienced with live demonstrations makes the medium technical difficulty approachable through real-life examples.

This collaborative session focuses on creating/maintaining community OpenStack deployment Chef cookbooks.  The goal of community cookbooks is that they can  become the upstream source for OpenStack deployments and shared best practices.  In this session, we will review the current state of the code, flag items to be resolved, identify upcoming features and discuss design impacts required to implement those features.   Even if you’re not contributing to the upstream effort, this is a great place to join in the discussion around best practices and OpenStack operations.

Nova (OpenStack Compute) gives us agility and flexibility for computing infrastructures. Virtualization plays an important role in Nova to provide those agility and flexibility; however, there is a performance penalty caused by virtualization. For example, there is significant performance degradation for response time and context switch on virtualized servers compared to bare-metal servers. Some (non-x86 based) machine architectures of interest to technical computing users have either poor or non-existent support for virtualization. Also some users want to use bare-metal machine itself w/o virtualization. One alternative to using virtualization to provision hardware in a cloud environment is to do bare-metal provisioning: rebooting the machine to a fresh system image before handing over control to the user, and wiping the local hard drive when the user is done with the resources.

NTT docomo and USC/ISI are proposing "General Bare-Metal Provisioning Framework on OpenStack (http://wiki.openstack.org/GeneralBareMetalProvisioningFramework)" to solve the problems. In the framework, we extended legacy schedulers to be able to provision an instance to both virtual and bare-metal machines. We also introduced a new nova-compute node that can manage several bare-metal machines. We embedded fault-tolerance of the nova-compute, since the failure of the nova-compute affectes to several bare-metal machines. x86_64 and TILEPro64 machines have already supported and more cpu architectures can be supported by adding CPU specific drivers to the nova compute node (e.g. power management and OS installation).

Using this, we can install VM image to a bare-metal machine directly using exact same API used in Nova. Since there is no hypervisor that isolates users from underlying resources, we integrated several components to achieve the same isolation level as provided by Nova. We replaced the following Nova functions to manage bare-metal machines.

1. Turn the power on and off -> IPMI (PXE) or PDU (non-PXE)
2. VM image provisioning -> PXE or non-PXE Boot
3. Network isolation -> Quantum + OpenFlow
4. iSCSI isolation -> IP access limitation
5. Console Access -> Serial over LAN

We believe this function gives several benefits to users.

1. A user can provision an instance to a virtual machine and a bare-metal machine through the same API. Therefore, we can use all the ecosystem created on top of Nova for a bare-metal server provisioning. For example, we can extend/shrink Nova Compute nodes based on a resource utilization using Auto-Scaling for VM.
2. We can migrate an instance from a virtual machine to a bare-metal machine based on a server load.
3. We can manage/update Nova infrastructure using Nova.
4. Various heterogeneous architectures (e.g. ARM, GPU) can be incorporated into the cloud with the bare-metal provisioning technique. We have shown provisioning the systems with x86_64 and TILEPro64 processors as bare-metal machines.

During the presentation, we will explain the current architecture proposed for grizzly release and a way of supporting new CPU architectures. We will also demonstrate auto-scaling of Nova compute by using this function.

RSVP here!

http://www.mirantis.com/sandiego-openstack-2012-kickoff-party/

Come Join DreamHost for some Good Clean Folsom Fun at
Bootlegger with Open Bar and Food from 8pm - Midnight!

Located at 804 Market Street  San Diego, CA 92101

RSVP below!

“Ubuntu's vision for Open Cloud computing and role in OpenStack”

Agility and scale are the twin goals of cloud computing. Companies want to improve developer agility and productivity, they also want the benefits of scale economics, both internally and from their public cloud providers. With production deployments of OpenStack onUbuntu12.04 LTS at many sites, including telco's, service providers and enterprises, and with Ubuntu being the OS deployed at the largest scale on public clouds, we have gained valuable insight into the challenges and opportunities that both present. Mark will share knowledge from Canonical's support of real OpenStack deployments together with news and roadmaps for cloud users that are building out large scale public and private clouds with Ubuntu and OpenStack.

After only two years, OpenStack has become the de-facto standard open source cloud computing platform and is the fastest growing open source project in history.  With over 5,000 members from over 850 different organizations in over 80 countries supporting over 500 active developers that have contributed over 500,000 lines of code, OpenStack is the foundation of numerous products and services.  The future of OpenStack will depend on ensuring that customers, service providers, and product companies are able to build the most innovative products and services on top of the OpenStack platform.  Chris C. Kemp, co-  founder of OpenStack and CEO of Nebula,  will discuss the challenges and opportunities ahead for OpenStack, the Foundation, the community, and the opportunity for OpenStack to disrupt enterprise computing in the next five years in the same way that mobile has disrupted personal computing.

This session will re-state the general idea of openstack-common, review the progress we made in Folsom and discuss general plans for the project in Grizzly.

We will discuss renaming to the project to Oslo, renaming the current repo to oslo-incubator, promoting some APIs out of incubation, a versioning scheme for library releases and a clear-out of stalled incubation efforts.

OpenStack delivers a massively scalable cloud management framework for use by any organization running on standard hardware. Joshua McKenty, one of OpenStack’s founders at NASA and a driving force behind its continued success, will discuss how OpenStack got its start, how it’s changing the cloud computing landscape, and the future of OpenStack in this new era of cloud computing.

In particular, Joshua will describe the major components of OpenStack — the virtual machines, virtual hard-drives, object storage, virtual networks, image registry, and the dashboard — as well as the associated sub-projects and the OpenStack services that combine to provide an incredibly flexible self-service infrastructure platform. He’ll also talk about some of the diverse use cases for OpenStack and the exciting ways in which companies are extending the capabilities and accessibility of OpenStack through partnerships and technology development.

At the Folsom design summit, OpenStack developers decided we would embrace infrastructure high availability, a standard feature in other cloud stack solutions. Infrastructure HA is particularly important to those users who are looking to OpenStack as a means of data center consolidation involving legacy applications, and who are not at liberty to execute a major application redesign from the ground up.

Since then, we have had seen the addition of an in-progress High Availability Guide, we have contributors writing integration code for the Pacemaker high-availability stack (the standard Linux HA infrastructure layer), and OpenStack is rapidly improving in high availability features. We are also seeing exciting progress in storage technologies like Swift and Ceph, which come with high availability built-in.

This session is a progress report and outlook on high availability features in Folsom and Grizzly.

Fortune 2000 companies are eager for OpenStack to open up cost models around cloud computing much like Linux did for operating systems but most have not yet taken the plunge.  Why?  In this talk, hear tales from the field of the most commonly cited missing features that the enterprises are asking for before taking fully embracing OpenStack for both private and public cloud usage.

Content will be scheduled on site.

During the Folsom summit we defined some requirements for a unified command line client program for OpenStack (http://wiki.openstack.org/UnifiedCLI). Since then we have begun development and made significant progress, but the project has stalled out a bit. During this session we will discuss restarting the project and find additional contributors.

Modern web and mobile applications demand a highly-available,
distributed object storage system that supports highly-concurrent
workloads. OpenStack Swift solves these problems at large services
providers, top web properties and large enterprises.

This talk will also provide an overview of Swift’s architecture where
you will learn about the components of Swift. This talk will also
cover use cases including high-volume websites, mobile application
development, custom file-sharing applications, data analytics and
providing private/public storage infrastructure-as-a-service.

This talk is also for those who want to understand the design goals of
Swift and how to best make use of this component of OpenStack. It’s a
great introduction for those interested in using or learning more
about Swift.

It's time to take Fog to the next level.  Fog is the leading Ruby abstraction library for the OpenStack API and it's embedded in several ecosystem products.  With the addition of Quantum, there is a need to extend Fog's models to comprehend cloud networking.  Our vision includes adding both hidden functionality like setting up networks by default and explicit functions that expose the power of elastic networking.  The goal of this session is to discuss the best ways to surface this functionality and coordinate development so that we do not duplicate or fork efforts.

Moderator: Gretchen Curtis, Piston

Panelists:

• Gary Chen
• Sean Michael Kerner
• Stephen O'Grady
• Krishnan Subramanian

A Lightning talk is a short presentation, no longer than 5 minutes. Unlike other presentations at the OpenStack Summit. the lightning talks are unstructured and can be about anything: from code, to running, to any hobby you may have. You can use slides but the 5 minutes need to take into account setting up of your equipment.

You sign up for giving the talk the same day you'll want to deliver it. Participate to the opening sessions every day for more details.

Be creative and have fun.

As the standard RPC call are being used more and more to convey information that may need to be auditable, some messages could need to carry additional security. Namely, some message could need to be signed and contain an incremental number incremented on each host.

If done correctly, this could allow to trace a series of messages (for example, billable events) and ensure that it has not been tempered with and that messages are not missing.

See also session http://summit.openstack.org/cfp/details/118 which is a precursor to that.

Based on a discussion we started with Eric Windisch, this effort is common with the work he stated and we will be joining our efforts in this session and hopefully in the future work.

https://blueprints.launchpad.net/nova/+spec/trusted-messaging

A presentation to introduce new members of the OpenStack Community to Nova. This will include a brief history of the project, an overview of the supporting projects (Glance, Keystone, Horizon, etc), API examples, and Nova architecture. The intended audience would be both new members of the community and more business-focused attendees as well as technical attendees who would like a good overview (or refresher) on Nova.

The open source configuration management and automation framework Chef is used to deploy and manage many large public and private installations of OpenStack and supports a wide variety of deployment scenarios. Chef for OpenStack is a project based on the healthy exchange of code, ideas and documentation for deploying and operating OpenStack with Chef. With involvement from Intel, Dell, HP, Rackspace and many others there is a community of collaboration between users, developers and operators. This session will discuss the currently available resources and documentation, the evolution and layout of the project and the roadmap going forward.

Joshua McKenty will take a look at the future of infrastructure automation as it pertains to the adoption of private and public clouds. Every layer of cloud comes down to infrastructure automation. Learn how the software-defined infrastructure is playing a part to orchestrate the underlying machines and virtual resources up through applications and the Paas layers.

Furthermore, Joshua will discuss how automating the integration of Paas and Iaas on a technical level has the potential to drive greater adoption of public and private clouds, and how it can even show ways to make the Paas layer install on top of OpenStack without human interaction.

Content will be scheduled on site.

The services framework from nova is in the process of being moved into openstack-common. I'd like to propose the following additions to the services framework to make it more useful:
* Signal Handling
--HUP to reload configs
--TERM die as soon as threads are finished
* Command and Control over RPC:
Pause (stop consuming regular queue messages)
Resume (continue consuming regular queu messages)
Reload (reload configs and continue)
Restart (run a new copy of the daemon and terminate this one)
* Potential Command and Control:
ChangeConfigOption (does it change the on disk config or just the running one?)
StartPaused (start a new copy of the code Paused, requires running simultaneous code)
SoftTerminate (terminate the instance when threads are finished)
NOTE: The last two could be useful for the following strategy:
a) StartPaused
b) Pause (this one)
c) Resume (new one)
d) SoftTerminate(this one)

Let me tell you a dirty little secret. While OpenStack is a great project, it is extremely complicated for and indivdual with an engineering/operations focus vs a programming focus to get to their first code contribution.

My name is Colin, I am and engineer. Although I initially got involved with OpenStack in the context of operations, I quickly was drawn into actually contributing code to the project. What I found is that many of the tools and workflows used to contribute to OpenStack are completely foreign to those (like me) with an operations focus.

In this session I will go over the biggest challenges that I faced as an engineer contributing. And review the  tools and techniques to that I used to get past them. This information will be presented with the goal of arming engineers just getting involved with the knowledge tools necessary to get to their first successful contribution and beyond.

Learning objectives

1. The importance of community - Leveraging the power of the meeting

2. Talking your employeer into supporting OpenStack and the CLA

3. Setting up your dev environments - getting beyond Devstack

4. Getting git, using the git repository for those that don't code for a living

5. Testing your code - what do you mean it doesn't build?

6. How to give back, and get other people involved in the community.

In this case study, Mercadolibre, e-commerce leader in Latin America, will share how they satisfy their huge needs of Infrastructure resources provisioning with OpenStack, when their technologies changed.

The will share a brief story about how they moved from a HigOps Virtualization Environment, to a real Cloud OS, set up around Openstack Compute (+1000 compute nodes), Swift, Keystone and Glance core services and how they managed to move from Cactus to Essex.

As an open innovation project, OpenStack attracts contributions from an overwhelming number of individuals and companies. Often, contributions are tactical, scratch-your-own-itch type. While welcome, this narrow focus can tend to add technical debt to the project and lower overall quality of the result. To ensure its long-term health, a project needs strategic contributions, focused on improving the quality, coherence and security of the end product.

In this presentation, Thierry Carrez, Release Manager for OpenStack, will introduce the contribution process within OpenStack, present the different types of contributions, and explain why some are more desirable than others. Mark McLoughlin, Principal Engineer at Red Hat and Project Technical Lead for OpenStack-Common, will follow up explaining how Red Hat is successfully contributing strategically to OpenStack and how other companies can follow this example.

Using the message bus for messages

The RPC library in openstack-common includes an API for sending and receiving RPC calls and for sending notification messages. It does not include usable APIs for subscribing to notifications, or for sending and receiving generic messages to be consumed by multiple workers. The ceilometer and quantum projects are hijacking notifications and using a low-level API to achieve this goal, but we need to add a public API and ensure that all of the RPC drivers support the pattern. The goal of this session is to agree on the basic design for such an API to be added during Grizzly.

Along with a way to receive notifications, we should also consider adding a more generic message API that is not tied to RPC. For example, as adoption of the ceilometer project grows, we may want to include a library for creating and sending metering messages from other services. We have such a library, using RPC right now, and it is mostly decoupled from the rest of ceilometer. At DreamHost we are building a service that will use the library, which will help us discover any other issues with removing it from ceilometer. It really shouldn't need to be based on RPC, though, since the messages are one way and meant to be consumed but need no reply.

Limitations of hardware-dependent networks are preventing enterprises from realizing the full potential of cloud computing, and therefore vastly limiting the return on their investment. Traditional networks don't scale in the same way storage and compute resources can scale and the only option generally is to scale up (purchasing bigger networking devices). There are several cons to this approach, such as; it’s not linearly scalable, it is expensive and this approach can cause service interruptions. The solution: virtualize the network.

In this session, Ben Cherian will educate the audience on what network virtualization is and the potential for this modern approach.

We are all participating in building OpenStack and just like Linux distributions, which helped would-be Linux users manage the complexity and configuration of myriad libraries, placement of files, and executables to successfully get the system to boot and run, all indications are that OpenStack distributions are poised to help would-be OpenStack users to quickly get a fully-functional and configured cloud up and running. Companies are bringing unique value-added capabilities  to the OpenStack core while fully providing enterprise support and services for their distributions. In this panel discussion, Dell will moderate a discussion with experts from Red Hat, Suse, Canonical, Morphlabs and Dell to discuss the importance of OpenStack distributions in the evolution of OpenStack and how they can support the needs of different markets and customer profiles.

Operating OpenStack successfully requires investing in automated process and configuration management.  This approach, known as DevOps, is changing how cloud applications and infrastructure is deployed and managed.  We’ve assembled a panel of top industry experts to discuss lessons learned and challenges remaining as OpenStack embraces DevOps.  Our panel speakers represent Puppet (Dan Bode), Chef (Matt Ray), Juju (Jorge Castro) and DevStack (Jesse Andrews).  Monty Taylor will lead the discussion as moderator.  Come prepared to learn about operating OpenStack and hear about the pros and cons of these different tools.

How OpenStack will score in the Brazilian Cloud! - Renato Armani

Openstack in India - opportunities galore - Sriram Subramanian

OpenStack for Vietnam's growth, and how OpenStack works with Government to make its impacts in developing countries - Trung Nguyen

The OpenStack way in China - Yujie Du

The goal of this session is to discuss whether the existing WSGI framework in openstack-common should be retained and used for future API work, or whether it makes more sense to look at some of the other Python web API frameworks and adopt something being used and maintained by the broader community. I will put together a few notes about why I chose not to use the openstack-common framework for the ceilometer API, and some pros and cons of other frameworks that we should evaluate.

Hear about how to get started deploying OpenStack and XenServer, including a demo of a new tool to help move your exisiting images into a XenServer based OpenStack cloud. Also come along to hear more about how Rackspace deploy XenServer in their public cloud.

The talk will hopefully include guest speakers: Mate Lakat (Citrix) and Chris Behrens (Rackspace)

This talk firstly provides an overview of dodai-deploy, the software

management tool which can be used to install openstack into multiple

machines environment. Then it reviews the history of dodai-deploy, and

show the new feature "Install As a Service". With the new feature, it is

no need to install dodai-deploy server any more. Users can log into a

global dodai-deploy server, select a software they want to install,

create an install plan, then do it automatically. If the time is

permitted, the talk will show a demo of how to install openstack with

the "Install As a Service" feature.

XML request and response processing in OpenStack has been a hot topic recently . The OpenStack code and development community has a large bias towards JSON and there have been proposals to deprecate support for XML. As a result, XML Request/Response processing is often not available or it is incorrect. However, XML is highly desired for accelerating adoption of OpenStack within the enterprise.

This session will be an open-ended discussion on various proposals on how to improve the XML request/response processing in OpenStack. One possibility is that a framework could be leverage or developed that would enable and make it much easier for OpenStack developers to support XML in all of the OpenStack services.

This session will explore potential solutions for XML processing around determining if a reasonable framework is developed to add it to all the OpenStack services. Additionally, we would like to discuss an overall process can be defined to resolve the current issues with XML as well as address future requirements in this area.

In this session we will explain our vision of how OpenStack will gain relevance in the datacenter to become the cornerstone from which all the services required for operation, existing or new, are going to be managed. This vision is the result of the feedback StackOps gets from users and customers worldwide. There are already service providers basing all their operations in OpenStack, many new OpenStack services being launched in different parts of the world and large companies betting on OpenStack as the main revenue generator for the future.

This change will be a process that will occur at different paces in the many different regions, sectors and businesses, due to factors of economic, legal, cultural and technological nature. In all cases, the result will be a total abstraction of most of the current datacenter procedures through automation, with the consequent gain in efficiency.

This process has a common denominator in all cases: it needs to be non-disruptive from the business perspective. This will be achieved by balancing out:

simplicity, not only on the deployment phase but most important on the daily operation
a high level of customization to match the specifics of each business
integrability with existing applications and or services
For all three elements, the OpenStack ecosystem has the challenge to find the right balance for each customer and evolve to fill in the existing gaps.

RSVP HERE!

Reach for the open clouds with Rackspace at Altitude Sky Lounge, located atop the Marriott Gaslamp, for unforgettable views of San Diego's skyline while you catch up with your friends from Rackspace and the OpenStack community. Rackspace, the open cloud company, will provide an open bar and plenty of food to get your night started.

Altitude Sky Lounge

(Rooftop bar – Marriott Gaslamp)

http://www.altitudeskylounge.com/enter

660 K St.

San Diego, CA 92101

6:00p-8:00p

 RSVP here

Join Nebula and our team – including many of the engineers and developers who originated the OpenStack project – for conversation, cocktails and light appetizers after a busy Tuesday at the OpenStack Design Summit.  

As an accompaniment to talking open cloud with some of the brightest in the industry, we’re pleased to feature a performance by local DJ legend Mark E. Quark and his trademark blend of house and industrial.

WHEN                                                                                                             

Tuesday, Oct 16th from 8pm to 11pm

WHERE                                                                                                                  

Andaz Hotel Rooftop Lounge @ 600 F Street, San Diego (Less than a mile from the conference venue)

WHO                                                                                                                  

Anybody with an OpenStack Design Summit badge is welcome to attend.

WHAT                                                                                                                    

Drinks, music, and light appetizers.

Get to know the new OpenStack Board of Directors during breakfast Wednesday morning. We'll make a few quick introductions and then provide an opportunity for everyone to interact and ask questions. You can find more information about the Board of Directors here: http://www.openstack.org/foundation/board-of-directors/

Enterprises have been steadily embracing private cloud environments and are increasingly finding use cases for the public cloud. We are past the point of the cloud being limited to shadow IT and startups. We are now entering the next wave of innovation and adoption which will drive the migration of production workloads to a cloud model and will require seamless public to private interoperability.   

This move will create a greater demand for cloud platforms that provide innovative, open services in a secure environment, backed by business level SLAs, and supported by quality service. Adopting a hybrid delivery model to ensure flexibility and scale will no longer be an option but rather a necessity.  

Zorawar 'Biri' Singh, SVP & GM, HP Cloud Services, will share how HP's customers are currently taking advantage of this hybrid delivery capability through HP's Converged Cloud vision and strategy. He'll discuss the untapped opportunities and benefits to moving production workloads to the cloud and the potential for OpenStack to lead this next wave of adoption.

WebEx is a leader in on-demand collaboration and the second largest vendor of SaaS for business applications in the world. Earlier this year, the company placed a strategic bet on OpenStack to build a private cloud platform for many of its mission-critical apps. In collaboration with Mirantis, WebEx was able to successfully traverse the implementation path and is currently onboarding a number of production workloads onto its OpenStack cloud. In this talk, WebEx will share more about the project, rationale behind choosing OpenStack, some of the key road-blocks on the path to production and touch upon the future roadmap.

DreamHost is launching several public cloud offerings, and along the way
we have learned a lot of information. The goal of this talk is to share
some of the lessons, tips, and tricks we have learned while designing
public cloud architectures.

Talk Outline and Notes:
The problems: Scale, Speed, Monitoring, Uptime, Security, Cost.
The domains: Networking, Storage, Hypervisors.

Scale: The pervasive problem. There are obvious issues (Data Center
Size, Network Switching Architecture, etc), but there are also the
not-so-obvious problems: DNS zone sizes and rebuild times, ARP/ND table
sizes, growing beyond Ethernet VLANs, and multiplication factor on small
delays. IPv6 is a requirement, not a nice to have, because we're out of
IPv4.

Speed: Disk I/O, Memory I/O, Network I/O, and CPU time all matter.
Performance cannot be cloud washed any longer. Beyond the user focused
problems there are pressing concerns inside the provider as well: how
fast can you expand? Automation is a requirement here that may cause
some initial delays will pay off long term.

Monitoring: Start with simple service monitoring via Nagios, then go
deeper. Agents on every everything. "Graph all the things" (we use
graphite).

Uptime: Decouple everything. Have multiple paths. Maintenance windows
are a thing of the past. HA is no longer an option, it's a requirement.
DevOps is the start, but planning and testing are critical.

Security: IPv6 is not IPv4 with more addresses; there are solutions to
common problems (ND replaces ARP), and introduction of new ones (RA).
Standard shared hosting/colo security models no longer work. The barrier
to entry in the cloud is a few cents, not a contract and an account
manager. Providers have to be proactive about security: SPAM, traffic
patterns, and bad money.

Cost: Forget everything you know about traditional storage. NFS, iSCSI,
SAN: these all do too little for too much money. Thinks like Ceph and
other Open Source technologies are game changers. Don't jump to the
other end of the pool either: consumer SATA brings a whole different
world of pain (time-outs and retries cause massive and hidden
performance degradation). We're going for the middle of the road:
Enterprise SATA and Enterprise SAS.

We are trying to open a new world in cloud computing: open tech, open
standards, and talking in the open. We think cloud should no longer be a
black box, and we're willing to talk about it on the record.

In a little over two years, OpenStack has shattered adoption benchmarks set by previous open source projects and gained acceptance as the future of the data center but has your career kept up with its blistering pace? Come join Niki Acosta, Cloud Evangelist at Rackspace in an engaging panel session to learn about the career paths of OpenStack heavyweights and how you can accelerate your career with OpenStack. Panelists will include John Purrier, CTO at AppFog; Gretchen Curtis, Co-Founder and Chief Strategy Officer at Piston Cloud Computing; Mike Metral, formerly of Sandia Labs and current Enterprise Architect at Rackspace; and John Dickinson, Director of Technology at SwiftStack and PTL for OpenStack Swift.  

I started a set of patches towards the end of the folsom cycle to allow the use of entry points for plugin and extension loading in nova. This was rightly rejected as a new thing that hadn't so much been discussed. However, in general I still like the idea of it, given that python does have this nice mechanism for plugin loading.

Why don't we walk through what it looks like, whether we should do it and how.

Did you know that VMware is a top-10 code and bugfix contributor to OpenStack and that VMware has  helped customers with Openstack production deployments? In this session, learn howcustomers are using OpenStack with VMware offerings like ESX, CloudFoundry and RabbitMQ. Walk away with a better understanding of VMware’s plans with OpenStack and the software-defined data center as well as VMware’s efforts around expanding Nicira’s contributions to Quantum and Open vSwitch.

While traditional HA and clustering techniques work for many cases, they are also frequently at the root of catastrophic failures. In this presentation we will cover other well understood and proven approaches to providing greater uptime.  Load balancing and service distribution patterns provide an alternative that allows for better horizontal scaling, greater aggregate throughput, and have failure characteristics that reduce the chance of cascading failures.  In addition, these alternative approaches are typically simpler to implement and have fewer moving parts, which means they are less prone to failures and have significantly less operational overhead.  In this session we'll discuss general principles around using equal-cost multi-pathing (ECMP) for IP flow load balancing, using routing protocols judiciously for managing ECMP flows, and show what happens in various failure conditions and how this is different from traditional load balancers, HA pairs, or clustering.

Rackspace’s Enterprise Business Intelligence group (EBI) was seeking a way to move away from their current Data Warehouse solution. They were looking for a cost effective way to scale out new infrastructure in order to meet the increasing business demands of users, house increasing amounts of data, and customize the collection of data.  For this, they utilized Hadoop, Cassandra and PostgreSQL with an OpenStack cloud and build the Analytical Compute Grid (ACG). 

Analytical Compute Grid(ACG) is solution that enables Rackspace to:

• House an ever growing set of data collected from multiple business units.
• Allow for quick collection of data
• Rapidly scale up and down to meet fluctuating demands.
• Provision a wide variety of open sourced virtual machines.
• Utilize open source technology to move away from enterprise license fees and avoid vendor lock in to any one particular product.

The team selected OpenStack to be the heart of the Analytic Compute Grid for the following reasons:

• OpenStack is compromised of a rich and robust API allowing the ACG engine to interface with OpenStack to perform all of the necessary dynamic scaling functions.
• ACG needs to rapidly create and destroy virtual machines. OpenStack provides the necessary speed of provisioning and scale to accomplish these tasks.
• ACG utilize OpenStack images to create system VMs. An OpenStack image contains all components necessary for VM to join ACG system.

OpenStack allow us to configure images with different data stores:

• Cassandra database for columnar data structures
• PostgreSQL  for relational data structures
• Hadoop distributed file system for large unstructured and noisy data

As the result, ACG enables users to select optimal data store for information collected. ACG provides SQL like syntax for data retrieval via standard JDBC interface regardless of the underlying data store type. 

Come hear about how Rackspace is using OpenStack to help manage it's data.

Contributing to free software projects requires persistence, humility, and above all, good communication skills. Is it possible to teach these to aspiring contributors? If so, how?

Upstream University was founded with the belief that this is not only possible but desirable from the point of view of the free software communities, the contributors themselves, and even the companies that hire them.  With the backing of luminaries such as Richard Stallman, Bradley Kuhn, Karen Sandler and Dave Neary, it devised a training program aimed at helping professional developers (and documenters!) contribute successfully to free software projects.

This talk, originally conceived as a workshop with Stefano Maffulli during the OpenStack Party at Oscon 2012, will expose Upstream University's short history, its challenges, and successess.  Most importantly, and in true free software spirit, as much as possible of the hard-earned lessons will be shared in the short time available.

Contributing to free software projects requires persistence, humility, and above all, good communication skills. Is it possible to teach these to aspiring contributors? If so, how?

Upstream University was founded with the belief that this is not only possible but desirable from the point of view of the free software communities, the contributors themselves, and even the companies that hire them.  With the backing of luminaries such as Richard Stallman, Bradley Kuhn, Karen Sandler and Dave Neary, it devised a training program aimed at helping professional developers (and documenters!) contribute successfully to free software projects.

This talk, originally conceived as a workshop with Stefano Maffulli during the OpenStack Party at Oscon 2012, will expose Upstream University's short history, its challenges, and successess.  Most importantly, and in true free software spirit, as much as possible of the hard-earned lessons will be shared in the short time available.

This session will primarily focus on merging rootwrap into openstack-common and further improvements to it. Time at the end of the session will be assigned to discuss incorporating keyring usage into the service infrastructure and any further service security infrastructure ideas.

This session will include the following subject(s):

Towards a unified and more featureful rootwrap:

Multiple projects (Nova, Cinder, Quantum) have adopted nova-rootwrap, so moving it to openstack-common sounds like a good idea to avoid code duplication and painful sync.

In this session we will discuss the plan to push rootwrap into openstack-common, as well as additional features for rootwrap (path searching, logging, Python code execution).

All your passwords belong to keyrings?:

Clients are starting to use python-keyring for passwords. It would seem to make sense to have other sensitive passwords also use a similar mechanism (for example in nova.conf, or in keystone.conf or in paste api ini files and so on). These places shouldn't have clear text passwords even though they do right now (eck). But I'd like to get input on what people think about that and possibly any issues they see.

Startups and enterprises alike have placed their strategic bets to monetize the OpenStack wave in various ways. As an ecosystem insider and board memeber of the OpenStack Foundation, in his talk, Boris Renski will offer his views on how various organizations in the OpenStack ecosystem are trying to monetize it today. He will also share his perspective on what works and what doesn’t, based on his experience helping grow Mirantis’ OpenStack business to 60+ people in just under 18 months.

Everyone loves it when things are fast, and that statement holds true whether you're visiting http://www.livingsocial.com or whether you're hitting the OpenStack Nova API and requesting, "Please show me all the instances which I've got running". Nobody ever writes in asking for support and saying, "All of my API calls are completing far too quickly. Slow it down!".

Optimizing the performance of software is arguably a never ending crusade. At some point in time you'll get things fast enough that you can say, "Any effort invested beyond this point is not adding value for the business" but then along comes new code which adds a zillion awesome features, but also regresses performance back to a level where it needs another tune-up.

In the process of transforming our infrastructure and preparing our new OpenStack IaaS to host all our applications, we've been looking for performance wins across the whole stack. We've got some aggressive targets to meet. We've investigated many hardware options and chosen an optimal solution, we've instrumented some of the OpenStack APIs and benchmarked to produce interesting results, and whilst we're not done yet, we do have a "Half-Time Match Report".

Join me as I walk through our learnings so far and propose follow-on areas for investigation and optimization.

A Lightning talk is a short presentation, no longer than 5 minutes. Unlike other presentations at the OpenStack Summit. the lightning talks are unstructured and can be about anything: from code, to running, to any hobby you may have. You can use slides but the 5 minutes need to take into account setting up of your equipment.

You sign up for giving the talk the same day you'll want to deliver it. Participate to the opening sessions every day for more details.

Be creative and have fun.

With the rapid growth of Sina Weibo, which now has over 350 million registered users around the world, and its affiliated services such as Weibo open API and the WeiGame platform which are now the most popular social and online gaming platform in China, we needed a robust and flexible infrastructure to host those applications and platforms.

In the early 2011, we initiated Sina Web Services (SWS), the first public IaaS cloud based on OpenStack in China. Thanks to the extensible architecture of OpenStack and the help of the OpenStack community, we were able to build up our IaaS platform and push it into production in a very short time.

We have accumulated much experience over 1.5 years of developing and operating an OpenStack public cloud. Since OpenStack now is far away from a 'turnkey' solution, in order to put it to production use, we must develop some necessary services in addition to the current projects of OpenStack. In this presentation, I will dive into the actual deployment and network topology of our production environment. I will also share about the extensions that we have made to OpenStack, such as Keystone integration to our existing identity system, OpenStack security enhancement, Swift performance optimization. I will also make public the design and architecture of our own service, such as LBaaS implementation; user & admin console, whose UI and underlying components are designed by ourselves that is now completely different from Horizon; Dough and Kanyun, which are now community project addressing metering and billing issue of OpenStack.

Regarding the operation of OpenStack, I will also talk about how we manage the internal branch and official code base of OpenStack, and how we build our CI system to archive highly automatic operation.

The OpenStack project consists of dozens of sub-projects and each of those are managed via a number of email lists and forums as well as software engineering tools such as issue trackers, version control, continuous integration, etc. Achieving a coherent view of all the information is tedious and immensely difficult. In this session, you will learn how the OpenStack Community team is piloting the Wikidsmart platform from zAgile to integrate information across different systems for a unified view in real-time dashboards. Instant questions can now be answered with faceted search of concepts across all the different repositories. And people and artifacts can be traced across different repositories in order to reconcile people and corresponding contributions.

Database code now exists in several projects, and much of it needs improvement. While improving the database abstraction itself is a good thing, it is difficult to do across various projects without it being moved into a common place. Additionally, there is code being sought for inclusion into openstack-common (oslo) which requires database access. For these reasons, a blueprint has been registered to move the database abstraction into common.

I will discussion my intentions, the new database library architecture, and how this will affect other blueprints such as db-threadpool and no-db-compute.

Most drivers in Cinder don't deal with local storage rather have a backend storage and an associated api. As an operator, managing multiple backends with Cinder becomes a hassle as each backend requires a single (or more for HA) instance of volume-manager.

This sessions wishes to answer the following and more:
- Who would use it?
- What are the benefits?
- What are the downsides?
- Do the drivers need to change to accomodate this?
- How do we schedule, how to choose the right backend?
- Does scheduling support for this fall under volume_types or a new volume_backend?

With the Nicira acquisition, the spotlight is on network virtualization. The Folsom release will introduce OpenStack’s networking component for the first time. And indeed, networking may turn out to be the most strategic component in OpenStack, and the key to realizing a vision of the software-defined data center. It’s a big opportunity and in addition to Nicira, there are many start-ups already tackling the challenges to network virtualization. This panel will include representatives from a few of these companies: Midokura, BigSwitch and 1-2 others, in a space that is quickly becoming more strategic to OpenStack success. Topics will include VMware’s acquisition of Nicira, estimated market opportunity for network virtualization (or SDN), realities of enterprise adoption, challenges to standard OpenStack networking (automation, scale, security etc.) and different technical approaches. The panel will conclude with predictions from the panel and an interactive Q&A with the audience.

The default Nova configuration works well for many use cases, but there are a myriad of options (many underused) that can help Nova better suit your needs. This talk will discuss some of these options, with a focus on new options in Folsom.

Nova’s configuration options:

• 3 RPC backends
• 3+ DB backends
• 5+ virtualization layers
• 500+ configuration options

Content will be scheduled on site.

At the beginning of 2012, eBay decided to overhaul its technology platform to support an increased focus on rapid innovation, and developer efficiency. To support this effort we built a developer cloud as an extension to our production cloud to give developers maximum flexibility and freedom while protecting business critical infrastructure.

This talk will present the challenges of designing a network infrastructure for both scale, and isolation, and how by using Software Defined Networks we were able to accommodate these two dimensions. We will also go through the automation aspects, presenting how the combination of openstack and quantum, allowed the rapid deployment of our developer cloud.

For performance, metrics and scaling tasks there is a strong need to have various components/code instrumented (call times, error counts, roundtrip times...). Currently ceilometer has similar data but different fundamental requirements so this session should talk about whether to augment ceilometer with this data or create a new tool. New code 'decorators' (which are not relevant to ceilometer) need to also be added to gather this information.

Many stackers are depending on OpenStack for large scale and revenue generating operations. In these environments, it is critical to monitor the health and optimize the performance of OpenStack components.

Expand on the discussion had on irc and on etherpad on use cases for volume_types and how the drivers / scheduler should handle it. Talk more about metrics the drivers need to expose to the scheduler.

http://etherpad.openstack.org/cinder-usecases

Openstack has started what will be a complete rebuild of the enterprise data center. It will take time and wont be a straight path but this shift represents one of the most fundamental changes to enterprise infrastructure. Many existing companies will adapt and thrive - many more will fail. The massive disruption in the enterprise IT market will create enormous opportunities for startups in the years ahead. My talk will go over some of my observations as a venture investor and why this is the time to think about openstack as a foundation for your startup.

The default Essex Nova scheduler is slow when it comes to scheduling multiple VMs. Taking about 26 seconds to schedule 100 VMs in our lab environment.  This talk will cover the process we took to identify the bottlenecks in the scheduler, in both the Essex and Folsom schedulers.  Covering:

• profiling Nova
• how eventlet changes everything
• interplay between sql and Nova
• understanding Nova logs
• RPC
• frequency scaling

CERN, the European Laboratory for particle physics, supports over 10,000 scientists world wide in their quest to find out what the Universe is made of and how it works. As part of a multi-year project to modernise and streamline its tools and processes, CERN is using OpenStack and other leading open source tools to double the computing resources available for physicists to around 15,000 servers by 2015.

This talk will review the current state of OpenStack at CERN, the early experiences of deployment such as LDAP integration and configuring with Puppet along with the plans for production.

This session will include the following subject(s):

New features:

New features that are too small on their own for a slot on their own:

Secure attach - modifying the attach path to go via a cinder control node before going to the compute node, so that the complete compromise of a compute node does not result in any more volumes being exposed than already happen to be attached to that node.

Retain glance metadata for bootable volumes
https://blueprints.launchpad.net/cinder/+spec/retain-glance-metadata-for-billing

List bootable volumes - proposal for the concept of a bootable volume - purely volume created from glace, for UI easy of design

Volume backup - an API to copy a volume to object store

IOPs meeting / billing
https://blueprints.launchpad.net/cinder/+spec/volume-usage-metering

Volume resize

Volume status state machine (ClayG)

OpenStack's clients and APIs are the first point of contact for users of OpenStack clouds, and the foundation upon which tools can be built. As such, it's time we start focusing on making that a first-class consistent experience.

Simple things like providing consistently named and implemented methods, and consistent sets of features (wherever implementation allows). If I've used one core OpenStack API I should be able to expect the same from another.

Examples of these types of features include:

* Filtering a list of resources on any attribute of the resource. (e.g. GET /servers?security_group=foo)

* Ordering (timestamp, alphabetical, etc.)

* Bulk actions (GET in bulk, DELETE in bulk, etc.)

* Many more...

The goal of this session is to determine a common set of features the community/user-base needs, and make that a contract which every API and client should strive towards.

It is *not* meant to rewrite any existing APIs, or make any backwards-incompatible changes. This is only to agree on our collective future and perhaps look at the easiest initial targets.

Learn more about Red Hat's cloud strategy and how OpenStack is becoming a big part of it. From delivering the core open source building blocks that power today's leading clouds to collaborating with the OpenStack community in building tomorrow's open source cloud platform - Red Hat offers a comprehensive set of products for customers to build an Open Hybrid Cloud.

At the OpenStack Design Summit and Conference in October 2011, Rackspace announced that it would be moving the OpenStack open source project to a separate foundation.  Following that, OpenStack invited community participation to help guide the process of moving to a foundation.  There have been a number of lessons learned during this process and a couple of members of the OpenStack Drafting Committee would like to share those with you.  This session will be led by Alice King, Vice President & Associate General Counsel, Rackspace, and Eileen Evans, Vice President & Associate General Counsel, Hewlett-Packard Company.

When Morplabs created mCloud - cloud software intended to allow service providers and enterprises to create EC2-like private clouds - Eucalyptus was the only open source compute cloud project in the game.

That all changed in July 2010 with the launch of OpenStack.

With multiple production deployments of Eucalyptus-based mCloud, find out how Morphlabs moved from Eucalyptus to OpenStack in 6 weeks.

Christopher Aedo will go into detail around pain points and challenges the team faced.

Nicira runs its Worldwide(WW) Field and Sales Engineering team's customer-facing demo and evaluation infrastructure as well as Engineering DevTest, Build and QA automation infrastructure on an internal private OpenStack Cloud that is built using OpenStack Essex components, OpenStack Quantum and a front-end UI that lets users deploy complex, multi-tier Enterprise application with multiple private networks, with just a click of a button!

In this presentation, we will provide user's with an overview of Nicira OpenStack Cloud, our complex enterprise customer use-cases for an OpenStack Cloud and how we have on-boarded following applications to the cloud:

• A complex training environment for Nicira's Network Virtualization Platform that requires 9 VMs and 4 Private networks, and a topology that requires varying # of nics on each VM.
• A training lab that uses OpenStack, Quantum and Nicira's Network Virtualization Platform to create a complete OpenStack deployment within an OpenStack Tenant!
• Ability to dynamically add/remove users to "projects" based on the user's current assignment.
• Cloud-bursting of our dedicated Software Development build environment to our OpenStack Cloud for on-demand elastic compute capacity.
• Ability create isolated private virtualized networks in our OpenStack cloud using OpenStack Quantum.

 
We will also go over the $ savings achieved in each of these use-cases by on-boarding our enterprise apps to our OpenStack Cloud.

The current volume api needs some TLC. Bringing a volume service to production has helped us identify areas where the current volume API is lacking. I would like to propose that we take a look at what can be done to whip the current volume api in shape to make a v2.0 of the api, and begin discussion of where the api should go down the road.

A short session, hopefully early in the week, where we can talk about what we accomplished this past cycle in the CI and dev infrastructure world, as well as what it is that we're planning to do already. Hopefully if we tell everyone what's already on the table before we start planning other things, it can be in the back of everyone's heads as we plan during the rest of the week.

Since its creation, OpenStack has enabled developers to build easy-to-use, massively scalable public and private clouds. This session will look at a new use for OpenStack that is helping organizations of all sizes thrive in a changing IT environment: cloud-hosted virtual desktops.

The consumerization of IT is changing the way the workforce operates, with mobility, remote workers and BYOD presenting tough challenges for IT administrators. Since introduction, virtual desktop infrastructure (VDI) looked to be a promising solution, but fell short due to high CapEx costs and complicated on-site infrastructure requirements. Solution providers such as Dell, NaviSite, Rackspace and NetApp are instead turning to the cloud to host virtual desktops that are affordable, quick to provision and easy to manage. With OpenStack as the foundation for cloud-hosted virtual desktops, service providers can reduce operational costs while deploying Windows desktops that are secure, scalable and accessible on any device.

In this session, Desktone Vice President of Engineering Ken Ringdahl will discuss how OpenStack can simplify virtual desktop deployments. The discussion will include:

• Examples of use cases for cloud-hosted virtual desktops founded on OpenStack.
• The unique properties of desktops when running on the cloud, and how these can be addressed in OpenStack type architectures.
• How the underlying storage, compute and networking infrastructure of OpenStack enables service providers to choose a preferred infrastructure vendor.
• The ability of tenant automation to drive down onboarding costs.
• Best practices for integrating cloud-hosted virtual desktops with other IaaS initiatives to share infrastructure, reduce equipment and enable faster deployment.

In this talk the patent context of open source and Linux will be outlined including the evolution from the SCO litigation through to the Mobile Patent Wars.  As part of this history the formation and operational evolution of OIN from passive to active deterrent will be discussed with an eye toward providing OpenStack Foundation members the benefit of OIN's experience as well as offering a set of considerations designed to aid in shaping the Foundation's IP policy.   This session will be presented by Keith Bergelt, CEO of Open Invention Network, in the hope of ensuring the Foundation's IP policy advances the OpenStack project's goals and is coherent with OIN's community-based approach to the preservation of freedom from patent aggression.

As enterprises grow to adopt OpenStack, use cases around resillient storage and the vendors they already have procurement relationships with keep popping up. There are two foundational functions that need to be supported within OpenStack in order as foundations to build a rich storage system that meets the demands of the enterprise. I'd like to focus on what the community wants to see in these features and how they should be built.

* Storage Tiering - This allows for less critical instances to be placed on commodity storage, and for dev&test environments to be placed on lower grade environments. Can this be accomplished by the multi-provider code being submitted, a hint to the storage system underneath, or do we need to put in something new? What semantics would we like to put in place here?
* Shared Volumes - Many clustering filesystems and solutions such as SQL Server rely on shared storage volumes being presented to multiple instances. Currently, volumes can only be mounted to one instance within Cinder. Should we change this restriction to all volumes (traditional local disk installations are in capable of this), or create a new type of volume to support instance sharing?

Enterprise IT is increasingly challenged to not only reduce costs but also respond to business imperatives with agility and innovation. Intel IT has addressed this challenge since 2010 by deploying a private cloud
and continuously evolving its infrastructure. To improve the speed and availability with which we deploy new cloud services, we recently augmented our private cloud with OpenStack along with our own internal code. Das Kamhout, Intel IT Principal Engineer, will map the journey Intel took to integrate OpenStack into our enterprise environment and what enterprise IT needs from OpenStack. Join this session to discuss how I ntel and the OpenStack community can work together to catalyze this transformation in the datacenter.

Rackspace Cloud Block Storage is launching soon. I'd like to describe briefly what the team built, what parts Lunr and OpenStack play in the product, and then dive into some lessons learned in the design and development of a scalable commodity hardware based storage solution and interfacing with nova-volumes, cinder, and the xen storage manager. After that, if anyone is still awake, probably end the talk with a quick wrap up highlighting some of the areas we think OpenStack volumes has the biggest opportunities to improve and with the communities blessing how we can contribute!

The OpenStack Vulnerability Management Team is responsible for handling the process for handling security vulnerabilities that have been reported to the project. The purpose of this session is to discuss any potential improvements that could be made to our handling of security issues.


Team info: http://www.openstack.org/projects/openstack-security/

Process: http://wiki.openstack.org/VulnerabilityManagement

Cloud computing workloads are increasingly sophisticated and specialized. End users continue to recognize the value of choice of their computing infrastructure (i.e. being able to select the 'right tool for the job' in their data centers). Why is computational architectural diversity important? How do you work with a relatively new community on enabling choice? Is it possible to do so in a manner that is viewed as a "win-win" for everyone? Please join us for an overview of how IBM is working with the OpenStack Community to expand the choices available to our customers which enables them to optimize their workloads, while at the same time helping to advance the cause of open cloud computing

The past five years have been a time of significant transformation in the legal and policy side of open source, particularly concerning expectations around relationships between open source community projects and corporate participants. This talk will discuss these developments and explain how they are illustrated by the launch of the OpenStack project and the licensing, contribution and governance models it has adopted.

In recent times, there has been a growing interest in evaluating the feasibility of running High Performance Computing (HPC) applications on cloud computing environments. Flexibility, scalability, and dynamic provisioning capabilities provided by a cloud infrastructure make it an attractive platform for running HPC applications. One important requirement of running today's data-intensive HPC applications is the availability of a parallel high performance storage system. Scalability and high bandwidth from the storage system are critical for HPC applications. Researchers have studied the I/O performance obtained from the traditional cloud storage options such as the persistent and ephemeral block storage. However there has not been any comprehensive studies about how a parallel file system (PFS) can be effectively integrated and provided as a service to cloud users running HPC applications and what would be the performance and security implications of such systems.

The objectives of our work to integrate a PFS in a cloud environment are two-fold: first, to determine the most efficient way to access a PFS from virtual-machine instances in the cloud, and second, to design a framework to provide the PFS as a service through the OpenStack platform.

We have identified and implemented three ways in which a high-performance file system can be used in HPC-cloud environment using Lustre:
A. PFS as a back-end to persistent volume storage
B. Accessing the PFS directly through file-system clients running inside the virtual machine instances
C. Accessing the PFS mounted on the virtual machine hosts through file-system pass-through from the instances. We are in the process of evaluating in detail the performance characteristics and security implications of each of these methods.

We are also looking at incorporating a file-system service inside the OpenStack framework that would allow users to provision and configure PFS storage dynamically and securely, in much the same way they can provision instances and volumes. The challenges involve ensuring security and isolation in allocating storage to the cloud users, and determining the file-system configuration options that should be exposed to the users through the file-system service APIs.

Connect. Eat. Play. 

At the New Children’s Art Museum 

Please join the HP team for a fun and spirited get together at The New Children’s Museum (across the street from the Manchester Grand Hyatt), 200 West Island Ave – San Diego, CA   

•  Check out the inspiring and whimsical art while eating great food, sampling tequilas, and tasting some of the best microbrews San Diego has to offer!   

•  Shuttles for Piston Cloud’s party will depart from the New Children’s Museum at 8:00pm. 

•  Don’t miss it! Event is limited to the first 800 people that arrive.

People familiar with Piston Cloud know that we usually have a thing or three up our collective sleeve. And the upcoming OpenStack Summit in San Diego is no exception.

On Wednesday, October 17th, from 8 ‘til late, we invite you to join us for an uncommonly fine blend of soirée, splurge and spectacle, with a heaping dash of gentleperson-ly swagger for good measure.

WHEN
Wednesday, October 17 from 8pm ‘til late

WHERE
The Stingaree, an exclusive multi-level discothèque. Max out in front of the fireplace on the VIP rooftop lounge or shake your tailfeather to the tunes in the guest house.

WHAT
Featuring the world premiere of Dope'n'Stack! Also, live music from the Red Skunk Jipzee Swing Band, hand-crafted beverages from the award-winning Snake Oil Cocktail Company, and of course, no Piston Cloud bash would be complete without canapés, cakes, and other fine fare.

GET THERE AND BACK
Transit will be provided via trolley from the HP party to The Stingaree and back to the Manchester Grand Hyatt all night long.

Please note, an OpenStack Summit badge is required for entry (unless we've told you otherwise).

PLEASE RSVP HERE!

http://pistoncloud-sandiego2012.eventbrite.com

Currently we trigger a number of changes to Launchpad based on content of commit messages submitted to Gerrit: bug status changes in particular.

This has proven very useful but we can do better, in particular to drive blueprint status from commit messages. This may involve stricter rules (header-style data in commit messages ?) to be able to specify precise things like Related-Bug, Fixes-Bug, Finalizes-Blueprint, Partially-Implements-Blueprint, etc. This session will discuss if/how/what we should implement.

Time permitting, we'll look into other Gerrit improvements, like a LP-prioritized review list (think http://reviewday.ohthree.com/)

The goal of this blueprint is to implement a driver for cinder. This will allow to create volume in local storage and back up point-in-time snapshots of your data to Swift for durable recovery. This snapshots are incremental backups, meaning that only the blocks on the volume that have changed since your last snapshot will be saved.
Even though the snapshots are saved incrementally, when you delete a snapshot, only the data not needed for any other snapshot is removed. So regardless of which prior snapshots have been deleted, all active snapshots will contain all the information needed to restore the volume. In addition, the time to restore the volume is the same for all snapshots, offering the restore time of full backups with the space savings of incremental.

All in a word, our solutions is local storage + qcow2 image + dependent snapshot + swift. This is like http://wiki.cloudstack.org/display/RelOps/Local+storage+for+data+volumes, but we have incremental snapshot than cloundstack.

If you are interested in this topic, please read the full specification: http://wiki.openstack.org/LocalStorageVolume

As OpenStack continues to mature, it is increasingly important for the community to be proactive in improving security.  The OpenStack Security Group (OSSG) is a new effort led by Nebula and HP to bring together security professionals who can work to address this need.  Our goal is to create a group that complements the Vulnerability Management Team by  working to improve the security in each project's software architecture, contributing software to address security relevant blueprints and bugs, and providing cross-project security assessments.  This talk will introduce the OSSG and describe some of our early success stories, while starting a conversation about the best path forward for OpenStack security.

Come learn how to deploy OpenStack Swift from the ground-up. This will be a hands-on workshop where we learn by typing rather than just a lecture. Come with a laptop, or watch and learn.

In this workshop you will be walked through deployment and configuration of OpenStack Swift by the Swift experts at SwiftStack. We will guide you through the architecture of Swift while we walk through a step-by-step installation from the ground up.

In this workshop, you'll learn:
- Swift's architecture (The Ring, Zones, Partitions, Accounts & Containers)
- How to bootstrap a basic Swift installation
- The guts of how swift works
- Swift’s failure recovery mechanisms

Bring your laptop (with virtualization extensions enabled in the BIOS)
and we will provide a virtual machine image that will be used in the workshop.

Folsom is out, and a major new feature is the Quantum network

service.  In this session, the Quantum experts from Nicira/VMware will

walk you through a hands on deployment of Quantum along with other

core OpenStack components.

We will walk you through a 4 node OpenStack deployment (cloud

controller, network node, and two compute nodes) while demonstrating

the key new use cases that Quantum enables.  We will provide

infrastructure using VMs in our very own OpenStack cloud (yes, that's

running Quantum on Quantum!).  Alternately, with a bit more effort you

can use your own four Ubuntu 12.04 nodes if you want to keep the setup

running beyond the lab period.

We will also answer people's questions about more advanced scenarios

and provide experience from 6+ months of Quantum production

deployments on Essex.

Content will be scheduled on site.

We are migrating the translation hosting for OpenStack projects to Transifex. To make use of these translations two things need to happen.

1) Pull translations from Transifex and merge them into the git repositories for the OpenStack projects. Jenkins is currently doing this for Nova using two jobs. The first pushes updated translation template files to Transifex when changes are merged and the second pushes translation changes to Gerrit once a day. This is working for Nova but is not flexible enough for Horizon and OpenStack Manuals. Need to discuss the expectations of each project and ways to make the Jenkins Job interface common across projects (and if a common interface is not possible determine the subsets that are needed).

2) Once projects have included translations in the git tree/packages/etc the projects need to be able to consume these resources. I believe Horizon may be the only project currently capable of doing this. For example Nova assumes the translations are located in a system specific directory which is not the case if Nova has been installed from source. Need to determine how best to consume translation resources. Perhaps a module is needed in openstack-common.

Today, OpenStack has support for block-based storage and object storage, but there is no explicit support for file-based storage. For certain applications, file-based storage has significant advantages over block storage and object storage, and a large amount of existing software is designed around file-based storage. We've heard demand from the operator community for a common management interface for file-based storage, and ideally, a common management interface for storage in general. We're proposing adding management of CIFS and NFS file sharing to OpenStack, and we believe that extending Cinder is the most logical way to achieve this, both because Cinder is already in the business of managing storage devices, and because users don’t desire yet another management interface. NetApp has developed a prototype to this end. It includes extended APIs as well as an implementation of a driver backend for Cinder. We'd like to unveil our progress and discuss these with the developer and user communities to see if this approach makes sense, and achieve consensus on a path forward.

For many of the same reasons that software-as-a-service is catching on with enterprise buyers, delivering web services on top of infrastructure-as-a-service architectures is appealing to the SaaS developers. Operational agility, lower CapEx, and a broad array of tools and services are on tap that make both public and private IaaS clouds a great platform to build on.  But how do you do this securely, especially in the public cloud where you have no access to the network or hypervisor your servers are running in?

Furthermore, for many SaaS providers, the person charged with security considerations isn’t a CSO or IT specialist, but rather, a “DevOps” guru – someone with their hands in both development and operations. While the traditional security professional is focused on compliance and security rules, this new crop is more concerned with continuous development and high availability.

In this session, CloudPassage Chief Evangelist, Andrew Hay, will break down the top security considerations that are specific to the cloud and offer practical steps for securing cloud-based application development. He’ll also address the following:

• Why perimeter-centric and hypervisor-based security doesn’t work in the cloud
• Which components of cloud security are the customer’s responsibility and which belong to the service providers
• Which layers of security are the must-haves for those just getting started
• Why the cloud server itself has to be self-defending (i.e. if you put a server out into the cloud, usually it’s being attacked within 30 minutes)

Horizon is the framework for building the OpenStack Dashboard, but anyone can use it to build whatever dashboards they like.

This session will quickly recap the Essex "Building on Horizon" basics, dive into new features like Workflows, and leave plenty of time for people who are currently working on building new components for the dashboard to ask specific questions.

We'll have a look at the current state of our communication tools and community resources: mailing-lists, IRC channels, Forums, Q&A sites, Bugtrackers, and discuss which improvements we can push during the Grizzly timeframe.

OpenStack is a maturing force in the Cloud ecosystem and has significant security related “growing-pains”.  No environment is more challenging for deployment than a public cloud. Our business is to allow people to run code and place files deep within our infrastructure. With customer data touching most systems this can be a dangerous proposition in this talk I will discuss some of architectural hurdles we have had to deal with and the countermeasures we have deployed over and above what you’d expect to see in a private cloud. We’ll walk through a security wish list that would make OpenStack the most secure Cloud platform in the world and discuss how to move in that direction.

Are you interested in learning more about the Puppet deployment tools for OpenStack that have been written as a collaborative effort by Cisco, Redhat, Enovance, CERN, Cybera, Morphlabs, Rackspace, and PuppetLabs?

Would you like to better understand how they can be used to deploy a fully functional OpenStack environment?

If, so this talk is a great place to get started.

It will discuss the Puppet deployment tools for OpenStack, with a focus on how users can use them to quickly and reliably build out OpenStack environemnt.

This talk will cover the operations knowledge that you will need to successfully run and operate an OpenStack Swift cluster. This session is for operators who want tactical advice on the operational tasks needed to run a Swift cluster.

In this workshop we will:
- Walk through the procedure of handling a drive failure
- Adding additional capacity to a Swift cluster
- Running benchmarks to simulate workloads
- Tuning a Swift cluster
- Using transaction IDs in the logs to find an error
- Monitoring Swift-specific metrics and what they mean such as async pending, quarantined objects and replication statistics.

Come prepared with an already running Swift cluster, or watch and learn. The all-in-one cluster created in the “Deploying OpenStack Swift” workshop is fine for this purpose.

At the Folsom Design Summit we discussed the issue of reconciling the python dependencies of OpenStack projects and establishing a process for reviewing changes to our dependencies.

This session will discuss the progress on the topic since then and our plans for the Grizzly series.

A particular focus of the session will be how we can gather data from distros that will inform our decisions about proposed dependency updates.

In Folsom we got an initial quantum + horizon integration working. However, there's still a lot more we need to expose, but things that arrived late in Folsom (L3, floating IPs, provider networks) and things that will arrive in grizzly (security groups, load-balancing).

Akihiro will be organizing this session.

In a number of OpenStack projects, systems communicate via a messaging/RPC mechanism.  The safety and reliability of this mechanism is vital to the security of OpenStack clouds.  However, this messaging layer currently relies on implicit trust based on basic network connectivity.  In Grizzly, there exists a blueprint to add cryptrographic trust between systems.

Eric Windisch is currently developing this trust mechanism based on feedback from the Folsom design summit.  He will highlight the requirements of a trusted messaging system and the architecture of this solution.

A working group session wherein current plans for Grizzly can be shared and anyone can suggest new features or blueprints they think should be addressed for the OpenStack Dashboard.

With the membership to OpenStack Foundation taking over Launchpad as the main source of identification for OpenStack contributors, it's time to think about an identity system for the whole project.

Work is already in progress to integrate the CLA management in OpenStack Gerrit review system with the Members' database, in order to reduce friction during the onboarding of new developers, increase reliability of our Copyright License Agreement.

Mutuated from Google's way of managing CLA, OpenStack Gerrit will comply with Foundation's bylaws and make onboarding easier.

This session will illustrate the new process and report on its status. Anybody that will be hiring developers to work on OpenStack in the future should attend this session.

72% of the 21 million health care records that have been compromised in the United States since September of 2009 should have been trivially protected using comprehensive encryption of the data before being written to disk.  See: http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachtool.html

A busy OpenStack compute node might spin up hundreds or thousands of instances per day.  Ephemeral, block, and object storage -- each and every one of these should always be encrypted before being written to the underlying physical media.  Multiple excellent file and disk encrpytion solutions exist in Linux, such as eCryptfs and dmcrypt.  With cryptographic co-processor acceleration (AES-NI) available on most modern CPUs, encryption is essentially "free", having a negligle impact on practical performance.

A forward-thinking, security conscious OpenStack "Grizzly" release should lead the IaaS industry by example, encrypting all guest data.  Everywhere.

OK, so now you have a Swift cluster set up.  What are you going to do with it?  Sure, you could throw some backups in there and call it a day.  But Swift is capable of so much more when it can integrate more deeply with your app or infrastructure.

In this workshop, you'll use Swift to assemble Swinterest, a fully-featured web application that (if precedent is to be believed) is bound to garner you fame and fortune.  Along the way, we'll discuss:

• Where Swift fits into your application's architecture
• How to extend and customize Swift authentication
• How to support rich integration by developing custom Swift middleware
• Avoiding potential pitfalls with Swift during application development
• Come learn how to take your Swift installation to the next level!

juju Charm School is an event where a juju expert is available to answer questions about writing your own juju charms. The intended audience are people who deploy software and want to contribute charms to the wider devops community to make deploying in the public and private cloud easy.

There has been much progress since last ODS, we are now able to export environments from public clouds and import them directly into OpenStack clouds; we will be showing how we use juju to move deployments from cloud to cloud.

Attendees are more than welcome to:

• Ask questions about juju and charms
• Ask for help modifying existing scripts and make charms out of them
• Ask for peer review on existing charms you might be working on
• Though not required, we recommend that you have juju installed and configured if you want to get deep into the event

Content will be scheduled on site.

OpenStack as a whole performs innumerable actions asynchronously, and in general leaves other projects in the dark as to those goings on. This affects Horizon especially, but enabling one project to learn about events in another project would be useful in myriad ways. For example:

A tenant is deleted in Keystone; instances are subsequently orphaned and left running in Nova, images are orphaned in Glance, etc. If Keystone sent out a signal when that project were deleted, a concerted cleanup action could take place throughout the entire system...

The Folsom cycle was the second cycle where we maintained a stable branch for the previous release. We will look back over the stable/essex maint efforts and identify successes and failures.

The stable-maint process still has some rough edges and so we will discuss ideas for improvements, ideally setting some specific goals for stable/folsom maintenance.

The lack of quality sources of entropy in cloud computing environment is a problem that has gained considerable attention this year, and has consequences that permeate the entire fabric of cryptography in enterprises.  Virtual machines typically lack physical hardware devices that provide random noise, such as microphones, wireless adapters, or serial bus interrupts.  Monitoring network interrupts generated by traffic (such as ARP requests) is one of the few sources of unpredictable input in cloud networks, but even that traffic can be somewhat scarce in some networks.  Without sufficient randomness, servers routinely generate vulnerable TLS certificates and predictable RSA/DSA private SSH keys.

In this session, we’ll discuss a draft RFC, proposing a network protocol for peer-to-peer exchange of randomness, review an open source implementation of that protocol in C, consider the results of some entropy quality tests, propose its inclusion as an OpenStack Incubator project. We’ll consider the opportunity for collaboration among cloud guests to interchange randomness in ways that defy predictably from outside observers, internal users, as well as offline users.

We'll also discuss other potential solutions to the problem, such as passing through Intel's new DRNG to guests, extending Nova to seed guests with better entropy through a virtio or disk device, as well as other suggestions brought by attendees.