Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140724/33e3767f/attachment.html>