Open Stack

On Jul 3, 2014 6:38 PM, "Doug Shelley" <doug at tesora.com> wrote:
>
> Iccha,
>
>
>
> Thanks for the feedback. I guess I should have been more specific – my
intent here was to layout use cases and requirements and not talk about
specific implementations. I believe that if we can get agreement on the
requirements, it will be easier to review/discuss design/implementation
choices. Some of your comments are specific to how one might chose to
implement against these requirements – I think we should defer those
questions until we gain some agreement on requirements.
>
>
>
> More feedback below…marked with [DAS]
>
>
> Regards,
>
> Doug
>
>
>
> From: Iccha Sethi [mailto:iccha.sethi at RACKSPACE.COM]
> Sent: July-03-14 4:36 PM
>
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [trove] Discussion of capabilities feature
>
>
>
> Hey Doug,
>
>
>
> Thank you so much for putting this together. I have some
questions/clarifications(inline) which would be useful to be addressed in
the spec.
>
>
>
>
>
> From: Doug Shelley <doug at tesora.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
> Date: Thursday, July 3, 2014 at 2:20 PM
> To: "OpenStack Development Mailing List (not for usage questions) (
openstack-dev at lists.openstack.org)" <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [trove] Discussion of capabilities feature
>
>
>
> At yesterday's Trove team meeting [1] there was significant discussion
around the Capabilities [2] feature. While the community previously
approved a BP and some of the initial implementation, it is apparent now
that there is no agreement in the community around the requirements, use
cases or proposed implementation.
>
>
>
> I mentioned in the meeting that I thought it would make sense to adjust
the current BP and spec to reflect the concerns and hopefully come up with
something that we can get consensus on. Ahead of this, I thought it
would to try to write up some of the key points and get some feedback here
before updating the spec.
>
>
>
> First, here are what I think the goals of the Capabilities feature are:
>
> 1. Provide other components with a mechanism for understanding which
aspects of Trove are currently available and/or in use
>
> >> Good point about communicating to other components. We can highlight
how this would help other projects like horizon dynamically modify their UI
based on the api response.
>
> [DAS] Absolutely
>
>
>
> [2] "This proposal includes the ability to setup different capabilities
for different datastore versions. “ So capabilities is specific to data
stores/datastore versions and not for trove in general right?
>
>
>
> [DAS] This is from the original spec – I kind of pushed the reset to make
sure we understand the requirements at this point. Although what the
requirements below contemplate is certainly oriented around datastore
managers/datastores and versions.
>
>
>
> Also it would be useful for us as a community to maybe lay some ground
rules for what is a capability and what is not in the spec. For example,
how to distinguish what goes in
https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L273 as
a config value and what does not.
>
> [DAS] Hopefully this will become clearer through this process
>
>
>
> 2. Allow operators the ability to control some aspects of Trove at
deployment time
>
> >> If we are controlling the aspects at deploy time what advantages do
having tables like capabilities and capabilities_overrides offer over
having in the config file under the config groups for different data stores
like [mysql][redis] etc? I think it would be useful to document these
answers because they might keep resurfacing in the future.
>
> [DAS] Certainly at the time the design/implementation is fleshed out
these choices would be relevant to be discussed.
>
> Also want to make sure we are not trying to solve the problem of config
override during run time here because that is an entirely different problem
not in scope here.
>
>
>
> Use Cases
>
>
>
> 1. Unimplemented feature - this is the case where one/some datastore
managers provide support for some specific capability but others don't. A
good example would be replication support as we are only planning to
support the MySQL manager in the first version. As other datastore managers
gain support for the capability, these would be enabled.
>
> 2. Unsupported feature - similar to #1 except this would be the case
where the datastore manager inherently doesn't support the capability. For
example, Redis doesn't have support for volumes.
>
> 3. Operator controllable feature - this would be a capability that can be
controlled at deployment time at the option of the operator. For example,
whether to provide access to the root user on instance creation.
>
> >> Are not 1 and 2 set at deploy time as well?
>
> [DAS] I see 1 and 2 and basically baked into a particular version of the
product and provided at run time.
>
>
>
> 4. Downstream capabilities addition - basically the ability to use
capabilities as an extension point. Allow downstream implementations to add
capabilities that aren't present in upstream Trove.
>
>
>
> Requirements
>
>
>
> 1. There are a well known set of capabilities that are provided with
upstream Trove. Each capability is either read-only (basically use cases 1
& 2) or read-write (use case 3). Use case #4 capabilities are not part of
the "well known" set.
>
> 2. Each capability can be over-ridden at the datastore manager level, the
datastore level or the datastore version level. The datastore manager level
would be used for the read only capabilities and specified by a given
version of Trove. Datastore/Datastore version overrides would be for
Operator controllable capabilities that are read-write.
>
> >> Is there going to be a distinction at design level between
read-write/read only capabilities? For example are operators going to be
forbidden from changing certain capabilities?
>
> [DAS] Yes – It makes no sense for an operator to change a read only
capability because there would because it represents an missing
implementation
>
>
>
> 3. The datastore/datastore version overrides are only present if created
by the Operator at deployment time.
>
> >> Again if this is deployment time only, should we be having config
files  for different data stores? And instead of having to populate
databases by admins, this could be taken care of by config management tools
in deployments?
>
> [DAS] This is a design/implementation question –although I don’t really
understand the comment “…having to populate databases by admins..”.
However, the storage for the mechanism is implemented, it should be
abstracted from the operators/admins/users…
>
>
>
> 4. A clean Trove install should create the domain of known capabilities
and the datastore manager overrides relevant to the installed version of
Trove.
>
> 5. Upgrades - need to provide a mechanism to migrate from a version of
Trove where:
>
> a. A capability is being moved from historical config file into the
capability mechanism
>
> b. A previously non-existent capability is being introduced.
>
> c. Capability adjustments have occurred in the newer version that affect
the datastore manager level capabilities. This likely has some impact on
old-version guest agents running against capability upgrades.
>
>
>
> Any feedback is welcome. Hopefully, based on the feedback we can update
the spec and move forward on adjusting the implementation.
>

This sounds very similar to the v3/v2.1 discussion happening in nova. All
OpenStack projects need to address these issues and it would be a shame if
each project chose a different solution, perhaps this is a good topic for
the TC to help tackle? As having different solutions across OpenStack will
result in a non-cohesive user experience.

>
>
> Regards,
>
> Doug
>
>
>
> [1]
http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2014-07-02.log
starting
at 18:05
>
> [2] https://wiki.openstack.org/wiki/Trove/trove-capabilities
>
>
>
>
>
> Thanks,
>
> Iccha
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/6aecb9cb/attachment.html>