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