OpenStack Glance, Murano, Community app catalog: links in a chain
Nick Chase - November 17, 2015
Last month, at the OpenStack Summit in Tokyo, Mirantis engineer Alexander Tivelkov led a couple of Murano sessions: the cross-region session, and another about actions. Here's Alexander's view of what happened behind the scenes of the design summit in Tokyo.
After the session, we tried to do some internal (Mirantis-only) planning, but we were suddenly “attacked” by a very friendly (and very talkative) person who wanted to talk about Murano. It’s funny, we worked so hard to get some traction, and when we finally did, it caused problems for my schedule. Not that I'm complaining, of course. That's what summits are for, and we appreciate the outside perspectives!
It’s been suggested that we utilize so-called “Service Tokens” - additional authentication tokens being passed with the request, and identifying that these requests are made by some service (e.g. Nova) on behalf of the user. In this case, the request being made by the service will have both tokens, and the property protection will take into account the roles of both the user and the server. This streamlines the process.
Another related topic is property protection for read operations. Projects such as Searchlight are indexing image properties based on notifications emitted by Glance, and they (probably) should not be allow to search by the protected properties if the searching user does not have privileges to access them. However, this requires Searchlight to duplicate the property-protection settings of glance, and that’s a bad idea, as duplication is always error-prone. But we don’t know what to do with it. One of the ideas may be not to include the protected properties into the notification at all, but this will prevent Searchlight from indexing such data at all, even for admins.
The team has agreed on the first topic (more algorithms) and identified some open issues with the second (signature size). It was agreed that we should look more deeply into it, but that it should be solvable.
One important thing that did come out of this session is that DefCore will provide a set of compatibility requirements within 3 months of the summit, at which point the community can provide feedback.
For, artifacts my understanding is that the plugin-specific APIs are fine, as we just do not include them into DefCore, and that’s fine. The “public” part should be DefCore-compatible, however. So, this actually matches what I thought before, so we don't have to make any changes there.
It was also decided to merge the v3 feature-branch of python-glanceclient into the master, so we have a single client library. In the meantime, the Glare CLI should be done in the OpenStack CLI itself, not in python-glanceclient.
So, this is quite a radical change for us. It is ok, and it makes sense, however it actually puts the things back to where it was before the Vancouver. It's frustrating because these changes are confusing people, so I feel like we better pick something and stay at it, instead of changing the decisions every cycle with every new PTL.
As for as the actual priorities, security fixes have top priority, of course. Also, the conversion from Nova v1 to v2 is considered a primary priority. Most of the patches in this process will target Nova, but some things may need to land in Glance. These patches should indicate appropriate needs in the commit messages.
We agreed, that for the Mitaka cycle, most other features are of lower priority. (They are listed in the spec to be landed this week.) We also decided that Glare API stabilization is a priority on its own, but it's actual priority level was undecided. We'll file a separate spec on that ASAP.
The presentation clearly identified the potential conflict of AppCat, Murano and GlanceArtifacts, also it was expressed a very serious security concern on the fact that AppCat does not provide any way to verify the resources. AppCat should have https endpoint support, as well as the ability to sign resources. We decided to document the current issues, start fixing the https issue (as it's easier) and then think about how to do the consistency guarantees.
During the design session we discussed the workflow needed to update the assets. We agreed that the existing objects should never be modified. Instead, a new version of the object should be published.
The Murano Contributors’ Meetup actually turned into a cross-project work session for Murano, Glance and AppCatalog to define the borders between projects, and agree on shared responsibilities and reuse of common functionality.
We’ve started with what had been called Glance V3 (and now is called Artifacts V1, aka Glare) and its applications for Community App Catalog, i.e. with what was defined in this article. It turned out that we’ve finally reached an agreement with the AppCat guys on the fact that Glare should be used for the backend. We’ve identified the immediate action items for this to happen (pluggable DB models, CORS API support and more) and agreed to collaborate in this direction. Also, I’ve made a demo of the proof-of-concept we made for them.
Then we covered the overlap in functionality between the Murano Dashboard and the AppCatalog UI. And this one looks important; we’ve decided to join the UI efforts here.
Instead of having a separate “Murano” dashboard with its “Application Catalog” -> “Applications” panel which looks really similar in the name and the concept to the “Applications” panel of App Catalog UI, we’ve decided to have a single “Applications” Dashboard (note, that there will be no “Murano” or other code names in the UI: users usually don’t care about the project names). It will provide capabilities to browse both remote applications (i.e. search in apps.openstack.org) and the local one (Glare - if it is installed, of just Glance V2 if not) for all types of supported assets. It will users allow to install assets such as apps locally (if supported by local config) and launch the apps from the local copies (i.e. spawn a VM out of an Image, run a Heat stack out of a template or deploy a Murano application out of package).
The same dashboard will contain a “Running Apps” page to list what has already been deployed, with available actions, such as Stop or calling Murano Actions. Different versions of that dashboard will be available depending on what is currently installed in the cloud.
So this is a really big thing, which may turn into a new project with its own git repo and reviewers team. We need more discussion on this internally (we need to be sure that we don’t shoot ourselves in the foot with this: we don’t want a simple “launch a VM” or “run a Heat stack” to prevent people from using Murano), but overall that was a big success for the Murano team.
Murano
On Wednesday I did a Glance API V3 talk with Brian Rosmaita, hoping to send a proper message to those who are going to use our APIs. We also had some fruitful conversations on Artifacts before and after the sessions; it seems like the topic still attracts attention.After the session, we tried to do some internal (Mirantis-only) planning, but we were suddenly “attacked” by a very friendly (and very talkative) person who wanted to talk about Murano. It’s funny, we worked so hard to get some traction, and when we finally did, it caused problems for my schedule. Not that I'm complaining, of course. That's what summits are for, and we appreciate the outside perspectives!
Glance
Cross-project property protection
The idea here is that Glance has ability to “protect” (i.e. to make read only or to hide) some of the image metadata properties based on policies. However, there are projects which create, update or read the images on behalf of the user but still should have other privileges to access those properties. For example, if Nova creates a Snapshot of the VM, it should be able to set some special properties, while a regular user - that is, someone accessing the images API - should not be able to do that. Right now, Glance has no way to differentiate between these two types of requests; both of them are authenticated by the user's token.It’s been suggested that we utilize so-called “Service Tokens” - additional authentication tokens being passed with the request, and identifying that these requests are made by some service (e.g. Nova) on behalf of the user. In this case, the request being made by the service will have both tokens, and the property protection will take into account the roles of both the user and the server. This streamlines the process.
Another related topic is property protection for read operations. Projects such as Searchlight are indexing image properties based on notifications emitted by Glance, and they (probably) should not be allow to search by the protected properties if the searching user does not have privileges to access them. However, this requires Searchlight to duplicate the property-protection settings of glance, and that’s a bad idea, as duplication is always error-prone. But we don’t know what to do with it. One of the ideas may be not to include the protected properties into the notification at all, but this will prevent Searchlight from indexing such data at all, even for admins.
Glance: Image Signing
I attended a small session about needed improvements to the image signing feature, which was recently added and landed in Liberty. The list of improvements includes adding new signing algorithms (MD5 is definitely outdated, so more should be added, but we need to maintain backwards compatibility) and increasing the key size. The latter requires us to increase the size of the signature, and this may lead to some issues; the size of the signature property will have to be more than 255 chars, and since it is passed in the headers, that may cause some deployment issues.The team has agreed on the first topic (more algorithms) and identified some open issues with the second (signature size). It was agreed that we should look more deeply into it, but that it should be solvable.
Glance: DefCore updates
The DefCore guys joined us to explain DefCore’s rules and guidance about APIs, their test coverage, the differences between public and private (or admin) APIs and their view of them. It was a useful and informative session, mostly aimed at syncing up and clarifying these things. No particular decisions were made, but the picture became a lot clearer.One important thing that did come out of this session is that DefCore will provide a set of compatibility requirements within 3 months of the summit, at which point the community can provide feedback.
For, artifacts my understanding is that the plugin-specific APIs are fine, as we just do not include them into DefCore, and that’s fine. The “public” part should be DefCore-compatible, however. So, this actually matches what I thought before, so we don't have to make any changes there.
Glance: Artifacts
Ok, this one was my session, and here is an important decision we’ve made: we are separating the API endpoints of Glance Images (v1/v2) and Glance Artifacts (Glare) into two different processes (and thus two different endpoints in Keystone). This actually means that the Glance v3 API is removed in favor of Artifacts v1. The project itself remains in the Glance codebase, and under Glance project guidance.It was also decided to merge the v3 feature-branch of python-glanceclient into the master, so we have a single client library. In the meantime, the Glare CLI should be done in the OpenStack CLI itself, not in python-glanceclient.
So, this is quite a radical change for us. It is ok, and it makes sense, however it actually puts the things back to where it was before the Vancouver. It's frustrating because these changes are confusing people, so I feel like we better pick something and stay at it, instead of changing the decisions every cycle with every new PTL.
Glance Priority List
We decided to have a special tag in the commit message that indicates the work done by that commit is considered a priority for the Glance team during the Mitaka cycle. This tage then enables reviewers filter the reviews in the dashboard based on the approved team priorities.As for as the actual priorities, security fixes have top priority, of course. Also, the conversion from Nova v1 to v2 is considered a primary priority. Most of the patches in this process will target Nova, but some things may need to land in Glance. These patches should indicate appropriate needs in the commit messages.
We agreed, that for the Mitaka cycle, most other features are of lower priority. (They are listed in the spec to be landed this week.) We also decided that Glare API stabilization is a priority on its own, but it's actual priority level was undecided. We'll file a separate spec on that ASAP.
AppCatalog
For AppCatalog, there was a priority and roadmap presentation, followed by a design session.The presentation clearly identified the potential conflict of AppCat, Murano and GlanceArtifacts, also it was expressed a very serious security concern on the fact that AppCat does not provide any way to verify the resources. AppCat should have https endpoint support, as well as the ability to sign resources. We decided to document the current issues, start fixing the https issue (as it's easier) and then think about how to do the consistency guarantees.
During the design session we discussed the workflow needed to update the assets. We agreed that the existing objects should never be modified. Instead, a new version of the object should be published.
The Murano Contributors’ Meetup actually turned into a cross-project work session for Murano, Glance and AppCatalog to define the borders between projects, and agree on shared responsibilities and reuse of common functionality.
We’ve started with what had been called Glance V3 (and now is called Artifacts V1, aka Glare) and its applications for Community App Catalog, i.e. with what was defined in this article. It turned out that we’ve finally reached an agreement with the AppCat guys on the fact that Glare should be used for the backend. We’ve identified the immediate action items for this to happen (pluggable DB models, CORS API support and more) and agreed to collaborate in this direction. Also, I’ve made a demo of the proof-of-concept we made for them.
Then we covered the overlap in functionality between the Murano Dashboard and the AppCatalog UI. And this one looks important; we’ve decided to join the UI efforts here.
Instead of having a separate “Murano” dashboard with its “Application Catalog” -> “Applications” panel which looks really similar in the name and the concept to the “Applications” panel of App Catalog UI, we’ve decided to have a single “Applications” Dashboard (note, that there will be no “Murano” or other code names in the UI: users usually don’t care about the project names). It will provide capabilities to browse both remote applications (i.e. search in apps.openstack.org) and the local one (Glare - if it is installed, of just Glance V2 if not) for all types of supported assets. It will users allow to install assets such as apps locally (if supported by local config) and launch the apps from the local copies (i.e. spawn a VM out of an Image, run a Heat stack out of a template or deploy a Murano application out of package).
The same dashboard will contain a “Running Apps” page to list what has already been deployed, with available actions, such as Stop or calling Murano Actions. Different versions of that dashboard will be available depending on what is currently installed in the cloud.
So this is a really big thing, which may turn into a new project with its own git repo and reviewers team. We need more discussion on this internally (we need to be sure that we don’t shoot ourselves in the foot with this: we don’t want a simple “launch a VM” or “run a Heat stack” to prevent people from using Murano), but overall that was a big success for the Murano team.
