Re: [openstack-dev] [TROVE] Trove capabilities

[Michael Basnight]

Denis Makogon  writes:

> Let me elaborate a bit.
>
> [...]
>
> Without storing static API contract capabilities gonna be 100% corrupted,
> because there's no API description inside Trove.

Im not sure i understand what you mean here.

> About reloading, file should not be reloaded, file is a static unmodifiable
> template. As the response users sees the combinition of described contract
> (from file) and all capabilities inside database table (as i described in
> my first emai). To simplify file usage we could deserialize it into dict
> object and make it as singleton to use less memory.

Im not a fan, at all, of a file based config for this. It will be
exposed to users, and can be modeled in the database just fine.

> About Kalebs design and whole appoach. Without blocking/allowing certain
> capabilities for datastores whole approach is nothing else than "help
> document" and this is not acceptable.

Incorrect. Its a great first approach. We can use this, and the entries
in the db, to conditionally expose things in the extensions.

> Approach of capabilities is: "In runtime block/allow tasks to be executed
> over certain objects". That why i stand on re-reviewing whole design from
> scratch with all contributors.

We can do this _using_ kalebs work in the future, when we refactor
extensions. Weve had this conversation already, a few months ago when
the redis guys first came aboard. re-review is not needed. Kalebs stuff
is completely valid, and anything you are talking about can be used by
the user facing capabilities.

ON A SEPARATE NOTE

This is one of the hardest message threads ive ever read.  If you guys
(everyone on the thread, im talking to you) dont use bottom posting, and
quote the sections you are answering, then its nearly impossible to
follow. Plz follow the conventions the rest of the OpenStack community
uses. So if there is more to discuss, lets continue, using above as a
proper way to do it.


pgpWXbIs9UV0C.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TROVE] Trove capabilities

[Daniel Salinas]

I'll be honest, after reading your proposal Denis and looking over
what Kaleb has it feels like you both are calling 2 different things
"capabilities".  Denis, your proposal provides a way of blocking or
enabling api paths to the users.  Kaleb's proposal is more about
informing consumers of the api what things are required or not for
making those api calls.  One example that Kaleb is implementing is the
volume on create.  In the end, this will give a user the ability to
query the api for a datastore, redis for example, and find out that
redis does *not* use an ephemeral volume so they cannot pass a volume
size to the create call.  Another good example is users, again using
redis as an example.  If I am a company making a UI for trove and I
need to know when constructing the page for managing a redis instance
in trove, do I display the users tab of my UI or not.  Now I see some
definite overlap with some of the pathing stuff but if you dig further
into it, like with ephemeral volumes, I don't see a logical way to fit
that into your DSL.  Further I don't like changing the model of things
that are displayed to users via the api and having them stored in a
flat file anywhere.  Whether or not you come up with a clever way to
reload that file without restarting the trove process is irrelevant to
me.  In my mind, if data is for displaying to users then it gets put
in the database, plain and simple.  Then we don't need to do any
tricks with looking at a database entry and then looking in some
dictionary that was deserialized from a yaml file to see which ones
are actually shown or used.

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