Re: [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status
Hello All, I just took a look at this blueprint and see that it doesn't have any priority. Was there a discussion on priority? Any idea what, if any of this will make it into Icehouse? Also, are there going to be any further design sessions on it? Thanks, Travis From: Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] Sent: Friday, December 20, 2013 3:43 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status Hi, Metadata repository meeting occurred this Tuesday in #openstack-glance channel. Main item that was discussed was an API for a new metadata functions and where this API should appear. During discussion it was defined that the main functionality will be a storage for different objects and metadata associated with them. Initially all objects will have a specific type which defines specific attributes in metadata. There will be also a common set of attributes for all objects stored in Glance. During the discussion there was an input from different projects (Hest, Murano, Solum) what kind of objects should be stored for each project and what kind functionality is minimally required. Here is a list of potential objects: Heat: * HOT template Potential Attributes: version, tag, keywords, etc. Required Features: * Object and metadata versioning * Search by specific attribute\attributes value Murano * Murano files o UI definition o workflow definition o HOT templates o Scripts Required Features: * Object and metadata versioning * Search by specific attribute Solum * Solum Language Packs Potential Attributes: name, build_toolchain, OS, language platform, versions Required Features: * Object and metadata versioning * Search by specific attribute After a discussion it was concluded that the best way will be to add a new API endpoint /artifacts. This endpoint will be used to work with object's common attributes while type specific attributes and methods will be accessible through /artifact/object-type endpoint. The endpoint /artifacts will be used for filtering objects by searching for specific attributes value. Type specific attributes search should also be possible via /artifacts endpoint. For each object type there will be a separate table for attributes in a database. Currently it is supposed that metadata repository API will be implemented inside Glance within v2 version without changing existing API for images. In the future, v3 Glance API can fold images related API to the common artifacts API. New artifact's API will reuse as much as possible from existing Glance functionality. Most of the stored objects will be non-binary, so it is necessary to check how Glance code handle this. AI All projects teams should start submit BPs for new functionality in Glance. These BPs will be discussed in ML and on Glance weekly meetings. Related Resources: Etherpad for Artifacts API design: https://etherpad.openstack.org/p/MetadataRepository-ArtifactRepositoryAPI Heat templates repo BP for Heat: https://blueprints.launchpad.net/heat/+spec/heat-template-repo Initial API discussion Etherpad: https://etherpad.openstack.org/p/MetadataRepository-API Thanks Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status
Hi Travis, I think it will be discussed on the mini-summit which will be on Jan 27th-28th in Washington DC. Here is an etherpad with the summit agenda: https://etherpad.openstack.org/p/glance-mini-summit-agenda I hope that after F2F discussion all BPs will have priority and assignment. Thanks Georgy On Fri, Jan 17, 2014 at 10:11 AM, Tripp, Travis S travis.tr...@hp.comwrote: Hello All, I just took a look at this blueprint and see that it doesn’t have any priority. Was there a discussion on priority? Any idea what, if any of this will make it into Icehouse? Also, are there going to be any further design sessions on it? Thanks, Travis *From:* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] *Sent:* Friday, December 20, 2013 3:43 PM *To:* OpenStack Development Mailing List *Subject:* [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status Hi, Metadata repository meeting occurred this Tuesday in #openstack-glance channel. Main item that was discussed was an API for a new metadata functions and where this API should appear. During discussion it was defined that the main functionality will be a storage for different objects and metadata associated with them. Initially all objects will have a specific type which defines specific attributes in metadata. There will be also a common set of attributes for all objects stored in Glance. During the discussion there was an input from different projects (Hest, Murano, Solum) what kind of objects should be stored for each project and what kind functionality is minimally required. Here is a list of potential objects: Heat: · HOT template Potential Attributes: version, tag, keywords, etc. *Required Features:* · Object and metadata versioning · Search by specific attribute\attributes value *Murano* · *Murano files* o UI definition o workflow definition o HOT templates o Scripts *Required Features:* · Object and metadata versioning · Search by specific attribute Solum · Solum Language Packs *Potential Attributes:* name, build_toolchain, OS, language platform, versions *Required Features:* · Object and metadata versioning · Search by specific attribute After a discussion it was concluded that the best way will be to add a new API endpoint /artifacts. This endpoint will be used to work with object’s common attributes while type specific attributes and methods will be accessible through /artifact/object-type endpoint. The endpoint /artifacts will be used for filtering objects by searching for specific attributes value. Type specific attributes search should also be possible via /artifacts endpoint. For each object type there will be a separate table for attributes in a database. Currently it is supposed that metadata repository API will be implemented inside Glance within v2 version without changing existing API for images. In the future, v3 Glance API can fold images related API to the common artifacts API. New artifact’s API will reuse as much as possible from existing Glance functionality. Most of the stored objects will be non-binary, so it is necessary to check how Glance code handle this. AI All projects teams should start submit BPs for new functionality in Glance. These BPs will be discussed in ML and on Glance weekly meetings. Related Resources: Etherpad for Artifacts API design: https://etherpad.openstack.org/p/MetadataRepository-ArtifactRepositoryAPI Heat templates repo BP for Heat: https://blueprints.launchpad.net/heat/+spec/heat-template-repo Initial API discussion Etherpad: https://etherpad.openstack.org/p/MetadataRepository-API Thanks Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status
Hi, Metadata repository meeting occurred this Tuesday in #openstack-glance channel. Main item that was discussed was an API for a new metadata functions and where this API should appear. During discussion it was defined that the main functionality will be a storage for different objects and metadata associated with them. Initially all objects will have a specific type which defines specific attributes in metadata. There will be also a common set of attributes for all objects stored in Glance. During the discussion there was an input from different projects (Hest, Murano, Solum) what kind of objects should be stored for each project and what kind functionality is minimally required. Here is a list of potential objects: Heat: - HOT template Potential Attributes: version, tag, keywords, etc. Required Features: - Object and metadata versioning - Search by specific attribute\attributes value Murano - Murano files - UI definition - workflow definition - HOT templates - Scripts Required Features: - Object and metadata versioning - Search by specific attribute Solum - Solum Language Packs Potential Attributes: name, build_toolchain, OS, language platform, versions Required Features: - Object and metadata versioning - Search by specific attribute After a discussion it was concluded that the best way will be to add a new API endpoint /artifacts. This endpoint will be used to work with object’s common attributes while type specific attributes and methods will be accessible through /artifact/object-type endpoint. The endpoint /artifacts will be used for filtering objects by searching for specific attributes value. Type specific attributes search should also be possible via /artifacts endpoint. For each object type there will be a separate table for attributes in a database. Currently it is supposed that metadata repository API will be implemented inside Glance within v2 version without changing existing API for images. In the future, v3 Glance API can fold images related API to the common artifacts API. New artifact’s API will reuse as much as possible from existing Glance functionality. Most of the stored objects will be non-binary, so it is necessary to check how Glance code handle this. AI All projects teams should start submit BPs for new functionality in Glance. These BPs will be discussed in ML and on Glance weekly meetings. Related Resources: Etherpad for Artifacts API design: https://etherpad.openstack.org/p/MetadataRepository-ArtifactRepositoryAPI Heat templates repo BP for Heat: https://blueprints.launchpad.net/heat/+spec/heat-template-repo Initial API discussion Etherpad: https://etherpad.openstack.org/p/MetadataRepository-API Thanks Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
