OpenStack Summit Austin Glance update
- June 13, 2016
- Glance
Let’s take a quick look at the discussions that took place during the third day of the Summit in Austin. At least two of them were related to Glance. Traditionally we have been interested in this project since it is important for both the Murano and Community App Catalog projects. After the Summit in Tokyo, we published an article explaining the relation between these projects, but let's get a couple of updates to keep a finger on the pulse of the project.
The highlights of the talk included the new framework to define the artifact types using the oslo.versioned_objects library, an updated artifact lifecycle, and the state transition diagram.
He described the current state of the initiative: the code was 90% ready and is expected to be completed in early June, with the code review procedure to follow.
Unlike the previous summit discussions of the artifact initiative, this time there was no pushback from the community: folks just silently listened to the talk, asked a couple of minor technical questions and said nothing more. So, it looks like a silent agreement to have the feature in, but we can’t be sure about that until the code review begins.
Currently there are several levels of image visibility: “private” images (visible and accessible only to a tenant who owns them), “public” images (visible and accessible to everyone), and “shared” images: visible to the owner and the users that were explicitly granted access by the owner. The usual practice (at least in public clouds) is to restrict the setting of the public level to the cloud admins to indicate that the image is supported by the cloud operator.
There is a concept of the “default” image list: a set of images the user gets when calling the GET /v2/images API. The private images owned by the user’s tenant and the public images are included into the list, while the “shared” images are filtered out by default and require the user to explicitly accept the grant for the image before it appears in their default list. (This is done to prevent spamming.)
The idea is to have a new level of image visibility setting which will combine the benefits of the “shared” and “public” levels. It should be called “community” and is similar to “public” - the “community” images are accessible to everyone. But unlike the public ones they are not included in the default image list unless the user explicitly “subscribes” to that image.
The implementation of this idea is quite straightforward, but it hasn’t begun yet. Only the spec is present right now. The speaker - Brian Rosmaita from Rackspace - tried to bring more attention and encourage people to implement it. Only time will tell whether he succeeded or not.
This may indicate a loss of interest in the project by a significant part of the community — or it may mean that important things are happening below the radar of the summit and the team does not want to expose much. We may learn the answer to this based on the outcome of the Newton development cycle.
Glance artifacts
Mike Fedosin gave a presentation about the upcoming V1 version of the Glare API. This is work towards solidifying the grounds established in the experimental V3 API of the Glance API and then – based on the outcome of the Tokyo design summit – split into a separate Glare Service.The highlights of the talk included the new framework to define the artifact types using the oslo.versioned_objects library, an updated artifact lifecycle, and the state transition diagram.
He described the current state of the initiative: the code was 90% ready and is expected to be completed in early June, with the code review procedure to follow.
Unlike the previous summit discussions of the artifact initiative, this time there was no pushback from the community: folks just silently listened to the talk, asked a couple of minor technical questions and said nothing more. So, it looks like a silent agreement to have the feature in, but we can’t be sure about that until the code review begins.
Glance image sharing
This was quite a strange session. I had already seen the same proposal 1.5 years ago in one of Glance’s mid-cycle design summits, and it was accepted there - but it still hasn’t been implemented. This is probably because there is no real need for it for most of the stakeholders; the use case is a bit limited and is likely to be needed only by large public cloud providers, such as Rackspace (thus they are trying to drive it), but nobody else - or at least there is not much interest from other parties. So, here is a brief description of what is proposed.Currently there are several levels of image visibility: “private” images (visible and accessible only to a tenant who owns them), “public” images (visible and accessible to everyone), and “shared” images: visible to the owner and the users that were explicitly granted access by the owner. The usual practice (at least in public clouds) is to restrict the setting of the public level to the cloud admins to indicate that the image is supported by the cloud operator.
There is a concept of the “default” image list: a set of images the user gets when calling the GET /v2/images API. The private images owned by the user’s tenant and the public images are included into the list, while the “shared” images are filtered out by default and require the user to explicitly accept the grant for the image before it appears in their default list. (This is done to prevent spamming.)
The idea is to have a new level of image visibility setting which will combine the benefits of the “shared” and “public” levels. It should be called “community” and is similar to “public” - the “community” images are accessible to everyone. But unlike the public ones they are not included in the default image list unless the user explicitly “subscribes” to that image.
The implementation of this idea is quite straightforward, but it hasn’t begun yet. Only the spec is present right now. The speaker - Brian Rosmaita from Rackspace - tried to bring more attention and encourage people to implement it. Only time will tell whether he succeeded or not.
Conclusion
What is currently happening in the Glance community may seem to be a lull or even a decline: there is not much activity, lots of the features being discussed at the summits are minor, and even the major ones (like the Artifact Repository) don’t get the attention and the heated discussions they used to get.This may indicate a loss of interest in the project by a significant part of the community — or it may mean that important things are happening below the radar of the summit and the team does not want to expose much. We may learn the answer to this based on the outcome of the Newton development cycle.
