| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Timestamp | Suggested session title | Suggested session topic description | Your name | Notes, Remarks (optional) | Would you lead that session yourself ? | ||||||||||||||||||||||||
2 | 4/8/2015 13:49:09 | In-team scaling | In this session we'll discuss the challenges of scaling a development team and what we could do to solve those challenges. That includes introducing or changing roles within development teams, evolving the "core reviewers" concept, splitting review responsibilities along domain expertise lines, and other wild ideas. This will be mostly focused on Nova and Neutron cases, although the results are likely to be applicable far beyond those two projects. | Thierry Carrez | Yes ! | |||||||||||||||||||||||||
3 | 4/8/2015 13:55:55 | OpenStack release model(s) | In this session we'll discuss potential changes to the OpenStack 6-month release cycle (to start with the M release cycle). The "6-month release cycle with 3 intermediary milestones" model always has been a trade-off between our ability to produce and maintain a stable release and our desire to release early and often. As OpenStack projects mature (and we include more of them), it is good to revisit that trade-off and see if an evolution (or more flexibility) would help or hurt our users. | Thierry Carrez | Yes ! | |||||||||||||||||||||||||
4 | 4/9/2015 15:41:13 | Moving our applications to Python 3 | Now that the Oslo libraries are all working with Python 3, we are ready to prepare the tools and processes to allow us to port the applications. We won't be able to move all of the projects at once, so we need to come up with a way to move incrementally (spec to be submitted separately). | Doug Hellmann | I have a spec, but it exists mostly in my head. We'll need input from the devstack/QA team, infra, and probably the distro packagers at the very least, but I also want to find at least one project interested in working with me as a guinea pig to prove that the process works. | Yes ! | ||||||||||||||||||||||||
5 | 4/9/2015 17:15:57 | Cloud Service Federation | We want to enable a “supply chain” model of cloud service delivery, based on a network of service providers, intermediaries (resellers, aggregators, brokers), and consumers. The intent is to accommodate existing OpenStack applications with a mostly unchanged user experience. While this will build on recent work in Keystone in hierarchical multi-tenancy, it involves many aspects of OpenStack: virtual regions, quotas, RBAC, metering. | Geoff Arnold | Cloud Service Federation seems like an ideal vehicle for exploring the proposed OpenStack Product Management process. | Yes ! | ||||||||||||||||||||||||
6 | 4/9/2015 17:45:30 | Third Party CI Working Group | Discuss improving trust in CI systems test results, sharing tools and configurations, and testing responsibilities. | Kurt Taylor | Working Group wiki page: https://wiki.openstack.org/wiki/ThirdPartyCIWorkingGroup Summit topics are being finalized here: https://etherpad.openstack.org/p/liberty-third-party-ci-working-group | Yes ! | ||||||||||||||||||||||||
7 | 4/9/2015 17:54:09 | Neutron & Nova - Hug it out | There's been a lot of friction between the Neutron and Nova projects, when it comes to the issues of migration and deprecation. This session aims to improve relations between the projects by having everyone just shake hands and maybe have a hug or two. | Sean Collins | Yes ! | |||||||||||||||||||||||||
8 | 4/9/2015 21:14:13 | Errors, Notifications and Logs | There has been a groundswell of interest in converging Error Messages, Notifications and Log messages across project boundaries. And it can be confusing. The APIs generate responses that include error responses. How does this relate to messages generated for log files? How does this relate to cross project notifications? What other ways and paths are status being generated and passed in and across project boundaries? This sessions will focus on identifying, defining and delineating all the error/status messages types that are employed in multiple projects to communicate process status across boundaries. It will also hopefully move the projects closer to unified definitions and formats for the various message types. Some of the current work/discussions happening around this: https://review.openstack.org/#/c/167793/ https://wiki.openstack.org/wiki/LogWorkingGroup http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html https://review.openstack.org/#/c/156508/ Let's all get on the same page then improve it! | Rochelle Grober | I'd also like to get Everett Toews, doug Hellmann and Jay Pipes as moderators/speakers on this. Progress is being made; I'd like to get it more focused so that there are actionable items and developers who want to code towards this effort will have a place to start shortly. | Yes ! | ||||||||||||||||||||||||
9 | 4/10/2015 0:19:44 | Modern JavaScript in OpenStack | JavaScript is here to stay. We might not like it, but we can't continue to ignore it and/or try to crowbar it into python projects. There are many outstanding questions on how we should manage JavaScript: packaging, tooling, licensing, distribution, and more, and we can't really continue moving forward without coming to a consensus on these. | Michael Krotscheck | This is not just restricted to Horizon: several components of OpenStack can operate fine on their own and have asked for user interfaces of their own. | Yes ! | ||||||||||||||||||||||||
10 | 4/10/2015 12:44:24 | How to get notifications to end users | For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by "user messages", and how do they differ from our current log messages and notifications? - Our current logs are for the operator and have information that the user should not have (ip addresses, hostnames, configuration options, other tenant info etc..) - Our notifications (that Ceilometer uses) *could* be used, but I am not sure if it quite fits. (they seem a bit heavy weight for a log message and aimed at higher level events) These messages could be (based on Heat's use case): - Specific user oriented log messages (distinct from our normal operator logs) - Deprecation messages (if they are using old resource properties/template features) - Progress and resource state changes (an application doesn't want to poll an api for a state change) - Automated actions (autoscaling events, time based actions) - Potentially integrated server logs (from in guest agents) What do we have now: - The user can not get any kind of log message or notification from services. - nova console log - Heat has a DB "event" table for users (we have long wanted to get rid of this) What do other clouds provide: - https://devcenter.heroku.com/articles/logging - https://cloud.google.com/logging/docs/ - https://aws.amazon.com/blogs/aws/cloudwatch-log-service/ - http://aws.amazon.com/cloudtrail/ (other examples...) Should we use Zaqar for this or something else? | Angus Salkeld | http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html | Yes ! | ||||||||||||||||||||||||
11 | 4/13/2015 7:17:04 | OpenStack Documentation | What should OpenStack Documentation cover, and what shouldn't it? Which projects/components should the documentation team be working on, and what shouldn't they? What is valuable to developers, users, sysadmins, operators? Come along and tell us what you'd like to see in the documentation, and what you would prefer not to see. | Lana brindley | Yes ! | |||||||||||||||||||||||||
12 | 4/14/2015 23:47:12 | Handling project deletion | When projects are deleted from keystone, you can wind up with a bunch of orphaned objects in nova (instances), neutron (networks), etc. Is there a better way to handle this? | Brant Knudson | There's a couple of solutions here: 1) Don't let keystone delete the project somehow 2) When the project is deleted, broadcast an event and the other servers can go ahead and delete the objects. We've discussed this some and option 2 looks like the preferred one. There was a request to have the keystone team provide a function that other servers could use to monitor for the events and callback to the application. What are the requirements for this callback? (e.g., works in eventlet, async, ...). | Yes ! | ||||||||||||||||||||||||
13 | 4/16/2015 8:23:28 | Return request ID to the caller | This topic is part of a larger effort to log request ID mappings across service boundaries to help operators/developers to analyse logs effectively. Whenever a service makes a call to another service it will log both calling service request id and called service request id in the same log message. The idea is to store the 'x-openstack-request-id' returned from the response headers in the thread local storage of client, then expose get_openstack_request_id method to the caller to retrieve this request id. If OpenStack services like nova wants to log request ID mappings then it should call get_openstack_request_id after making a call to the cross project service using it's supported python api binding library. Advantages: - Doesn't break compatibility meaning OpenStack services using any python api binding clients supporting get_openstack_request_id method can be freely upgraded to a newer versions without making any changes to it. - Minimal changes are required in the python clients. | Abhishek Kekane | I have submitted a spec [1] in openstack-specs for cross-project approval. In this spec we have proposed two solutions, 1. Proposed change: Use thread local storage for storing last request-id from client 2. Alternative Solution: Return response headers and body from the respective clients [1] https://review.openstack.org/#/c/156508/ Implementation references with #1 change for python-cinderclient and nova: 1. python-cinderclient: https://review.openstack.org/#/c/173199/ 2. Nova: https://review.openstack.org/#/c/173234/ | Yes ! | ||||||||||||||||||||||||
14 | 4/17/2015 0:52:44 | OpenStack SDK: where it's at, where it's going | The OpenStack SDK project has made tremendous progress since the last summit and has received increasingly more attention from projects around the OpenStack ecosystem throughout that time. This session would be a discussion about the goals, progress, and priorities of the SDK -- many of those shared with efforts found in other projects -- and how we can work together to provide a first rate experience for those developing applications on OpenStack as well as those creating it. | Brian Curtin | Through a combination of curiosity by some, advocacy by our team, and traveling to four mid-cycle meetups to have conversations on it, OpenStack SDK is on the minds of several teams for moving their support behind it for the Liberty cycle. Some have even wanted to join in for Kilo and begin the process of ridding their project of its own client, but the timing hasn't worked out for both sides. Terry Howe and myself have an accepted talk on how to build applications using the SDK, which has gotten a bunch of interest, so we're looking forward -- in this session or otherwise -- to gathering people to talk about how to move this project out into the broader ecosystem. | Yes ! | ||||||||||||||||||||||||
15 | 4/18/2015 1:19:47 | Object Downloads: Cache Misses & Pollution | At Rackspace scale caching has a big impact on performance. When a 13G DLO needs to be downloaded from Glance, whether or not it is in the cache can be the difference between a six and a half minute download and a thirty second download. This can be exacerbated by the amount of bandwidth consumed by concurrently downloading the same object from the store for each request. Concurrent instance builds based on the same image can result in n cache misses, where n is the number of build requests. Separate caches on each API node can result in an unnecessary cache miss depending on which API node is hit. Periodic concurrent builds based of the same image can result in cache misses due to cache pollution and cache expiration policy. How can we maximize cache hits while minimizing unnecessary cache copies that pollute the cache? | Jesse J. Cook | https://etherpad.openstack.org/p/liberty-caching | Yes ! | ||||||||||||||||||||||||
16 | 4/20/2015 15:36:48 | Tightening rootwrap filters | The filters for rootwrap allow way more than they should be. We need a plan for how to tighten up the filters. | Brant Knudson | Yes ! | |||||||||||||||||||||||||
17 | 4/20/2015 16:02:50 | Functional Testing Show & Tell | Last summit we talked a lot about Functional Testing in the abstract, and lots of different projects went off in different directions experimenting with different approaches. We should have a session to capture what people did, what they feel is working well for them, what they feel they tried and didn't work out, and what the biggest inhibitors seem to be. Out of this we can hopefully capture some common patterns and start to converge where appropriate. | Sean Dague | Yes ! | |||||||||||||||||||||||||
18 | 4/20/2015 16:14:57 | Service Catalog Standardization | The Service Catalog is a great concept in OpenStack, it's also terribly underused, and configured differently nearly everywhere. The API Working Group did some initial fact finding here and discovered just how varied this is - https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog. Such a diverse Service Catalog means that services don't depend on it being correct (see Nova's *_host config variables), and it makes applications have to encode cloud specific behavior. What we want to discussion: - standard required naming for endpoints (versioned vs. unversioned) - changes needed in existing clouds/products to comply with this - changes in OpenStack programs that would rely on this more, thus making sure we've got it right - things we'd recommend that DefCore requires of clouds going forward | Sean Dague | This ideally should have the API WG part of driving this. I'm happy to be part of the conversation. | Would prefer not to | ||||||||||||||||||||||||
19 | 4/21/2015 23:51:06 | Defining tags for cross-project support | OpenStackClient, Horizon and Heat all allow users to consume other OpenStack services. These 3 projects could define and assign tags which indicate the level of support they have for other services. The intent of this session is to get these 3 projects to discuss the structure of the tags, and to establish the level of required TC involvement to define them. | Steve Baker | The scope of this session could be expanded to include tags which are assigned by operators, but that would likely deserve its own session. | Would prefer not to | ||||||||||||||||||||||||
20 | 4/23/2015 18:30:59 | Big Tent Model | There has been a lot of chatter about the Big Tent model and this session will bring in the TC members to explain the Big Tent Model, how it impacts existing projects, how new projects should take advantage of it, and to provide a Q&A session for it. | Travis Tripp | Obviously needs some TC members agree to lead this (ttx?) It would be nice to have pre-submitted questions. Here are two I have: Aside from the general discussion, one interest I have is how projects that use plugins to integrate with other projects should treat the plugins. Should each plugin be given its own repo and tagged independently? Should plugins for projects that have reached a certain level of maturity be in tree? Should the plugins actually live in the tree of the projects they provide the integration for? There are pros and cons of all of the above. | No ! | ||||||||||||||||||||||||
21 | 4/24/2015 16:52:30 | Roles for service users | The nova, neutron, and ceilometer service users are granted the admin role. This is a privilege escalation vulnerability waiting to happen. Service users should only be getting the permissions they require. Let's figure out a way to fix this and to prevent it from happening in future. | Brant Knudson | Yes ! | |||||||||||||||||||||||||
22 | 4/24/2015 22:13:47 | API Working Group: State of the Group | The API Working Group has a clear mission. To improve the developer experience of API users by converging the OpenStack API to a consistent and pragmatic RESTful design. The working group creates guidelines that all OpenStack projects should follow for new development, and promotes convergence of new APIs and future versions of existing APIs. The API Working Group has made good progress over the past 6 months towards these goals. Let's take some time to examine where we were, where we are, and where we're going. We'll discuss how to improve the effectiveness of the group, how to get our guidelines implemented in the OpenStack APIs, and any other ideas that improve the developer experience of API users. | Everett Toews | Yes ! | |||||||||||||||||||||||||
23 | 4/27/2015 18:44:38 | Barbican Integration Design Session | Barbican contributors will collaborate with attendees who are interested in using the key manager's capabilities but are not sure what functionality is currently available or how to best leverage it. Based on the attendees’ needs, topics covered may include secret storage and generation, x509 certificate management, and/or logical grouping of secrets. This session can be used for everything from initial architecture design to specific implementation discussions, based on attendees' pre-existing knowledge and is the hands-on complement to the Wednesday session “State of SSL in Barbican” and the Thursday session "Common Use Cases and Options for Barbican in your OpenStack Deployment". | Sheena Gregson | Paul Kehrer, Doug Mendizabal, and John Wood will be the technical leads for this discussion - I'll be there to help facilitate. | Yes ! | ||||||||||||||||||||||||
24 | 4/29/2015 10:37:25 | Technical vision for OpenStack to be ubiquitous cloud service | Through a fully distributed tenant OpenStack layer which function as the API addressing and routing, and combined with an ocean of OpenStack instances layer which provision resources like virtual machine, volume, network and etc ( no matter these OpenStack instances are in federated, or hybrid, or multi-region mode ), we can use OpenStack to build a world of ubiquitous cloud service. The vision is feasible by develop driver/agent to treat OpenStack instances as the tenant OpenStack's back-end ) | Chaoyi Huang ( joehuang ) | refer to http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg51641.html | Yes ! | ||||||||||||||||||||||||
25 | 4/30/2015 0:33:00 | Asyncronous API Error Reporting | There are many asyncronous operations an API user can perform that may fail without the user being able to understand why without calling support or having access to logs. Very few resources among all the OpenStack projects handle reporting errors to end users for asynchronous operations (Cinder volume creation, Glance Image snapshots, etc) and those that do are inconsistent with each other. This session would discuss a standard way for APIs to handle this as there are a lot of options to choose from and many APIs that do not tackle the problem at all. I will come prepared with suggested solutions, pros/cons, and proof of concept code implemented in the Cinder project. It's important that we have a solution that can become standard across openstack projects so input from the API WG would be critical. The goal of this session is to discuss the options, find additional concerns, and (hopefully) find an actionable way forward. | Alex Meade (ameade) | This was previously discussed as a Cinder session in Paris: https://etherpad.openstack.org/p/kilo-cinder-async-reporting This summit notes: https://etherpad.openstack.org/p/liberty-async-error-reporting | Yes ! | ||||||||||||||||||||||||
26 | 4/30/2015 2:22:49 | Unified Policy File | Instead of each project maintaining its own policy file, create a unified policy file that contains a common section for calculating the common rules. The goal is to make it clear what is meant by "admin" and how to limit the scope of any token. | Adam Young | Can be combined with the other policy suggestion "Roles for Service Users" | Yes ! | ||||||||||||||||||||||||
27 | 4/30/2015 22:20:00 | Improving user experience across all OpenStack projects | The intent of this meeting is to discuss strategies, tools, and processes to improve the overall user experience across all OpenStack projects. There is frequently an assumption that UX is specifically associated with improving user experiences for anything that has a graphical interface. However, good user experiences should extend into anything a user touches including APIs, CLIs and documentation. For example, the community could consider running a usability study on gathering the required data and launching an instance from the CLI. In the end, the best technology in the world loses its value if no one can use it. The goals of the session would be to start a discussion on how we choose to define user experiences as a community and identify potential areas of focus. | Piet Kruithof | Yes ! | |||||||||||||||||||||||||
28 | 5/3/2015 5:43:48 | Common scheduler & interfaces | One of the main goals for splitting out the scheduler from Nova into a separate project is to have a well defined entity for providing scheduling services to other projects. To that end we need to define what are the scheduling services different projects (Nova, Cinder, Neutron, Magnum, Ironic, ...) and and what the the APIs that need to be created to provide them. | Don Dugger (n0ano) | Yes ! | |||||||||||||||||||||||||
29 | 5/4/2015 21:22:04 | Managing concurrency | We have a proposal to drop eventlet, to be replaced by asyncio or threading. Let's get some of our concurrency experts together into a room to discuss the proposal and make sure we understand all of the issues. The goal of this session is to produce an action plan for making a decision about eventlet over the course of the next 2 cycles. | Doug Hellmann | The spec: https://review.openstack.org/#/c/164035/ | Yes ! | ||||||||||||||||||||||||
30 | 5/6/2015 4:47:10 | Partitioning in OpenStack as a whole | 1) Which projects need partitioning besides Nova?Cidner/Neutron/Ceilometer/Glance/Keystone? 2) Standalone partition design and deploy for each project, or some collaboration is need across them? e.g. Can a host belong to one Nova partition and another Cinder partition? 3) Any other value for partitioning besides scalability? e.g. fault domain isolation, heterogeneous integration... 4) Concept clarifying and instructions on different partition granularity, e.g. Cell, Available Zone, Aggregate... 5) Interface choice between parent and child partitions, internal RPC or external REST, or some other protocols? | Chaoyi Huang ( joehuang ) | Questions are from Loy Wolfe, I'd also invite Loy Wolfe as moderator/speaker on this topic if he is available. | Yes ! | ||||||||||||||||||||||||
31 | 5/16/2015 0:57:46 | Solving the UUID problem in cross-provider Nova, Cinder interactions | Please see the spec at: https://review.openstack.org/132623 Nova (and much of the rest of OpenStack) currently makes the assumption that there is only one endpoint for each type of service that can be used at a time. This blueprint outlines some use cases on why supporting multiple endpoints is a desirable feature and proposes some solutions. When there is only a single Nova, Cinder or Neutron, the current UUID scheme works well since each object type can only be served from a single endpoint. The issue being addressed here, however, is that Nova's use of an unqualified UUID to refer to objects (e.g., volumes and networks) precludes users from mixing and matching Nova with non-default service endpoints. When there are multiple instances of each of these services with multiple endpoints, it is undefined which endpoint owns a particular UUID. The Massachusetts Open Cloud team, being new to the OpenStack community, requests feedback on the best direction for realizing our goal of mixing and matching services under Nova. The current proposal focuses on Cinder, though we suspect that interactions with Neutron and Glance will have similar issues. The Massachusetts Open Cloud team, being new to the OpenStack community, requests feedback on the best direction for realizing our goal of mixing and matching services under Nova. The current proposal focuses on Cinder, though we suspect that interactions with Neutron and Glance will have similar issues. | Jason Hennessey | my email : henn@bu.edu | Yes ! | ||||||||||||||||||||||||
32 | ||||||||||||||||||||||||||||||
33 | ||||||||||||||||||||||||||||||
34 | ||||||||||||||||||||||||||||||
35 | ||||||||||||||||||||||||||||||
36 | ||||||||||||||||||||||||||||||
37 | ||||||||||||||||||||||||||||||
38 | ||||||||||||||||||||||||||||||
39 | ||||||||||||||||||||||||||||||
40 | ||||||||||||||||||||||||||||||
41 | ||||||||||||||||||||||||||||||
42 | ||||||||||||||||||||||||||||||
43 | ||||||||||||||||||||||||||||||
44 | ||||||||||||||||||||||||||||||
45 | ||||||||||||||||||||||||||||||
46 | ||||||||||||||||||||||||||||||
47 | ||||||||||||||||||||||||||||||
48 | ||||||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||||||
100 |