Open Stack

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<mailto:doug at tesora.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto:openstack-dev at lists.openstack.org>)" <openstack-dev at lists.openstack.org<mailto: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.

[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?

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.

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.
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?
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?

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?

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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140703/9a11df2c/attachment.html>