Open Stack

Excerpts from Octave J. Orgeron's message of 2017-02-03 09:54:53 -0700:
> 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?

You'll need to approach the infrastructure team (#openstack-infra, or
here on the list) about that.

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

That should help.

> 
> 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>