[openstack-dev] [all][glance] Summary from the Mitaka summit
flavio at redhat.com
Tue Nov 3 09:48:14 UTC 2015
As usual, here's my summary from the summit. This time, it's limited
mostly to Glance as I wasn't able to spread myself on other rooms as I
normally do. Before I get into the details, I'd like to recommend
folks to do the same and write their own summaries (especially PTLs).
It's nice to read what will happen in other projects and to compare
the different visions and data from ppl that attended the summit.
Also, remember that there are many folks that might have had to skip
the summit that are also interested in hearing the news and,
hopefully, provide extra feedback.
Anyway, here's my collection of thoughts. Note that more detail can be
found in each spec and each etherpad.
For folks that didn't make it to the summit, I'd like to remind you
that, despite the agreements made at the summit, there's still chance
for you to comment and weight in. Nothing is written on stone so
please, provide your feedback.
We discussed the implementation of Keystone's trusts in Glance.
We spent some time throughout the week talking with folks from the
Keystone team on whether it was recommended to use `Service Tokens` or
go ahead with trusts. The short version of that discussion is that,
while service token is finalized, we'll go ahead and add support for
trusts. This may be superseded in the future by the use of `service
tokens` but it'll have to be discussed when that time comes.
Small note for folks not familiar with some of Glance's issues. This
work is important as it'll help fixing a long standing issue on the
data upload/download of big images. In the current Glance tokens may
expire during such operations (unless the token lifetime is extended
in keystone), which ends up in an auth error being returned back to
Trusts won't be used for every request but rather for those that
involve sending and receiving data (upload and download). This is to
reduce the performance impact creating trusts has on the API.
Glance Artifacts REpository (Glare)
Do you remember the Glance *EXPERIMENTAL* Glance V3 API? We had that
famous discussion again, the one we had in Vancouver, Paris and
Atlanta :) This time, however, we were able to reason about this with
the implementation in mind and, for the sake of backwards
compatibility, DefCore support and not having another major API
release, we've agreed to pull it out into its own endpoint/process.
In addition to the above, the experimental version of this API will be
refactored a bit to be compliant with DefCore requirements. Or better,
the team has engaged with the API WG team and asked them to review the
API implementation. There was quite some feedback that will be
addressed during Mitaka. It's still unsure whether it'll be considered
stable at the end of the cycle. This will be revisited when the time
As far as the python bindings go, we'll pull into glanceclient the
work that was done during liberty. Therefore, glanceclient will be the
python library to use, whereas the CLI will be in openstackclient.
We also participated in Murano's and App Catalog's meetup to discuss
how we can move forward with this. The result of that discussion is
that these teams will look into using Glare. They had several
questions and we went through all of them. I'm personally super happy
about this collaboration.
Glance image upload reloaded
We spent most of our summit time discussing this topic. This was
discussed in 1 fishbowl session, 1 working session and half meetup.
The topics discussed were related to improving the current upload
workflow by refactoring it into something that is interoperable,
discoverable and has a lower impact on deployments without affecting
the requested functionality by users.
This all sounds like a whole bunch of fancy words put together to
describe something that won't happen, ever. However, I've to say that
after the lengthy discussions there have been with the community
before and during the summit, we've reached a status in the proposal
that seems to accomplish all the above in a nice way.
I'm not going to get into the details of what the results have been
because to explain that, I'd have to also explain all the problems and
requirements. This is exactly what the spec does. Please, go and
read it, provide feedback, and help out. This is important.
Thanks Brian Rosmaita and Stuart Mclaren for preparing and moderating
Starting this cycle, we've agreed on having a list of
priorities. These priorities mention what the team is going to
be focused on. In other words, reviewers will give a higher priority
to the topics mentioned on that list as they impact the project's goal
for the cycle.
I'd like to stress that the above doesn't mean other things won't be
worked on/reviewed. Nonetheless, whenever there's a conflict, freeze
request, reviews bandwidth, you should bare in mind that things in the
list of priorities will come first.
The team dedicated one of the slots to DefCore. It was a great time
to bring members of the team up to speed with regards to what the
defcore requirements are, how we can improve communications between
our teams and how we can provide more feedback.
During the discussion, we identified some of the issues DefCore has
when it comes to Glance and we also talked about how we can improve
our tempest test suite.
In summary, there are some tests to improve, others that needs to be
The team did more than the above during the summit. There was a
discussion on image signning, hallway discussions, and there was also
a glance-drivers sprint during the meetup (we reviewed all specs that
didn't have negative feedback). I'm super happy with the results of
the summit and how promising Mitaka is looking. I'd like to thank
everyone for participating and making all the above happen.
Overall, I think it'll be fare to summarize the cycle's goal as
"getting back on our feet". Let's do it!
P.S: Please, contribute to this thread with the list of things I might
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev