Open Stack

On Mon, Jul 7, 2014 at 1:37 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

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


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 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/20140708/a8062291/attachment.html>