A narrative list of things to do as prompted by summit, with associated exposition.

Gabbi

The presentation went well, with various assertions of people wanting to have gabbi tests in their stuff, notably Nova and "the api tests in tempest", meme-like "gabbi will fix that" statements throughout the week. Unfortunately I think this may take more hand holding than I initially desired. Not because people aren't capable, but rather the general crush of too much to do requires some management and encouragement.

• MissingGabbiCoverage is still pending
• Move gabbi under qa umbrella (postponed until compelling reason)
• Unit tests for gabbi (coverage via unittest rather than via gabbi itself)
• Consolidate tutorial code and other links into docs

Ceilometer

We went into summit hoping to make some progress on decomposing ceilometer into its constituent parts and making those parts reusable as separate tools either in concert with the other ceilometer parts or with other systems, such as Monasca. I was expecting a bit of resistance or at least fear, but there was support across the board for at least trying.

In part this may have been because there was input from operators that this would be a useful way to help them scale and use different parts effectively. For example some people wanted to be able to use the pollsters without thinking about anything else.

In general it felt like the doors were opened to being considerably more radical in approaches to solving problems because if we're not, then there won't be any problems to solve.

• Spec collection agent split (fabio has already started one, will have to see if it is aligned). I'm still hoping to keep the pollsters separate from the notification agent but that may not be practical.
• Do collection agent split.
• Review alarm split spec
• Review save nova from the compute agent spec. I have some concerns about avoiding coupling between the compute agent and the notification agent. If the cache reset is going to be via RPC (which it seems like it has to be) then anything (with auth) needs to be able to call it or we are building in a coupling which is part of what we are trying to kill.
• ceilo in virtenv in devstack (under review)
• devstack plugin for ceilo. This is a keeping-up-with-qa requirement.
• grenade plugin for ceilo. This too is a keeping-up-with-qa requirement.
• I put myself on the hook to investigate why uwsgi + ceilo app.wsgi don't seem to be working
• Testing (unit and functional) need a review and tidy up to make sure we are able to ride the splits described above smoothly.
• Think about ceilo's relationship with WSME (see below).

Gnocchi

We didn't do a lot of talking about Gnocchi, mainly because it is pretty much under control and other things are not. The general upshot of interactions with people are that they are interesting, want to give it a try and are concerned about migration. With migration it is not necessarily a concern about data migration but rather of other tooling: there is a change in API that will require change in tooling.

• Better backends. This is something that has to happen to make sure that gnocchi is useful in real world situations. There's a plan to make the API async so that data deposits do not have to guarantee write before returning. This will help with things like InfluxDB.

Making sure gnocchi actually works in the real world is a high priority.

API-WG

The API working group sessions had lots of attendees and a good sense of momentum. One relatively important outcome is that the role of the working group as educator, not just information provider, was made more explicit. This happened because it became clear that a lot of people trying to use the guidelines were coming from a position of unfamiliarity with the history and culture of HTTP. Without that background guidelines that just say "Do X not Y" are easy to contest.

A decision has been made to be far more verbose in the guidelines, telling the story of why things are as they are.

• Update my own pending reviews
• Review the many pending reviews
• Bring up need for changes-since guideline for many/most APIs.

WSME

I had a few discussions with people about WSME and there's general agreement that no one should be using it for anything. There's a new release going out today which fixes some important bugs but not enough to make a significant difference especially given the general agreement that WSME's architecture is just plain wrong for what people want and should be able to do.

This means that forthcoming work with WSME should be maintenance only, and review of contributions from people who do use it (there is one contributor from outside OpenStack who uses it actively).

• Maintain WSME

Other

Many conversations wound their way back to oslo.messaging as a limiting factor. Too much data in the queue, inability to ttl things in the queue, inability to easily send things in the queue as events consumable by multiple endpoints. Since so many of my conversations ended up at this point I feel like I badly need to understand messaging much better than I currently do.

• Learn oslo.messaging

The QA team would like me to be more active in the QA team. I'm not sure if I have the cycles for this but I think it is necessary for continued good health and it is also where a lot of my energy goes anyway. I'd especially like to make sure that Fedora is healthy in the QA environments.

• QA general explore
• Fedora health in QA
• tempest-lib API clients HTTP accuracy