We have some common cross project concerns that fall by the wayside when we don't pull the whole community together to focus attention on them. Things like functional testing, upgrades, interaction with DefCore, recruiting more core reviewers, and application of the logging guidelines. Let's sit down together and pick one or two "themes" for this cycle for all projects to be considering as background for their project-specific goals.
How can we make log messages and the log library both flexible enough and standard enough that the library meets the needs of projects without imposing project specific formats into the log stream.
Progress has been made, but let's put together the plan to keep this moving forward for Mitaka.
The Service Catalog is an incredibly useful concept in the keystone project, which is substantially underused today. We had an exploratory session in Vancouver to move the ball forward, which led to a cycle of building up context on the problem. The Tokyo session will be presenting an path forward to a Service Catalog: TNG which will be a set of steps we can move forward on. It will quickly touch on items that seem uncontroversial, and then get eyes on some of the potentially more controversial pieces to come up with the best approach forward.
The base line cross-project spec for this work is evolving here: https://review.openstack.org/#/c/181393/.
Moderator: Sean Dague Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-service-catalog-tng
Tuesday October 27, 2015 11:15am - 11:55am JST
Royal room
The Service Catalog is an incredibly useful concept in the keystone project, which is substantially underused today. We had an exploratory session in Vancouver to move the ball forward, which led to a cycle of building up context on the problem. The Tokyo session will be presenting an path forward to a Service Catalog: TNG which will be a set of steps we can move forward on. It will quickly touch on items that seem uncontroversial, and then get eyes on some of the potentially more controversial pieces to come up with the best approach forward.
The base line cross-project spec for this work is evolving here: https://review.openstack.org/#/c/181393/.
Moderator: Sean Dague Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-service-catalog-tng
Tuesday October 27, 2015 12:05pm - 12:45pm JST
Royal room
At the ops midcycle dhellmann talked with Chris Hoge about some of the issues the DefCore team is encountering with establishing the correct versions of APIs, with changes to APIs, and with the tests for our APIs. This led to the mailing list discussion about the Glance project priorities for Mitaka. A design summit session would be a chance to identify problem areas and work on solutions to ensure that all projects fully understand how they can and should be making changes while maintaining compatibility testing.
We should also work on improving communication between the contributor community and the DefCore committee. dhellmann also spoke with zehicle, and he's planning to be present at the session to help with that so when DefCore identifies potential issues, they can feed back into the project teams and vice versa.
During the Liberty cycle we introduced a number of governance tags that can be applied to project teams and deliverables, in an effort to provide information about what we produce in the big tent and help our users navigate that ever-growing set of projects.
This session will look back at the tags we introduced, and will brainstorm the next step. The 'next-tags' workgroup at the Technical Committee already has a few things in the pipe (tags to describe which projects have a horizon panel, or heat resources, or devstack plugins, tags to describe the QA being done...), but what are we missing ?
There is an idea to create a sub team in Large Deployments Team ( https://wiki.openstack.org/wiki/Large_Deployment_Team ) focused on identifying OpenStack performance issues. We would like to work on their solutions and sharing knowledge about performance and scalability researches done by different companies.
It will be a good idea to gather together and finalise Performance team mission, #1 issues to work on, and share experience.
Moderator: Dina Belova Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-performance-team-kick-off
Tuesday October 27, 2015 2:00pm - 2:40pm JST
Royal room
Recently the TC approved a "follows standard deprecation" tag which tried to reasonably capture what projects were doing. That coincided with the removal of v1 cinder API from devstack, which didn't really go so well, and had to be reverted.
This session will be a bit of a post mortem on what went wrong there, and how we do this less wrong in the future. The expected output is a plan for how cinder (and other projects) can reasonably remove their very old APIs, what's expected there, and what additional guidance we should provide in our standard-deprecation tag.
Also we will be talking about libraries and clients and their deprecation story.
Moderator: Sean Dague Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-standard-deprecation-policy
Tuesday October 27, 2015 2:00pm - 2:40pm JST
Crown room
We need to all get together and figure out and understand what the issues with DLM are, what lock management features have been replicated by many various projects and what something like zab (zookeeper), raft (consul, etc.d, ...), paxos (?), or other variant can offer to openstack and its diverse set of projects.
Connected to: https://review.openstack.org/#/c/209661/
Related to:
- https://etherpad.openstack.org/p/servicegroup-refactoring - http://lists.openstack.org/pipermail/openstack-dev/2015-September/075267.html - http://lists.openstack.org/pipermail/openstack-dev/2015-July/070683.html - (and many others)
Why: without understanding the problem, and what the solutions are, what the various offerings provide... we have no hope in fixing it, so let's work on that.
Expected result: understanding what a DLM is, what some of the common patterns they offer are, and in my happy world/vision agreeing that a DLM solution (ideally one, not many) will help openstack(s) future (in terms of long-term health, operability, features, and so-on); reduce common code that is replicated similar features and possibly bring world peace.
Moderator: Mike Perez Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-dlm
Tuesday October 27, 2015 2:50pm - 3:30pm JST
Crown room
* (Very) short status of work done in Liberty? * DevStack: install clients and servers with Python 3 and run functional tests with Python 3 * Wiki: https://wiki.openstack.org/wiki/Python3 * Define goals for the Mitaka release. Example: Functional tests of Neutron and Heat must run on Python 2 and Python 3 on the gates.
Moderator: Victor Stinner Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-python-3
Tuesday October 27, 2015 2:50pm - 3:30pm JST
Amethyst room
When devstack sets up the service users, some of them get the 'service' role, which is great, but nova and neutron get the 'admin' role, which is not great. Also, the docs seem to say that all the service users should have the 'admin' role.
We need a cross-project initiative to figure out what the operations are that the different services need to do (e.g., what does neutron need to do on nova), update the docs with the correct info so that deployers can set up their system in a secure way, update the default policies, and change devstack to do the role assignments for testing.
We need to all get together and figure out and understand what the issues with DLM are, what lock management features have been replicated by many various projects and what something like zab (zookeeper), raft (consul, etc.d, ...), paxos (?), or other variant can offer to openstack and its diverse set of projects.
Connected to: https://review.openstack.org/#/c/209661/
Related to:
- https://etherpad.openstack.org/p/servicegroup-refactoring - http://lists.openstack.org/pipermail/openstack-dev/2015-September/075267.html - http://lists.openstack.org/pipermail/openstack-dev/2015-July/070683.html - (and many others)
Why: without understanding the problem, and what the solutions are, what the various offerings provide... we have no hope in fixing it, so let's work on that.
Expected result: understanding what a DLM is, what some of the common patterns they offer are, and in my happy world/vision agreeing that a DLM solution (ideally one, not many) will help openstack(s) future (in terms of long-term health, operability, features, and so-on); reduce common code that is replicated similar features and possibly bring world peace.
Moderator: Mike Perez Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-dlm
Tuesday October 27, 2015 3:40pm - 4:20pm JST
Crown room
Over the last cycles we realized that the OpenStack Way, our common culture and reference points, was no longer naturally transmitted to newcomers via oral tradition. To start solving that problem, during the Liberty cycle the Technical Committee formed a workgroup to document our common culture. The result is the Project Team Guide, which can be found at:
http://docs.openstack.org/project-team-guide/
What's the next step there ? Where can we improve that ? Any new chapters to suggest ? Should we further discontinue the wiki ? How to improve publicity around that guide ?
We also started work to make keeping up with what's happening in OpenStack development easier, including summaries of important threads from openstack-dev. In this session we'll brainstorm how to further improve on that.
When Keystone was first incubated, roles were global. Roles were later scoped to projects, but policy files have not kept up with this,. The Goal of the Dynammic Policy discussions has been to make policy better match the requirements of scaling delegation decisions in cloud, but have thus far been limited by the static nature of policy files. Lets fix this.
One of the biggest problems is global Admin; a user assigned admin in any role gets admin everywhere. We can fix parts of this in Keystone, but, again, it needs a crossproject effort to wipe out global admin. Blueprints: keystone/dynamic-policies-delivery
Moderator: Adam Young Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-global-admin
Tuesday October 27, 2015 3:40pm - 4:20pm JST
Royal room
Multinode testing is something we have all wanted for a long time. We have had it for a while now but its applied inconsistently. We should figure out where this fits in our testing setup. Do we replace single node default tests with multinode tests? Do we use this only for testing special things like DVR and live migration?
The test env can be complicated and adding more nodes raises the bar on reliability requirements. There is a lot to consider here and likely need broad input to determine what the future is with multinode testing.
Nova has spent the last few years learning how to do live upgrades, developing technology and best practices along the way. Other projects are starting to identify upgrades as a key feature requirement. We should have a cross-project session dedicated to sharing the challenges and strategies learned over the years.
I propose a session where we provide a short background of nova's journey, identify the key challenges, and then quickly move to Q&A/discussion with people working in other projects trying to actually move the ball forward. Background Reading: Upgrades in Nova: The Details - http://www.danplanet.com/blog/2015/10/05/upgrades-in-nova-the-details/ Upgrades in Nova: RPC APIs - http://www.danplanet.com/blog/2015/10/05/upgrades-in-nova-rpc-apis/ Upgrades in Nova: Objects - http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/ Upgrades in Nova: Database Migrations - http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/
The process around cross-project specs is lengthy and painful. The cross-project meeting doesn't work that well. We should brainstorm how to improve those for the Mitaka cycle.
Moderators: Thierry Carrez / Mike Perez Etherpad: https://etherpad.openstack.org/p/mitaka-crossproject-comms
Tuesday October 27, 2015 4:40pm - 5:20pm JST
Crown room
It would be helpful to operators of OpenStack clouds if some set of configuration for OpenStack services were reconfigurable on the fly.
At a minimum, we could start with log level, allowing operators to move from INFO to DEBUG in response to issues, then back to INFO once the data needed has been acquired. Ideally, services would notice config file changes and manage themselves entirely without requiring a restart.
Note that this might benefit from sectioning the config file into "dynamic" and "require restart" to help operators know what setting can be changed on the fly. Note that this might benefit from sectioning the config file into "dynamic" and "require restart" to help operators know what setting can be changed on the fly.
The keystone has been implementing federation support for a few releases now. We are at the stage where other projects, such as: horizon, chef, puppet, ansible, and the CLIs have begun to support it as well. Furthermore, the topic of using services from different clouds (mix and match federation) have begun to arise, in this scenario a user could create a VM from one cloud, while getting images and volumes from a service provider cloud.
Moderator: Steve Martinelli Etherpad: https://etherpad.openstack.org/p/mitaka-cross-project-keystone-federation-next-step
Tuesday October 27, 2015 5:30pm - 6:10pm JST
Crown room
The dynamics of our development system (where the bulk of contributions come from companies selling OpenStack consulting) naturally results in the medium-to-large private cloud use case to be well covered.
However, the two ends of the use cases spectrum are: - small OpenStack deployments in labs for technology evaluation or teaching in universities - very large scale public clouds with highly-dynamic workloads
I would argue that in order for OpenStack to succeed, we *all* need both those use cases to be well covered. We need new users and contributors and need to improve on the small lab experience. We need to facilitate the emergence of very large public cloud providers so that workloads can be easily burst to something with near-infinite capacity. However both ends of the spectrum are not naturally served by our developers demographics, and need some extra help from all of us, project contributors, to be covered.
This session is about how we, cross-project, can do a better job at serving those two extreme use cases.
