OpenStack Mitaka Design Summit

https://etherpad.openstack.org/p/TYO-ops-quotas-and-billing

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 :)

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

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

https://etherpad.openstack.org/p/TYO-ops-user-commitee-meta-session

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

https://etherpad.openstack.org/p/TYO-ops-infrastructure-containers

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

https://etherpad.openstack.org/p/TYO-ops-end-user-containers

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

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

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

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

Tokens
- Criteria for getting fernet to be default?
- fernet in tempest tests and devstack
- More documentation - there's a lot of misconceptions on fernet tokens (ie, they have to be simultaneously rotated on all nodes).
- Guidelines on how often to rotate
- fernet token validation performance improvements
- Gating of PKI deprecation on Fernet

Tokenless Auth
- Criteria for getting tokenless auth to be default in devstack?
- Certs instead of service accounts (wishlist)

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

hierarchical multitenancy

- Suggestion: To aid the review of these patches, we should implement this in two phases:
- Phase 1: Replace the unerlying implementation of domains with top level projects acting as domains
- Phase 2: Support a hieracrchy of projects acting as domains
- feature branch

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

Policy

We made some head-way, what's the next logical step?
- Distribution of policy files from Keystone server: Either we should use the policy backend or deprecate.
- Management of Roles
- Merge role ID and Role name
- Get a standard base set of roles
- Idea 1: Virtual roles (aka role-groups): This proposes "management roles" to be created that map to "policy roles" (i.e. those that appear in a policy file)
- This is composed of three distinct things:
- Role inference (assigning one role grants a second)
- Hidden roles (an assiged role that does not show up in a token)
- Role namespaces
- Idea 2: Implied roles: This proposes a role hierarchy of policy roles
- Virtual only misses the ability to compose permissions. We were going to push this on the POlicy side, but we can start on the token issuing
- Bug 968696 (Admin not properly scoped)
- How to handle APIS not scoped to projects
- Roles for management of remote services like "add hypervisor"
- How to delete a resource where the project has been deleted

Currently Nodepool is limited to managing whatever it can boot through the Nova API, which for most public service providers is still just virtual machine instances. This is insufficient for some kinds of testing (for example, those which need access to bare metal servers), and overkill for others (simpler jobs like unit testing and static analysis may work just fine in a container). Let's discuss a plug-in framework for achieving this in Zuul v3.

https://etherpad.openstack.org/p/mitaka-infra-nodepoolplugins

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

deprecations

- ldap assignment driver?
- ldap write support? (Also, python3-ldap instead of python-ldap)
- eventlet?
- v2.0 API?!?!
- PKI and/or PKIz
- PKI can go once we have Fernet as default. Focus should be on making Fernet as robust as possible.

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

Federation

- With keystoneauth merged with openstackclient we will be able to finish client side (esp k2k)
- Service Providers endpoint filtering - today every user gets set of enabled service providers in the token response. We should be able to limit it per user/scoped project/scoped domain etc - https://review.openstack.org/#/c/188534/
- Native tracing of the ephemeral users - please see section
- keystoneauth1.session.Session() should allow for getting remote-clouds Session() objects basing on K2K. Something like sp_session = session.Session().get_remote_session('sp1')
- What's the best way to have configurations for multiple clouds and easily switch between them - each cloud should have at least project/domain id to scope to. Is it os-cloud-config?
- Troubleshooting and debugging support
- Mix and Match federation
- What was demo'ed in Boston from the folks from MOC
- Use local nova, but get images from a remote SP glance
- Use local swift, but sign objects from a remote SP barbican
- LDAP "federation" - we should formally support use of an Apache lookup module for LDAP, then allow mapping into keystone groups via the regualar federation mapper
- We need SSSD/identity_look to be domain-friendly. i.e. pass down both DN and domain
- deprecate ldap identity(henrynash) Not for a looooong time, my friend, but one day
- Mapping engine - relies on the string substitution and concatenation - this stops us from fixing few open bugs (https://bugs.launchpad.net/keystone/+bug/1401057). Are we happy with the engine for now so there is no urgent need for rewriting it? Are we relatively happy with that and some work would be welcomed? Do we need more intelligent DSL kind of language? Do we miss anything (in terms of functionalities)?
- Pre-canned mappings? the K2K mapping and Tokenless Auth mapping are for the most part, very similar looking.

OpenStack continues to accumulate new projects at a rapid pace, and this is part of the Big Tent promise. We've automated some of the new project process, but could still do better (more self-service, better validation, clearer documentation). We're already pushing Gerrit past the scale of any other users so let's also discuss how we can support this continued growth whether that be development of additional tools, a new backend model, or perhaps a closer relationship with upstream Gerrit development.

https://etherpad.openstack.org/p/mitaka-infra-scalingnewprojectcreation

There's been little progress (in any direction) since the Liberty Summit decision to abandon our previous StoryBoard migration plan. What are the remaining blockers for implementing Maniphest? What about recent progress by the team that adopted StoryBoard and resumed its development? Do we need a plan C? What is likely to happen during the Mitaka cycle? Who is with us?

https://etherpad.openstack.org/p/mitaka-infra-tasktracking

Moderator: Eric Harney

A couple of topics I see as related...
* Defining/documenting the driver API
* Possible changes to driver API to pull DB access out of drivers
* Whether we can enable integration of drivers with non-Cinder services

Session leader: Brian Rosmaita

What problem is this trying to solve?:

We need to nail down the requirements for a public-facing image import mechanism that will satisfy DefCore as well as the concerns of large public clouds and small private clouds and small public clouds and large private clouds. OK, so a brief summary of this is that the current upload mechanism works fine for some folks but not others. DefCore wants us to have a single upload mechanism for everyone to use. That's what we want to nail down the requirements on. The current upload mechanism will continue to exist but won't be a DefCore requirement.

Summit session etherpad: https://etherpad.openstack.org/p/Mitaka-glance-image-import-reloaded

We have a experimental API for artifacts now. We should now consider all the constraints as well as requirements from users, operators, other projects and WGs to ensure the new upcoming API is ready and steady for launch.

Discussion:
We should discuss the API details, tradeoffs for interop, scalability, usability etc. Consider the requirements from other teams' requirements and adopt the API accordingly.

Etherpad: https://etherpad.openstack.org/p/mitaka-glance-artifacts-review

In this session, we'll go through work items and deliverables for the Mitaka release.

Etherpad

In this session, we'll detail how to get from noticing a bug, through bug triage, creating a patch, and getting it merged. We'll also discuss team processes (how we choose cores, what the PTL does, etc), and best practices for working on the docs team.

Etherpad

The Horizon contributors meetup is a informal gathering of the project contributors, with an open agenda.

The Horizon contributors meetup is a informal gathering of the project contributors, with an open agenda.