Open Stack

Excerpts from Octave J. Orgeron's message of 2017-02-02 09:40:23 -0700:
> Hi Doug,
> 
> One could try to detect the default engine. However, in MySQL Cluster, 
> you can support multiple storage engines. Only NDB is fully clustered 
> and replicated, so if you accidentally set a table to be InnoDB it won't 
> be replicated . So it makes more sense for the operator to be explicit 
> on which engine they want to use.

I think this change is probably a bigger scale item than I understood
it to be when you originally contacted me off-list for advice about
how to get started. I hope I haven't steered you too far wrong, but
at least the conversation is started.

As someone (Mike?) pointed out on the review, the option by itself
doesn't do much of anything, now. Before we add it, I think we'll
want to see some more detail about how it's going used. It may be
easier to have that broader conversation here on email than on the
patch currently up for review.

It sounds like part of the plan is to use the configuration setting
to control how the migration scripts create tables. How will that
work? Does each migration need custom logic, or can we build helpers
into oslo.db somehow? Or will the option be passed to the database
to change its behavior transparently?

Keep in mind that we do not encourage code outside of libraries to
rely on configuration settings defined within libraries, because
that limits our ability to change the names and locations of the
configuration variables.  If migration scripts need to access the
configuration setting we will need to add some sort of public API
to oslo.db to query the value. The function can simply return the
configured value.

What other behaviors are likely to be changed by the new option?
Will application runtime behavior need to know about the storage
engine?

Doug

> 
> Thanks,
> Octave
> 
> On 2/2/2017 6:46 AM, Doug Hellmann wrote:
> > Excerpts from Octave J. Orgeron's message of 2017-02-01 20:33:38 -0700:
> >> Hi Folks,
> >>
> >> I'm working on adding support for MySQL Cluster to the core OpenStack
> >> services. This will enable the community to benefit from an
> >> active/active, auto-sharding, and scale-out MySQL database. My approach
> >> is to have a single configuration setting in each core OpenStack service
> >> in the oslo.db configuration section called mysql_storage_engine that
> >> will enable the logic in the SQL Alchemy or Alembic upgrade scripts to
> >> handle the differences between InnoDB and NDB storage engines
> >> respectively. When enabled, this logic will make the required table
> >> schema changes around:
> >>
> >>    * Row character length limits 65k -> 14k
> >>    * Proper SQL ordering of foreign key, constraints, and index operations
> >>    * Interception of savepoint and nested operations
> >>
> >> By default this functionality will not be enabled and will have no
> >> impact on the default InnoDB functionality. These changes have been
> >> tested on Kilo and Mitaka in previous releases of our OpenStack
> >> distributions with Tempest. I'm working on updating these patches for
> >> upstream consumption. We are also working on a 3rd party CI for
> >> regression testing against MySQL Cluster for the community.
> >>
> >> The first change set is for oslo.db and can be reviewed at:
> >>
> >> https://review.openstack.org/427970
> >>
> >> Thanks,
> >> Octave
> >>
> > Is it possible to detect the storage engine at runtime, instead of
> > having the operator configure it?
> >
> > Doug
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>