On Mon, Jul 7, 2014 at 1:37 PM, Joe Gordon <joe.gord...@gmail.com> wrote:
> > On Jul 3, 2014 6:38 PM, "Doug Shelley" <d...@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.se...@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 <d...@tesora.com> > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > > Date: Thursday, July 3, 2014 at 2:20 PM > > To: "OpenStack Development Mailing List (not for usage questions) ( > openstack-dev@lists.openstack.org)" <openstack-dev@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. > After further thought, instead of the TC this would make a great general ML thread topic. In addition to solving this in trove and nova, neutron is looking into this as well. > > > > > > 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@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