OpenStack Mitaka Design Summit: Full Schedule

11:15am JST

Ops:Operator Feedback into Development Priorities for OpenStack Projects

The Product WG recently asked a majority of the PTLs for a list of questions that would provide necessary information to make design decisions and to better understand how the services are being used in OpenStack cloud deployments. While the full list of questions is too long for a 40 minute session, we would like to spend time on 10 or 11 of these questions with you, the operators, so that we can take this feedback directly to the project teams. The projects that will be discussed are Nova, Cinder, Glance, Heat, Horizon, Triple O, Ironic, Kolla, and Keystone. Thanks in advance for your help!

https://etherpad.openstack.org/p/TYO-ops-feedback-into-PWG

Note: This is an interactive discussion for the ops community. No presentations will be given. Please come armed with your knowledge, bug links and be ready to pitch in :)

Moderators

Shamail Tahir

Offering Manager, IBM Private Cloud and OpenStack Initiatives, IBM

I am an Offering Manager for OpenStack Initiatives at IBM Cloud and enthusiastic about technology. In my current role, I am focused on open-source and product strategy. I have been in the OpenStack community since 2013 and I am currently participating in the Product, Enterprise... Read More →

Tuesday October 27, 2015 11:15am - 11:55am JST
Ohka room

Ops

12:05pm JST

Ops: Major Liberty Operator Issues

Liberty Release Notes: The missing manual

https://etherpad.openstack.org/p/TYO-ops-major-liberty-issues

Note: This is an interactive discussion, no presentations will be given.

Moderators

David Medberry

Lead Engineer, OpenStack DevOps, Charter Comm

Open source advocate for 15+ years.OpenStack developer, deployer since 2011...OpenStack Community leader for 4+ years.Formerly doing cloud and open source for Canonical (Ubuntu) and HP, currently doing OpenStack at Charter Communications.Known to launch flying discs at anyone attending... Read More →

Rainya Mosher

Tuesday October 27, 2015 12:05pm - 12:45pm JST
Ohka room

Ops

2:50pm JST

Ops: Lightning Talks

Come and see experienced ops folks give Lightning Talks! Basically a 5-10 minute talk about something cool. Maybe about your deployment, architecture, a nice feature, etc.

https://etherpad.openstack.org/p/TYO-ops-lightning-talks

Moderators

Mike Dorman

DevOps Engineer, SendGrid

A 15-year systems engineering veteran focused on cloud architecture, site reliability, automation and infrastructure design in service provider and enterprise environments. I am knowledgeable in the full deployment stack, from data center, network and hardware configuration to application... Read More →

Tuesday October 27, 2015 2:50pm - 3:30pm JST
Ohka room

Ops

11:15am JST

Ops: Deployment Tips

Bring your tips, questions, comments, and dreams. We'll have a discussion where we share what's worked for us, ask what's worked for other people, and what could work better for everybody.

The output of this session should be a set of tips and tricks that could be massaged into a SuperUser article to share with a wider audience.

https://etherpad.openstack.org/p/TYO-ops-deployment-tips

Note: This is an interactive discussion, no presentations will be given.

Moderators

Jesse Keating

OpenStack Engineer, Blue Box

Jesse Keating is an OpenStack Engineer at Blue Box. He has been a part of the Linux community for over 13 years, as a user, contributor, instructor, author, and evangelist. A believer in Continuous Integration and Continuous Delivery.

Wednesday October 28, 2015 11:15am - 11:55am JST
Ohka room

Ops

12:05pm JST

Ops: Networking

https://etherpad.openstack.org/p/TYO-ops-networking

Note: This is an interactive discussion, no presentations will be given.

Moderators

Edgar Magana

Software architect, Salesforce

Edgar is an emerging leader who has specialized in Cloud Computing, Network Virtualization, Software-defined Networking (SDN), Network Functions Virtualization (NFV), OpenFlow and OpenStack. He has developed excellent software development skills and outstanding customer and business... Read More →

Wednesday October 28, 2015 12:05pm - 12:45pm JST
Ohka room

Neutron Ops

2:00pm JST

Ops: Lightning Talks

Moderators

Mike Dorman

DevOps Engineer, SendGrid

Wednesday October 28, 2015 2:00pm - 2:40pm JST
Ohka room

Ops

2:50pm JST

Heat: Issues from deploying very large stacks

https://etherpad.openstack.org/p/mitaka-heat-large-stacks

During this session we want to discuss issues which happens during creating large stacks:
* token timeouts
* nova limitations (ResourceGroup batching should be ok for this - status)
* polling services during check_complete
* heat limits (resources, template size)
* validation for large stack may take a lot of time (looks like was fixed by caching mechanism)
* another part - we wait validation of all template, before sending response about starting creation (may be make validation separate?)

Wednesday October 28, 2015 2:50pm - 3:30pm JST
Ohka room

Heat

format json

3:40pm JST

Heat: User/ops session for summit

https://etherpad.openstack.org/p/mitaka-heat-user-ops

* pain points.
* feature requests.
* app catalog: what templates do users need in the app catalog, (should upstream Heat team need to be involved in this)?
* "Implement SecurityGroupIngress and SecurityGroupEgress" blueprint is very important. Could be in high priority ?

Wednesday October 28, 2015 3:40pm - 4:20pm JST
Ohka room

Heat

format json

4:40pm JST

Swift: Ops feedback session

This session is designed to listen to those who are deploying Swift in production. We want to hear pain points, ideas for improvements, and success stories.

Wednesday October 28, 2015 4:40pm - 5:20pm JST
Ohka room

Swift Ops

format json

5:30pm JST

Swift: Inbound cross-project issues

This session is to cover some issues in Swift that have cross-project impact--specifically those cross-project issues that are inbound to the project (external things Swift needs to address) rather than outbound (changes in Swift that require other projects to change).

Topics to address:
* RBAC with oslo.policy
* dependencies and requirements.txt

Wednesday October 28, 2015 5:30pm - 6:10pm JST
Ohka room

Swift

format json

9:00am JST

Magnum: Storage Features

OpenStack already has a variety of storage capabilities offered through Cinder, and Manila. In the Mitaka release, we plan to embark on an adventure to add new storage integration features into Magnum to allow these resources to be utilized from your containerized applications. Come to this session to affirm our current priorities for adding storage features. For example, we would like to add support for cinder volumes with filesystems automatically created by Heat/Magnum that are added to the host, and shared with the container by using "-e" hints in Docker that can be used in combination with "-v" flags with Docker to conenct a new/existing volume to a particular container. We would also like to leverage Manila to expose a given filesystem to multiple containers so they can have a consistent filesystem view across multiple containers on multiple hosts.

Thursday October 29, 2015 9:00am - 9:40am JST
Ohka room

Magnum Manila Cinder

format json

9:50am JST

Magnum: Netwoking: Past, Present, and Future

The first networking solution for Magnum used a simple flannel overlay network with our Kubernetes bay. Since then, Magnum and Neutron contributors ahve been working together to design Kuryr, which acts as a libnetwork driver for Docker that connects docker containers to your Neutron networks. This way it can work with your existing SDN. Magnum Also has a new networking specification for that is designed to work with exising Bay types, as well as new ones that are not based on Docker containers. In this session we will outline Magnums goals and non-goals for networking, and explain our point-of-view for how OpenStack cloud resources, including Magnum bays, should be able to share common networks easily.

Thursday October 29, 2015 9:50am - 10:30am JST
Ohka room

Magnum Neutron

format json

11:00am JST

Heat: Composition improvements

https://etherpad.openstack.org/p/mitaka-heat-composition-improvements

Looking to clarify objections to the proposal to enhance HOT to support an optional capabilities annotation,
which is similar in concept to the TOSCA substitution_mapping definition.
This would move us closer to being a TOSCA capable orchestrator, and enable more control of the already
powerful composition capabilities exposed via our resource_registry interfaces.
Spec: https://review.openstack.org/#/c/196656/

This then raises some interesting questions around parameter interfaces (and resource_registry interfaces)
If you expect to have your heat templates widely consumed, the parameters inteface is effectively your "public API".
* How do you deprecate or rename anything, ever (we need a user-visible warning mechanism, combined with some sort of deprecated tag similar to how oslo config deprecation works?)
* Could we add some way to define cross parameter constraints (or multiple conflicting parameter_groups), such that you could e.g group certain parameters as deprecated and/or conflicting with some others?
* Related to the cross-parameter constraint but more general than deprecation/conflict, could we have e.g defaults defined derived from another parameter, or constraints (such as min/max) derived in a similar way?
The idea with all of this is to enable a more complete user-visible schema to be defined, and to enable that to evolve over time when those writing and consuming the templates are not the same folks.

Thursday October 29, 2015 11:00am - 11:40am JST
Ohka room

Heat

format json

11:50am JST

Heat: Complete heat support in python-openstackclient

https://etherpad.openstack.org/p/mitaka-heat-openstackclient

Lets aim for a python-heatclient 1.0.0 which has full support for all heat commands that work on python-openstackclient.
Topics to cover include:
* Namespacing top-level commands from plugins are uncoordinated. Other than 'stack', what other top-level commands will we claim?
* There are lots of commands to port over, this would be best shared by multiple developers, look for volunteers
* What higher-level commands are missing which would actually help users manage complex stacks (eg, debugging failed resources in deeply nested stacks)

Thursday October 29, 2015 11:50am - 12:30pm JST
Ohka room

Heat

format json

1:50pm JST

Magnum: Bare Metal Bays

Magnum is designed to offer a choice of compute instance types to run bays, including Virtual Machines, Bare Metal, and even Containers from libvirt/lxc. Our main templates create VM instances, and we have templates that are designed to work with ironic bare metal instances as well. there are some challenges with bare metal instances that make it more difficult for them to securely join Neutron networks and use Cinder storage volumes. This is because working with these services requires that the control plane can be accessed by the host, which it normally can not be. In this session we will highlight these differences and explain which issues are unique to irnoic, and which are challenges for Magnum.

Thursday October 29, 2015 1:50pm - 2:30pm JST
Ohka room

Magnum Ironic

format json

2:40pm JST

Magnum: Getting Started for Developers and Sysadmins

Overview for developers and system administrators/engineers planning to begin with Magnum for the first time. In this session, we will identify all the useful resources for you about where to find documentation and guides, video sessions about Magnum, where to find the developemnt team to interact with them, how to join our community, where to file bugs, and and how to contribute new features and improvements. We will also poll the audience for your input on ways that we could make Magnum easier to work with, and more friendly for newcomers.

Thursday October 29, 2015 2:40pm - 3:20pm JST
Ohka room

Magnum

format json

3:30pm JST

Magnum: Scope of Magnum

Today Magnum serves as an integration point to allow OpenStack cloud operators to offer a containers-as-a-service solution to their cloud users. It allows the creation of Bays, which are groupings of Nova instances that run a container orchestration engine (COE) such as Docker Swarm, Kubernetes, or Apache Mesos. This gives users a choice of what type of container environment to start up. We have intentionally avoided the creation of new container technology, such as container formats, runtime environments, or the creation of elaborate openstack-specific tools for interacting with containers, holding a strong preference for allowing the use of native APIs and tools. Let's discuss our current point of view, and true that up with your expectations from OpenStack. Should our scope be expanded? If so, what should that new scope include, and why?

Thursday October 29, 2015 3:30pm - 4:10pm JST
Ohka room

Magnum

format json

4:30pm JST

Keystone: libraries

https://etherpad.openstack.org/p/keystone-mitaka-summit-libraries

Keystone Libraries

Keystonemiddleware
- Tokenless auth support?
- Can be done with strong authentication
- Needs an API that returns the same data as token validation that can be called by service users
- Federation mix and match support?
- Change KSM to use KSA

KeystoneAuth
- Ready for primetime
- Merge with openstackclient
- Make version discovery more LB friendly
- may need a configurable way to disable version discovery

Keystoneclient
- When to do a 2.0 release that removes CLI/Auth/Middleware?!

Thursday October 29, 2015 4:30pm - 5:10pm JST
Ohka room

Keystone

format json

5:20pm JST

Keystone: cross-project

https://etherpad.openstack.org/p/keystone-mitaka-summit-x-project

Cross-Project

- Let's finally kill off the discussion of LDAP user list, and settle with listing role assignments instead! (How about lets fix role assignments too?!!! Anybody try "openstack role assignment list" command and actually *like* what it displays? :))
- Many stakeholders have problem with the ephemerality of the users - they need to be able to trace users actions for instance for billing and security. Keystone has native support for CADF events (thanks stevemar), but that's just a half of the solution as nothing consumes them by default. We should think on a solution that will allow deployers to track ephemeral users and make it available in a default DevStack installation. The first shot is Ceilometer/Gnocchi. +1 (henrynash)
- Automatic provisioning of projects when Federated users first log in:
- Notification driven

Thursday October 29, 2015 5:20pm - 6:00pm JST
Ohka room

Keystone

format json