Comments below..

On 2/2/2017 6:22 PM, Doug Hellmann wrote:
Yes, this is major undertaking and major driver for Oracle to setup a
3rd party CI so that we can automate regression testing against MySQL
Cluster. On the flip side, it helps solve some of the challenges with
I'm not sure we would want to gate projects on CI run outside of
our infrastructure community. We've had some bad experiences with
that in the past. What are the options for running MySQL Cluster
on nodes upstream?

It shouldn't be too bad to setup MySQL Cluster. I haven't worked with the CI infrastructure upstream. What would it take to get it configured?


larger deployments where an active/passive solution for MySQL DB is not
sufficient. So the pay-off is pretty big from an availability and
scale-out perspective.

But I do realize that I'll have to maintain this long-term and hopefully
get others to help out as more services are added to OpenStack.
Given the scope of the work being proposed, and the level of expertise
needed to do it, we're going to need to have more than one person
available to debug issues before we go to far ahead with it.

It might help to have an example or two of the sorts of migration
script changes you've described elsewhere. Maybe you can prepare a
sample patch for a project?

Are there tools that can look at a table definition and tell if it
meets the criteria for the cluster backend (the row size, types
used, whatever else)? Or is it something one has to do by hand?

I'm working on updating my keystone patches and will put that up for review early next week. I'll send the link for that. Then I'll work on cinder next. So those two should provide good examples of what the patches look like.

I've been doing things by hand, but I think a tool could be developed.

So what do you envision that I'll have to add to the oslo.db library to
make things work as you describe? What would be the best example for me
to build from?
You need a function that takes the cfg.CONF instance as an argument. It
should call register_opts() to register the option or options it uses,
and then it can return the value. Something like:

from oslo_db import options

def get_db_engine_type(conf):
     conf.register_opts(options.database_opts)
        return conf.database.mysql_storage_engine

I'll work on this and submit an update to the patch for oslo.db.



Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--

Oracle <http://www.oracle.com/>
Octave J. Orgeron | Sr. Principal Architect and Software Engineer
Oracle Linux OpenStack
Mobile: +1-720-616-1550 <tel:+17206161550>
500 Eldorado Blvd. | Broomfield, CO 80021
Certified Oracle Enterprise Architect: Systems Infrastructure <http://www.oracle.com/us/solutions/enterprise-architecture/index.html> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to