Re: [openstack-dev] [Glance][Trove] Metadata Catalog

[Mark Washenberger]

I think there is some confusion about what the glance metadata api is going
to do.

We are *not* planning to store metadata about other openstack resources in
glance.

We *are* planning to store definitions of the relevant schemas of metadata
for other classes of openstack resources.

For example, if somebody adds a feature to Nova or a hypervisor driver to
deliver clowns and rainbows whenever you boot a flavor with
"extra_specs:clowns_and_rainbows" = "yes please", the metadata catalog will
allow users to discover that property, read its description, learn the
schema of possible values for this key, and learn the related keys that
could be applied on images, volumes, volume image metadata, etc.

If someone wants to make a general store that can be used to store actual
metadata, as opposed to just the definitions for metadata, they have my
support. But given the mission of the Glance Program at this point, such a
service probably does not belong in Glance.


On Thu, Jul 24, 2014 at 3:11 PM, Tim Simpson 
wrote:

>  I agree as well.
>
>  I think we should spend less time worrying about what other projects in
> OpenStack might do in the future and spend more time on adding the features
> we need today to Trove. I understand that it's better to work together but
> too often we stop progress on something in Trove to wait on a feature in
> another project that is either incomplete or merely being planned.
>
>  While this stems from our strong desire to be part of the community,
> which is a good thing, it hasn't actually led many of us to do work for
> these other projects. At the same time, its negatively impacted Trove. I
> also think it leads us to over-design or incorrectly design features as we
> plan for functionality in other projects that may never materialize in the
> forms we expect.
>
>  So my vote is we merge our own metadata feature and not fret over how
> metadata may end up working in Glance.
>
>  Thanks,
>
>  Tim
>
>  --
> *From:* Iccha Sethi [iccha.se...@rackspace.com]
> *Sent:* Thursday, July 24, 2014 4:02 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Glance][Trove] Metadata Catalog
>
>   +1
>
>  We are unsure when these changes will get into glance.
> IMO we should go ahead will our instance metadata patch for now and when
> things are ready in glance land we can consider migrating to using that as
> a generic metadata repository.
>
>  Thanks,
> Iccha
>
>   From: Craig Vyvial 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, July 24, 2014 at 3:04 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Glance][Trove] Metadata Catalog
>
>   Denis,
>
>  The scope of the metadata api goes beyond just using the glance
> metadata. The metadata can be used for instances and and other objects to
> add extra data like tags or something else that maybe a UI might want to
> use. We need this feature either way.
>
>  -Craig
>
>
> On Thu, Jul 24, 2014 at 12:17 PM, Amrith Kumar  wrote:
>
>>  Speaking as a ‘database guy’ and a ‘Trove guy’, I’ll say this;
>> “Metadata” is a very generic term and the meaning of “metadata” in a
>> database context is very different from the meaning of “metadata” in the
>> context that Glance is providing.
>>
>>
>>
>> Furthermore the usage and access pattern for this metadata, the frequency
>> of change, and above all the frequency of access are fundamentally
>> different between Trove and what Glance appears to be offering, and we
>> should probably not get too caught up in the project “title”.
>>
>>
>>
>> We would not be “reinventing the wheel” if we implemented an independent
>> metadata scheme for Trove; we would be implementing the right kind of when
>> for the vehicle that we are operating. Therefore I do not agree with your
>> characterization that concludes that:
>>
>>
>>
>> >> given goals at [1] are out of scope of Database program, etc
>>
>>
>>
>> Just to be clear, when you write:
>>
>>
>>
>> >> Unfortunately, we’re(Trove devs) are on half way to metadata …
>>
>>
>>
>> it is vital to understand that our view of “metadata” is very different
>> from (for example, a file system’s view of metadata, or potentially
>> Glance’s view of metadata). For that reason, I believe that your comments
>> on https://review.openstack.org/#/c/82123/16 are also 

Re: [openstack-dev] [Glance][Trove] Metadata Catalog

[Tim Simpson]

I agree as well.

I think we should spend less time worrying about what other projects in 
OpenStack might do in the future and spend more time on adding the features we 
need today to Trove. I understand that it's better to work together but too 
often we stop progress on something in Trove to wait on a feature in another 
project that is either incomplete or merely being planned.

While this stems from our strong desire to be part of the community, which is a 
good thing, it hasn't actually led many of us to do work for these other 
projects. At the same time, its negatively impacted Trove. I also think it 
leads us to over-design or incorrectly design features as we plan for 
functionality in other projects that may never materialize in the forms we 
expect.

So my vote is we merge our own metadata feature and not fret over how metadata 
may end up working in Glance.

Thanks,

Tim


From: Iccha Sethi [iccha.se...@rackspace.com]
Sent: Thursday, July 24, 2014 4:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][Trove] Metadata Catalog

+1

We are unsure when these changes will get into glance.
IMO we should go ahead will our instance metadata patch for now and when things 
are ready in glance land we can consider migrating to using that as a generic 
metadata repository.

Thanks,
Iccha

From: Craig Vyvial mailto:cp16...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, July 24, 2014 at 3:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Glance][Trove] Metadata Catalog

Denis,

The scope of the metadata api goes beyond just using the glance metadata. The 
metadata can be used for instances and and other objects to add extra data like 
tags or something else that maybe a UI might want to use. We need this feature 
either way.

-Craig


On Thu, Jul 24, 2014 at 12:17 PM, Amrith Kumar 
mailto:amr...@tesora.com>> wrote:
Speaking as a ‘database guy’ and a ‘Trove guy’, I’ll say this; “Metadata” is a 
very generic term and the meaning of “metadata” in a database context is very 
different from the meaning of “metadata” in the context that Glance is 
providing.

Furthermore the usage and access pattern for this metadata, the frequency of 
change, and above all the frequency of access are fundamentally different 
between Trove and what Glance appears to be offering, and we should probably 
not get too caught up in the project “title”.

We would not be “reinventing the wheel” if we implemented an independent 
metadata scheme for Trove; we would be implementing the right kind of when for 
the vehicle that we are operating. Therefore I do not agree with your 
characterization that concludes that:

>> given goals at [1] are out of scope of Database program, etc

Just to be clear, when you write:

>> Unfortunately, we’re(Trove devs) are on half way to metadata …

it is vital to understand that our view of “metadata” is very different from 
(for example, a file system’s view of metadata, or potentially Glance’s view of 
metadata). For that reason, I believe that your comments on 
https://review.openstack.org/#/c/82123/16 are also somewhat extreme.

Before postulating a solution (or “delegating development to Glance devs”), it 
would be more useful to fully describe the problem being solved by Glance and 
the problem(s) we are looking to solve in Trove, and then we could have a 
meaningful discussion about the right solution.

I submit to you that we will come away concluding that there is a round peg, 
and a square hole. Yes, one will fit in the other but the final product will 
leave neither party particularly happy with the end result.

-amrith

From: Denis Makogon [mailto:dmako...@mirantis.com<mailto:dmako...@mirantis.com>]
Sent: Thursday, July 24, 2014 9:33 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Glance][Trove] Metadata Catalog


Hello, Stackers.

 I’d like to discuss the future of Trove metadata API. But first small 
history info (mostly taken for Trove medata spec, see [1]):
Instance metadata is a feature that has been requested frequently by our users. 
They need a way to store critical information for their instances and have that 
be associated with the instance so that it is displayed whenever that instance 
is listed via the API. This also becomes very usable from a testing perspective 
when doing integration/ci. We can utilize the metadata to store things like 
what process created the instance, what the instance is being used for, etc... 
The design for this feature is modeled heavily on the Nova metadata API with a 
few tweaks in how it works internally.

And here comes conflict. Glance devs are working on “Glance Metadat

Re: [openstack-dev] [Glance][Trove] Metadata Catalog

[Iccha Sethi]

+1

We are unsure when these changes will get into glance.
IMO we should go ahead will our instance metadata patch for now and when things 
are ready in glance land we can consider migrating to using that as a generic 
metadata repository.

Thanks,
Iccha

From: Craig Vyvial mailto:cp16...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, July 24, 2014 at 3:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Glance][Trove] Metadata Catalog

Denis,

The scope of the metadata api goes beyond just using the glance metadata. The 
metadata can be used for instances and and other objects to add extra data like 
tags or something else that maybe a UI might want to use. We need this feature 
either way.

-Craig


On Thu, Jul 24, 2014 at 12:17 PM, Amrith Kumar 
mailto:amr...@tesora.com>> wrote:
Speaking as a ‘database guy’ and a ‘Trove guy’, I’ll say this; “Metadata” is a 
very generic term and the meaning of “metadata” in a database context is very 
different from the meaning of “metadata” in the context that Glance is 
providing.

Furthermore the usage and access pattern for this metadata, the frequency of 
change, and above all the frequency of access are fundamentally different 
between Trove and what Glance appears to be offering, and we should probably 
not get too caught up in the project “title”.

We would not be “reinventing the wheel” if we implemented an independent 
metadata scheme for Trove; we would be implementing the right kind of when for 
the vehicle that we are operating. Therefore I do not agree with your 
characterization that concludes that:

>> given goals at [1] are out of scope of Database program, etc

Just to be clear, when you write:

>> Unfortunately, we’re(Trove devs) are on half way to metadata …

it is vital to understand that our view of “metadata” is very different from 
(for example, a file system’s view of metadata, or potentially Glance’s view of 
metadata). For that reason, I believe that your comments on 
https://review.openstack.org/#/c/82123/16 are also somewhat extreme.

Before postulating a solution (or “delegating development to Glance devs”), it 
would be more useful to fully describe the problem being solved by Glance and 
the problem(s) we are looking to solve in Trove, and then we could have a 
meaningful discussion about the right solution.

I submit to you that we will come away concluding that there is a round peg, 
and a square hole. Yes, one will fit in the other but the final product will 
leave neither party particularly happy with the end result.

-amrith

From: Denis Makogon [mailto:dmako...@mirantis.com<mailto:dmako...@mirantis.com>]
Sent: Thursday, July 24, 2014 9:33 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Glance][Trove] Metadata Catalog


Hello, Stackers.

 I’d like to discuss the future of Trove metadata API. But first small 
history info (mostly taken for Trove medata spec, see [1]):
Instance metadata is a feature that has been requested frequently by our users. 
They need a way to store critical information for their instances and have that 
be associated with the instance so that it is displayed whenever that instance 
is listed via the API. This also becomes very usable from a testing perspective 
when doing integration/ci. We can utilize the metadata to store things like 
what process created the instance, what the instance is being used for, etc... 
The design for this feature is modeled heavily on the Nova metadata API with a 
few tweaks in how it works internally.

And here comes conflict. Glance devs are working on “Glance Metadata 
Catalog” feature (see [2]). And as for me, we don’t have to “reinvent the 
wheel” for Trove. It seems that we would be able

to use Glance API to interact with   Metadata Catalog. And it seems to be 
redundant to write our own API for metadata CRUD operations.



From Trove perspective, we need to define a list concrete use cases for 
metadata usage (eg given goals at [1] are out of scope of Database program, 
etc.).

>From development and cross-project integration perspective, we need to 
>delegate all development to Glance devs. But we still able to help Glance devs 
>with this feature by taking active part in polishing proposed spec (see [2]).



Unfortunately, we’re(Trove devs) are on half way to metadata - patch for 
python-troveclient already merged. So, we need to consider 
deprecation/reverting of merged and block

merging of proposed ( see [3]) patchsets in favor of Glance Metadata Catalog.


Thoughts?

[1] https://wiki.openstack.org/wiki/Trove-Instance-Metadata

[2] https://review.openstack.org/#/c/98554/11

[3] https://review.openstack.org/#/c/82123/


Best regards,

Denis Makogon

_

Re: [openstack-dev] [Glance][Trove] Metadata Catalog

[Craig Vyvial]

Denis,

The scope of the metadata api goes beyond just using the glance metadata.
The metadata can be used for instances and and other objects to add extra
data like tags or something else that maybe a UI might want to use. We need
this feature either way.

-Craig


On Thu, Jul 24, 2014 at 12:17 PM, Amrith Kumar  wrote:

> Speaking as a ‘database guy’ and a ‘Trove guy’, I’ll say this; “Metadata”
> is a very generic term and the meaning of “metadata” in a database context
> is very different from the meaning of “metadata” in the context that Glance
> is providing.
>
>
>
> Furthermore the usage and access pattern for this metadata, the frequency
> of change, and above all the frequency of access are fundamentally
> different between Trove and what Glance appears to be offering, and we
> should probably not get too caught up in the project “title”.
>
>
>
> We would not be “reinventing the wheel” if we implemented an independent
> metadata scheme for Trove; we would be implementing the right kind of when
> for the vehicle that we are operating. Therefore I do not agree with your
> characterization that concludes that:
>
>
>
> >> given goals at [1] are out of scope of Database program, etc
>
>
>
> Just to be clear, when you write:
>
>
>
> >> Unfortunately, we’re(Trove devs) are on half way to metadata …
>
>
>
> it is vital to understand that our view of “metadata” is very different
> from (for example, a file system’s view of metadata, or potentially
> Glance’s view of metadata). For that reason, I believe that your comments
> on https://review.openstack.org/#/c/82123/16 are also somewhat extreme.
>
>
>
> Before postulating a solution (or “delegating development to Glance
> devs”), it would be more useful to fully describe the problem being solved
> by Glance and the problem(s) we are looking to solve in Trove, and then we
> could have a meaningful discussion about the right solution.
>
>
>
> I submit to you that we will come away concluding that there is a round
> peg, and a square hole. Yes, one will fit in the other but the final
> product will leave neither party particularly happy with the end result.
>
>
>
> -amrith
>
>
>
> *From:* Denis Makogon [mailto:dmako...@mirantis.com]
> *Sent:* Thursday, July 24, 2014 9:33 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Glance][Trove] Metadata Catalog
>
>
>
> Hello, Stackers.
>
>
>  I’d like to discuss the future of Trove metadata API. But first small
> history info (mostly taken for Trove medata spec, see [1]):
>
> *Instance metadata is a feature that has been requested frequently by our
> users. They need a way to store critical information for their instances
> and have that be associated with the instance so that it is displayed
> whenever that instance is listed via the API. This also becomes very usable
> from a testing perspective when doing integration/ci. We can utilize the
> metadata to store things like what process created the instance, what the
> instance is being used for, etc... The design for this feature is modeled
> heavily on the Nova metadata API with a few tweaks in how it works
> internally.*
>
> And here comes conflict. Glance devs are working on “Glance Metadata
> Catalog” feature (see [2]). And as for me, we don’t have to* “reinvent
> the wheel” for Trove. *It seems that we would be able
>
> to use Glance API to interact with   Metadata Catalog. And it seems to be
> redundant to write our own API for metadata CRUD operations.
>
>
>
> From Trove perspective, we need to define a list concrete use cases
> for metadata usage (eg given goals at [1] are out of scope of Database
> program, etc.).
>
> From development and cross-project integration perspective, we need to
> delegate all development to Glance devs. But we still able to help Glance
> devs with this feature by taking active part in polishing proposed spec
> (see [2]).
>
>
>
> Unfortunately, we’re(Trove devs) are on half way to metadata - patch
> for python-troveclient already merged. So, we need to consider
> deprecation/reverting of merged and block
>
> merging of proposed ( see [3]) patchsets in favor of Glance Metadata
> Catalog.
>
>
>
> Thoughts?
>
> [1] https://wiki.openstack.org/wiki/Trove-Instance-Metadata
>
> [2] https://review.openstack.org/#/c/98554/11
>
> [3] https://review.openstack.org/#/c/82123/
>
>
>
> Best regards,
>
> Denis Makogon
>
> ___
> 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

Re: [openstack-dev] [Glance][Trove] Metadata Catalog

[Amrith Kumar]

Speaking as a ‘database guy’ and a ‘Trove guy’, I’ll say this; “Metadata” is a 
very generic term and the meaning of “metadata” in a database context is very 
different from the meaning of “metadata” in the context that Glance is 
providing. 

 

Furthermore the usage and access pattern for this metadata, the frequency of 
change, and above all the frequency of access are fundamentally different 
between Trove and what Glance appears to be offering, and we should probably 
not get too caught up in the project “title”.

 

We would not be “reinventing the wheel” if we implemented an independent 
metadata scheme for Trove; we would be implementing the right kind of when for 
the vehicle that we are operating. Therefore I do not agree with your 
characterization that concludes that:

 

>> given goals at [1] are out of scope of Database program, etc

 

Just to be clear, when you write:

 

>> Unfortunately, we’re(Trove devs) are on half way to metadata …

 

it is vital to understand that our view of “metadata” is very different from 
(for example, a file system’s view of metadata, or potentially Glance’s view of 
metadata). For that reason, I believe that your comments on 
https://review.openstack.org/#/c/82123/16 are also somewhat extreme.

 

Before postulating a solution (or “delegating development to Glance devs”), it 
would be more useful to fully describe the problem being solved by Glance and 
the problem(s) we are looking to solve in Trove, and then we could have a 
meaningful discussion about the right solution. 

 

I submit to you that we will come away concluding that there is a round peg, 
and a square hole. Yes, one will fit in the other but the final product will 
leave neither party particularly happy with the end result.

 

-amrith

 

From: Denis Makogon [mailto:dmako...@mirantis.com] 
Sent: Thursday, July 24, 2014 9:33 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Glance][Trove] Metadata Catalog

 

Hello, Stackers.


 I’d like to discuss the future of Trove metadata API. But first small 
history info (mostly taken for Trove medata spec, see [1]):

Instance metadata is a feature that has been requested frequently by our users. 
They need a way to store critical information for their instances and have that 
be associated with the instance so that it is displayed whenever that instance 
is listed via the API. This also becomes very usable from a testing perspective 
when doing integration/ci. We can utilize the metadata to store things like 
what process created the instance, what the instance is being used for, etc... 
The design for this feature is modeled heavily on the Nova metadata API with a 
few tweaks in how it works internally.

And here comes conflict. Glance devs are working on “Glance Metadata 
Catalog” feature (see [2]). And as for me, we don’t have to “reinvent the 
wheel” for Trove. It seems that we would be able 

to use Glance API to interact with   Metadata Catalog. And it seems to be 
redundant to write our own API for metadata CRUD operations.



From Trove perspective, we need to define a list concrete use cases for 
metadata usage (eg given goals at [1] are out of scope of Database program, 
etc.). 

>From development and cross-project integration perspective, we need to 
>delegate all development to Glance devs. But we still able to help Glance devs 
>with this feature by taking active part in polishing proposed spec (see [2]).



Unfortunately, we’re(Trove devs) are on half way to metadata - patch for 
python-troveclient already merged. So, we need to consider 
deprecation/reverting of merged and block 

merging of proposed ( see [3]) patchsets in favor of Glance Metadata Catalog.



Thoughts?

[1]  <https://wiki.openstack.org/wiki/Trove-Instance-Metadata> 
https://wiki.openstack.org/wiki/Trove-Instance-Metadata

[2]  <https://review.openstack.org/#/c/98554/11> 
https://review.openstack.org/#/c/98554/11

[3]  <https://review.openstack.org/#/c/82123/> 
https://review.openstack.org/#/c/82123/

 

Best regards,

Denis Makogon



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance][Trove] Metadata Catalog

[Denis Makogon]

On Thu, Jul 24, 2014 at 5:46 PM, Arnaud Legendre 
wrote:

>  Hi Denis,
>
>  I think this is a perfect time for you to review the spec for the glance
> metadata catalog https://review.openstack.org/#/c/98554/ and see if it
> fits your use case.
> Also, we have a session tomorrow at 9:00am PST at the Glance meetup to
> discuss this topic. I think it would be useful if you could join (in person
> or remotely). Please see the details:
> https://wiki.openstack.org/wiki/Glance/JunoCycleMeetup
>
> I will try to take part in, unfortunately remotely. Also, i'm reviewing
metadata spec right now. If there would be some kind of a gap or missing
abilities - i would leave comments. But for the cursory glance - it looks
exactly what we need, except our own(Trove) specific things.

Thanks,
Denis M.


>  Thank you,
> Arnaud
>
>  On Jul 24, 2014, at 6:32 AM, Denis Makogon  wrote:
>
>   Hello, Stackers.
>
>  I’d like to discuss the future of Trove metadata API. But first small
> history info (mostly taken for Trove medata spec, see [1]):
>  Instance metadata is a feature that has been requested frequently by our
> users. They need a way to store critical information for their instances
> and have that be associated with the instance so that it is displayed
> whenever that instance is listed via the API. This also becomes very usable
> from a testing perspective when doing integration/ci. We can utilize the
> metadata to store things like what process created the instance, what the
> instance is being used for, etc... The design for this feature is modeled
> heavily on the Nova metadata API with a few tweaks in how it works
> internally.
>
>  And here comes conflict. Glance devs are working on “Glance Metadata
> Catalog” feature (see [2]). And as for me, we don’t have to “reinvent the
> wheel” for Trove. It seems that we would be able
>  to use Glance API to interact with   Metadata Catalog. And it seems to
> be redundant to write our own API for metadata CRUD operations.
>
>
>  From Trove perspective, we need to define a list concrete use cases
> for metadata usage (eg given goals at [1] are out of scope of Database
> program, etc.).
>  From development and cross-project integration perspective, we need to
> delegate all development to Glance devs. But we still able to help Glance
> devs with this feature by taking active part in polishing proposed spec
> (see [2]).
>
>
>  Unfortunately, we’re(Trove devs) are on half way to metadata - patch
> for python-troveclient already merged. So, we need to consider
> deprecation/reverting of merged and block
>  merging of proposed ( see [3]) patchsets in favor of Glance Metadata
> Catalog.
>
>
> Thoughts?
>
>  [1] https://wiki.openstack.org/wiki/Trove-Instance-Metadata
>  [2] https://review.openstack.org/#/c/98554/11
>  [3] https://review.openstack.org/#/c/82123/
>
>
>  Best regards,
>  Denis Makogon
>  ___
> 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance][Trove] Metadata Catalog

[Arnaud Legendre]

Hi Denis,

I think this is a perfect time for you to review the spec for the glance 
metadata catalog https://review.openstack.org/#/c/98554/ and see if it fits 
your use case.
Also, we have a session tomorrow at 9:00am PST at the Glance meetup to discuss 
this topic. I think it would be useful if you could join (in person or 
remotely). Please see the details: 
https://wiki.openstack.org/wiki/Glance/JunoCycleMeetup

Thank you,
Arnaud

On Jul 24, 2014, at 6:32 AM, Denis Makogon 
mailto:dmako...@mirantis.com>> wrote:

Hello, Stackers.

 I’d like to discuss the future of Trove metadata API. But first small 
history info (mostly taken for Trove medata spec, see [1]):
Instance metadata is a feature that has been requested frequently by our users. 
They need a way to store critical information for their instances and have that 
be associated with the instance so that it is displayed whenever that instance 
is listed via the API. This also becomes very usable from a testing perspective 
when doing integration/ci. We can utilize the metadata to store things like 
what process created the instance, what the instance is being used for, etc... 
The design for this feature is modeled heavily on the Nova metadata API with a 
few tweaks in how it works internally.

And here comes conflict. Glance devs are working on “Glance Metadata 
Catalog” feature (see [2]). And as for me, we don’t have to “reinvent the 
wheel” for Trove. It seems that we would be able
to use Glance API to interact with   Metadata Catalog. And it seems to be 
redundant to write our own API for metadata CRUD operations.



From Trove perspective, we need to define a list concrete use cases for 
metadata usage (eg given goals at [1] are out of scope of Database program, 
etc.).
>From development and cross-project integration perspective, we need to 
>delegate all development to Glance devs. But we still able to help Glance devs 
>with this feature by taking active part in polishing proposed spec (see [2]).



Unfortunately, we’re(Trove devs) are on half way to metadata - patch for 
python-troveclient already merged. So, we need to consider 
deprecation/reverting of merged and block
merging of proposed ( see [3]) patchsets in favor of Glance Metadata Catalog.


Thoughts?

[1] https://wiki.openstack.org/wiki/Trove-Instance-Metadata
[2] https://review.openstack.org/#/c/98554/11
[3] https://review.openstack.org/#/c/82123/


Best regards,
Denis Makogon
___
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][Trove] Metadata Catalog

[Denis Makogon]

Hello, Stackers.

 I’d like to discuss the future of Trove metadata API. But first small
history info (mostly taken for Trove medata spec, see [1]):
Instance metadata is a feature that has been requested frequently by our
users. They need a way to store critical information for their instances
and have that be associated with the instance so that it is displayed
whenever that instance is listed via the API. This also becomes very usable
from a testing perspective when doing integration/ci. We can utilize the
metadata to store things like what process created the instance, what the
instance is being used for, etc... The design for this feature is modeled
heavily on the Nova metadata API with a few tweaks in how it works
internally.

And here comes conflict. Glance devs are working on “Glance Metadata
Catalog” feature (see [2]). And as for me, we don’t have to “reinvent the
wheel” for Trove. It seems that we would be able

to use Glance API to interact with   Metadata Catalog. And it seems to be
redundant to write our own API for metadata CRUD operations.



From Trove perspective, we need to define a list concrete use cases for
metadata usage (eg given goals at [1] are out of scope of Database program,
etc.).

>From development and cross-project integration perspective, we need to
delegate all development to Glance devs. But we still able to help Glance
devs with this feature by taking active part in polishing proposed spec
(see [2]).



Unfortunately, we’re(Trove devs) are on half way to metadata - patch
for python-troveclient already merged. So, we need to consider
deprecation/reverting of merged and block

merging of proposed ( see [3]) patchsets in favor of Glance Metadata
Catalog.


Thoughts?

[1] https://wiki.openstack.org/wiki/Trove-Instance-Metadata

[2] https://review.openstack.org/#/c/98554/11

[3] https://review.openstack.org/#/c/82123/


Best regards,

Denis Makogon
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev