The Glance PTG schedule etherpad contains links to the etherpads for each of the sessions discussed below: https://etherpad.openstack.org/p/glance-pike-ptg-schedule
1. Short topics dharinic led a discussion of a three recent items she's been looking into. First up was how the Glance limited JSON patch support could be enhanced to allow JSON pointer references to particular tags. Consensus was that Glance supports the json-patch standard correctly for tags. Although we don't completely implement json-pointer (as is clearly documented), it doesn't make sense to do so in this case because tags are a set (hence unordered), so you can't meaningfully index into them. They look like a list, but that's because of the representational limitations of JSON. Also, there's already a "tags" API in v2 that allows a user to refer to individual tags by name. Thus, we'll leave the tags support as is. Next up was a discussion of how the v2 API is handling range requests for partial downloads in v2. Consensus was to fix this as dharinic proposed. Final topic was supporting more complicated JSON schemas than Glance currently uses. dharinic has some ideas of how to do this and will put up a patch where it can be discussed. 2. What's up with Glance docs? asettle (docs PTL) met with the team to discuss what docs the Glance team should be maintaining and what manuals are handled by the docs team. It became clear that the Glance docs need an information architecture rennovation to make the content more accessible to the various intended audiences (developers, operators, admins, end-users). Once we get them organized better, it will be easier to reduce redundancy and add enhancements. Several glancers volunteered to be contacts for asettle as she proposes a basic reorg. 3. Pike Community Goals alex_bash reported on the two Pike goals and what the likely impact on Glance will be. alex_bash has been putting up patches over the past few weeks to fix the Glance functional tests that were failing under Python 3.5, so that work is actually close to completion. (Kudos to alex_bash!) The wsgi goal for Pike is limited enough (run the current Images API in mod_wsgi in devstack) that alex_bash is optimistic that it can be completed without too many complications. Additionally, alex_bash volunteered to implement the wsgi community goal, so Glance looks to be in good shape for these. Patches are up for the Glance planning artifacts: - https://review.openstack.org/#/c/437349/ - https://review.openstack.org/#/c/437354/ 4. Image import refactor (session 1) We discussed jokke's proposal for the import backend (the "stage") and considered one or two alternatives, but ultimately decided that jokke is on the right track for an MVP implementation in Pike. 5. The Future of glance See the etherpad for a few things that were suggested. The team was pretty exhausted by the previous session, so we kept this one short. Plus, there's the glance/glare session Thursday morning where this will be discussed a bit more. - https://etherpad.openstack.org/p/glance-pike-ptg-future 6. Hierarchical image access Very lively discussion around this, in particular, whether this type of sharing can be accommodated by our current image sharing framework. nikhil is going to put up a spec to clarify the proposal and use cases, and the team agreed to continue the discussion on the spec patch. 7. OSSN review By this time we were running late, so we didn't get too far. We concentrated on OSSN-0075, in which we provide operator advice, but for which we don't have a fix. In a nutshell, the problem is that Glance allows a user to specify an image UUID at the time of image creation. If an operator purges the database to eliminate all soft-deleted records, it's possible for a UUID for a trusted image to be re-used by some other image. We discussed introducing a policy to govern specifying a UUID on image creation and/or modifying the glance-manage script to purge image properties, tags, members, and locations but no longer purge the main images table, which would prevent UUID re-use since we'd retain all the issued UUIDs. There are pros and cons to both approaches. Consensus was to consult with a database expert, and possibly both introduce the policy and modify the purge operation and let operators choose whether/how they want to handle this issue. Looking forward to another productive day! brian __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev