OpenStack Kilo Design Summit

Ceph is one of the most popular storage option for OpenStack installations. We will use this time and space to discuss future Ceph enhancements related to the OpenStack Kilo release.

OpenDaylight is the leading open source platform for Software Defined Networking (SDN). Currently there is an ML2 plugin for OpenDaylight within Neutron. Significant work has already been done to show the benefits of managing virtual and physical network elements via OpenStack through the OpenDaylight controller. In addition, service function chaining, group-based-policy, security-groups and distributed virtual routing are all development activities that span both OpenStack and OpenDaylight and deeper collaboration on these topics will significantly benefit both projects.

The bulk of the time will be used in discussion of the above activities and brainstorming plans for work in Kilo and Lithium (OpenDaylight’s next release) to improve the network programmability available to OpenStack through the use of OpenDaylight. Additional technical topics for discussion will also be solicited from members of the audience and pursued as time permits.

Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.

Ansible’s goals are foremost those of simplicity and maximum ease of use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with an accelerated socket mode and pull modes as alternatives), and a language that is designed around auditability by humans – even those not familiar with the program.

Ansible is a popular tool for deploying and managing OpenStack, as well as for deploying and managing workloads run on OpenStack.

There are three areas of interest in the intersection of ansible and OpenStack.

- deploying OpenStack with ansible
- OpenStack support in ansible/managing workloads on OpenStack with ansible
- use of ansible in OpenStack itself

All three are worthy topics, but the second two are potentially more useful to discuss in person. Namely, what, if anything, does the OpenStack community want to do in terms of ensuring a good enduser experience for ansible users on OpenStack, and where, if anywhere, can ansible be useful inside of OpenStack.

Cloud Foundry BOSH Cloud Provider Interface or CPI provides implementation and is designed to manage the deployment of Cloud Foundry on top of OpenStack.

In this session we will discuss what other enhancements could be made to the CPI to automate and further enhance Cloud Foundry deployments on OpenStack.

The puppet-openstack modules on StackForge are an effort to address both the deployment and long-term configuration and maintenance of an OpenStack system.

During this session, we will create a roadmap for the next six-month release cycle, addressing issues including:

* Automated integration testing
* Features of the openstacklib and openstack_extras modules, such as HA support and other common library resources
* Review of core members
* Composition module
* Release management and namespace
* Identifying valuable platform integrations beyond Puppet modules
* Any other topics proposed by the community.

Solum allows cloud operators to add customizable CI/CD Pipeline capability to applications so they can be built, tested, and run on OpenStack clouds. This design session will start with a Solum demo, then move on to planning feature development for the OpenStack Kilo release.

Presentation of how Chef can be used to manage OpenStack deployments. Topics include:

* The future roadmap
* Community Concerns and Questions
* Q & A 

Group Based Policy (GBP) is a StackForge project that provides declarative abstractions for achieving scalable intent-based infrastructure automation. GBP was originally conceived in the Atlanta Design Summit and has since evolved to its current state where it can be put into the hands of early adopters.

Currently GBP complements the OpenStack networking model with the notion of policies that can be applied between groups of network endpoints. As users look beyond basic connectivity, richer network services with diverse implementations and network properties are naturally expressed as policies. Examples include service chaining, QoS, path properties, access control, etc. GBP thus allows application administrators to express their networking requirements using a Group and a Policy Rules-Set abstraction. The specifics of policy rendering are left to the underlying pluggable policy driver. The GBP model also inherently supports constructs that makes it easy to abstract and consume complex network service chains and graphs.

This model of defining groups of entities and providing abstractions to capture user intent in the form of a policy language is being extended to the entire infrastructure in general. In this session we will review the GBP implementation for Juno, discuss the roadmap for Kilo, and also share pointers on how new participants can contribute to the project.

Wiki page: https://wiki.openstack.org/wiki/GroupBasedPolicy

Poppy: An Open API for CDN Provisioning

OpenStack operators have many choices when incorporating a Content Delivery Network (CDN) into their infrastructure -- the CDN marketplace has both tried-and-true vendors and up-and-coming upstarts with innovative new features.

But these vendors often have highly-customized and proprietary provisioning APIs. This can be problematic when an operator wishes to support multiple providers -- or swap out one vendor for another. And these challenges spill over to developers who become forced into codifying the CDN instructions for multiple vendors into their applications.

Poppy aims to solve these challenges. Written as a modular, vendor-neutral API, Poppy incorporates a driver-based model that wraps provisioning instructions for all CDN vendors that support it. Application developers can write their code once, and Poppy will handle all the requisite translations behind-the-scenes.

Poppy's success depends on active and engaged participation by CDN Providers. Much like Cinder, Manila, and Designate use a driver-based approach to connect multiple vendors to a consistent API, Poppy will do the same for CDN Providers.

This design session will discuss with the openstack community and CDN providers on how to coalesce on the ideal vendor-neutral API, and lay the implementation plans for the platform and driver development in preparation for OpenStack Kilo.

As you'll see in the links below, multiple CDN providers are already engaged, and significant design, documentation, and implementation work is underway.

http://poppycdn.org/
https://wiki.openstack.org/wiki/Poppy
https://github.com/stackforge/poppy

MagnetoDB is a key-value storage service, designed and developed as an OpenStack service. It provides a similar storage as a service model to OpenStack Swift or Cinder, providing a data path ReST API for easy data storage and retrieval. It uses OpenStack Keystone for authorization and enforces secure multi-tenancy using OpenStack's model of domains and projects. MagnetoDB leverages OpenStack Notifications for integration with billing and monitoring systems.

The overview of project achievements during Juno cycle will be presented. The roadmap for Kilo will be discussed, and we will be diving into the design and implementation details of major features.

(Speakers: Shuo Yang, Weidong Shao)

In this session, we will

• quickly demo (10 mins) of OpenStack deployment with Compass and explain what happened behind the scene.
• come and play compass with us, and we will stand up an OpenStack on your a Linux/Mac/Windows box - we will have a feature collection and design brainstorming session. Specifically, we would like to share the following design topics
• meta-data description of a target system (this is to enable existing Cookbooks/Manifests/Playbooks to be plugged into Compass)
• exploring the hardware management engines (we plan to use existing frameworks such as xCat, Ironic IPA, ONIE)
• we would like hear your input.

Please provide your interest for discussion in this session at design session Etherpad entry (https://etherpad.openstack.org/p/compass_design_collections )

Murano Project introduces an application catalog, which allows application developers and cloud administrators to publish various cloud-ready applications in a browsable categorized catalog. It may be used by the cloud users (including the unexperienced ones) to pick-up the needed applications and services and composes the reliable environments out of them in a "push-the-button" manner.

In this session we will briefly overview results of Juno release cycle and focus the discussion on our goals for Kilo release cycle.

Session etherpad: https://etherpad.openstack.org/p/kilo-murano-design-session

Design sessions with Neutron GBP, ODL, Swift, Congress, Nova, and Heat.