This session will include the following subject(s):
Running Keystone in different environments:
OpenStack operators may want to run Keystone in a variety of environments that best fit their operational needs and existing identity infrastructure. Examples include the following:
* Targeting PyPy for performance. * Using Jython or IronPython for working with Java-based or .Net-based infrastructure.
We can motivate this discussion by considering the scenario of using Keystone on Jython to work with an existing Java-based identity environment. There are a number of reasons why this could be a good option:
* Operators may be running an existing identity infrastructure to support legacy usage in their data center(s). They would prefer to provide a seamless experience to their customers as they migrate to completely using OpenStack.
* Porting existing Java code to Python is avoided. This is especially helpful when considering that such operators want to avoid additional and significant investment in legacy approaches, but instead want to move such code to maintenance mode. Java APIs can instead be directly used by a Keystone driver, which helps improve the performance picture as well.
* In the side-by-side migration, both Keystone and legacy services can be deployed in the same servlet container, given that WSGI can be readily mapped to the servlet API. This simplifies deployment during the transition, avoids additional latency overhead, and does not require wrapping existing Java code in REST APIs that can then be consumed. This is especially important if there is any impedance mismatch between the identity models that could result in additional overhead.
* Other possibilities include being able to access a wealth of Java based APIs (Shibboleth and others).
Note that Keystone is well-suited for considering these types of deployment questions. Keystone does not use eventlets/greenlets, making it much more portable to alternatives like Jython or IronPython. In addition, seamless identity support is generally expected by customers, compared to perhaps other APIs operators would need to support.
(Session proposed by Jim Baker)
Keystone Dev/Ops Session:
Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success.
However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer.
This session proposes to run such an an "ops" session for the Keystone project.
Primarily, the purpose of this session is to for developers to ask the operators to answer questions, and request information. However, operators could also be allowed to tell the developers things (give feedback) as a secondary purpose.
