13:01:52 <HenryG> #startmeeting neutron_db
13:01:53 <openstack> Meeting started Mon Jul 21 13:01:52 2014 UTC and is due to finish in 60 minutes.  The chair is HenryG. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:57 <openstack> The meeting name has been set to 'neutron_db'
13:02:02 <HenryG> Agenda #link https://wiki.openstack.org/wiki/Meetings/NeutronDB#Agenda
13:02:11 <HenryG> Thanks again to everyone for the great work in getting the healing merged!
13:02:23 <HenryG> Now we need to clean up some things and look at testing.
13:02:33 <HenryG> #topic Unit Tests
13:02:49 <HenryG> Problems with migrations unit test in the gate
13:02:52 <rpodolyaka> yeah, so spent some time today debugging unit tests failures in the gate
13:02:57 <HenryG> #link: https://review.openstack.org/76520
13:03:21 <akamyshnikova> #link https://review.openstack.org/107992
13:03:27 <rpodolyaka> the reason is that we have tables using different mysql engines: some of them use innodb, other use myisam
13:03:47 <rpodolyaka> the problem is that you can reference a column of a myisam table from an innodb table
13:04:02 <rpodolyaka> the mysql version in the gate defaults to myisam
13:04:23 <rpodolyaka> and we specify the engine to be used only in a few migration scripts
13:04:30 <rpodolyaka> while others use default value
13:04:37 <jlibosva> I've done some time ago patch to unify engines, maybe it can be handy - https://review.openstack.org/#/c/81334/
13:04:56 <rpodolyaka> e.g. my mysql defaults to innodb
13:05:02 <rpodolyaka> so the same tests work fine for me
13:05:21 <rpodolyaka> so the solution is straightforward - convert all tables to innodb
13:05:35 <rpodolyaka> and check all new tables to be created will use it
13:06:02 <rpodolyaka> the problem is that we have to support existing installations of neutron
13:06:09 <rpodolyaka> which might have myisam tables
13:06:22 <rpodolyaka> converting those to innodb can take *some* time
13:06:55 <rpodolyaka> so this particular migration script is going to be slow
13:07:37 <rpodolyaka> jlibosva: yeah, we definitely will need that
13:07:51 <rpodolyaka> for new installations
13:08:22 <rpodolyaka> and for existing ones - another migration script...
13:08:44 <HenryG> I am not familiar with backends and storage engines. Does this affect PostgresSQL?
13:08:45 * rpodolyaka blames mysql defaults...
13:08:55 <akamyshnikova> HenryG, no
13:08:56 <rpodolyaka> nope
13:09:05 <HenryG> Phew.
13:09:53 <HenryG> OK, so we see how the patch to force InnoDB goes, then rebase the unit test patch on that?
13:10:28 <akamyshnikova> HenryG, yes
13:10:31 <rpodolyaka> yeah. and jlibosva's patch to patch existing migration scripts
13:10:49 <rpodolyaka> we could even squash them
13:10:56 <jlibosva> It also contains function to change current tables to use given storage engine
13:11:10 <rpodolyaka> ah, great
13:11:17 <HenryG> Either way is fine/
13:11:35 <rpodolyaka> jlibosva: have you tested it on big tables?
13:11:50 <rpodolyaka> big == >1KK of rows
13:11:56 <jlibosva> rpodolyaka: no, just ordinary
13:12:03 <jlibosva> and it takes some time ...
13:12:08 <rpodolyaka> yep :(
13:12:22 <rpodolyaka> anyway, it doesn't seem we have much choice her
13:12:28 <jlibosva> agreed
13:12:43 <rpodolyaka> though, I'd ask mysql gurus first :)
13:13:19 <HenryG> Do you think many existing installations have MyISAM tables?
13:13:54 <rpodolyaka> good question
13:14:03 <rpodolyaka> it depends on the mysql version these installations use
13:14:37 <rpodolyaka> I mean, there may be no such cases at all
13:15:34 <rpodolyaka> ..or all the tables might be myisam ones (except 3 tables we set the engine explicitly for)
13:16:51 <akamyshnikova> if some table use myisam heal_migration wll fail
13:17:03 <HenryG> We'll have to document that it will take time if there are big existing MyISAM tables.
13:17:36 <rpodolyaka> I just hope mysql switched the default value to innodb a long time ago...
13:18:05 <HenryG> Why is the gate defaulting to MyISAM?
13:19:01 <rpodolyaka> we should check the mysqld config of the gate
13:19:24 <rpodolyaka> either we set the default engine to be myisam, or mysql does
13:19:50 <HenryG> rpodolyaka: Can you investigate?
13:20:07 <rpodolyaka> HenryG: sure!
13:20:19 <rpodolyaka> rpodolyaka@rpodolyaka-pc:~/src/config$ grep -i myisam . -R
13:20:19 <rpodolyaka> ./modules/openstack_project/manifests/slave_db.pp:        'default_engine' => 'MyISAM',
13:20:30 <rpodolyaka> will take a look
13:20:53 <HenryG> #action rpodolyaka to research storage engine configuration in the gate
13:21:00 <HenryG> rpodolyaka: Thanks!
13:21:08 <rpodolyaka> np
13:21:27 <HenryG> Let's move on to the next item in the agenda
13:21:49 <HenryG> #topic Rewriting History
13:21:59 <HenryG> Nuage plugin wants to delete some migrations from the timeline
13:22:07 <HenryG> #link https://review.openstack.org/105611
13:22:14 <jlibosva> Do they have a reason to do so?
13:22:29 <jlibosva> imo it could be done by usual migration script
13:22:35 <HenryG> They changed their design
13:22:59 <HenryG> They want to undo that and do it a different way
13:23:14 <akamyshnikova> in commit message mentioned that no deployment work was done
13:23:31 <HenryG> akamyshnikova: yes
13:24:54 <HenryG> Question is, should we allow them to remove the two migrations? Or as jlibosva said, fix it with a new migration?
13:25:10 <akamyshnikova> I don't like the idea of removing migrations, but may be in this it is ok...
13:25:40 <jlibosva> If someone is working with trunk and deployed juno, they already have all tables because of db_heal
13:26:00 <jlibosva> if they make a change in timeline before healing, the change won't affect people using current trunk
13:27:12 <HenryG> jlibosva: You are right. Even if they do not use nuage plugin, it is a problem.
13:27:17 <jlibosva> yes
13:27:29 <HenryG> Because now all tables are in the DB.
13:28:02 <HenryG> OK, I will comment on that patch.
13:28:35 <HenryG> next
13:28:42 <HenryG> #topic Model Class Consolidation
13:29:06 <HenryG> This is about moving all model classes to one directory.
13:29:57 <HenryG> This is a big code shuffle change.
13:30:07 <jlibosva> I think it would be better to separate plugin models instead of putting everything in one file
13:30:15 <jlibosva> Because of packaging
13:31:05 <HenryG> jlibosva: Agreed. In fact, I think we should have a lot of separate files. Almost as there are today.
13:31:17 <HenryG> But all under one directory
13:31:35 <HenryG> And containing only the models.
13:31:40 <jlibosva> good idea
13:32:05 <jlibosva> it will give packagers option to exclude plugin specific models
13:32:21 <jlibosva> hm, then again, they are already in db
13:32:58 <HenryG> jlibosva: right. From now on they should not split models out of any packages.
13:33:05 * jlibosva shuts up :)
13:33:44 <HenryG> But having separate files will allow more efficient importing in the rest of the neutron code base where needed.
13:34:18 <HenryG> We don't need everyone import all models all the time.
13:34:45 <HenryG> I think it is OK to file a bug for this work?
13:35:15 <akamyshnikova> can not it be part of bp about db-refactor?
13:35:47 <jlibosva> I agree with akamyshnikova
13:36:02 <HenryG> akamyshnikova: It could be, but mestery wants to mark that BP as done this week. :)
13:36:24 <jlibosva> HenryG: I can start working on it today
13:37:00 <HenryG> (Although I see no problem using an "Implemented" BP to commit code.)
13:37:04 <HenryG> jlibosva: Thanks!
13:37:53 <jlibosva> I mean that should optimistically imply we can make it this week :-)
13:38:01 <HenryG> moving on
13:38:08 <HenryG> #topic Grenade
13:38:23 <HenryG> I have not given this much attention :(
13:38:29 <jlibosva> I did a little
13:38:32 <jlibosva> https://review.openstack.org/#/c/106000/
13:38:48 <jlibosva> I fail to get sdague to take a look on the link above
13:39:40 <jlibosva> It should bring neutron grenade testing back to life. Although, there still could be tempest failures due to flakies since it runs tempest twice
13:40:24 <HenryG> #action HenryG and mestery to poke sdague to look at https://review.openstack.org/106000
13:41:09 <HenryG> Thanks jlibosva, I'll try to help getting more traction on this now
13:41:24 <jlibosva> HenryG: thanks
13:41:41 <mestery> HenryG: Looked
13:42:27 <HenryG> mestery: thanks!
13:43:26 <HenryG> #topic Reorganize Migrations
13:43:42 <HenryG> salv-orlando is not here
13:43:57 <HenryG> akamyshnikova: I guess you are not working much on this yet?
13:44:43 <HenryG> Sorry
13:44:50 <HenryG> #link http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/reorganize_migrations.rst
13:44:52 <akamyshnikova> I have a talk with salv-orlando on Friday, but with all this tests failing I don't have time to think much about it
13:45:16 <HenryG> akamyshnikova: Understood. No problem.
13:46:02 <HenryG> We'll discuss it more when the test items are done
13:46:11 <akamyshnikova> HenryG, thanks
13:46:18 <HenryG> #topic Open discussion
13:47:21 <jlibosva> I have one thing: There is neutron-db-manage command that doesn't fit with other similar openstack component's tools
13:47:50 <jlibosva> e.g. nova has "nova db sync" without providing any configuration file because it can be obtained automatically with oslo function
13:48:35 <jlibosva> I'd like to unify this with other services so Neutron doesn't differ. My question is: should I file it as a bug or BP? SAD has passed :(
13:48:45 <jlibosva> and what are your opinions on this idea?
13:49:28 <akamyshnikova> for me it sounds more like bp
13:49:45 <HenryG> agreed
13:50:02 <HenryG> Which means Kilo
13:50:10 <HenryG> I think that is OK though
13:50:44 <akamyshnikova> I have one small question. Are we going to have some meeting or talks on summit in Paris this year that I should participate in?
13:50:49 <HenryG> For Juno we should just tweak the template for autogenerate
13:52:39 <HenryG> akamyshnikova: the design sessions are usually decided quite late.
13:53:38 <HenryG> That said, I personally don't have any DB session planned, since the Neutron DB 'team' is so small.
13:54:07 <akamyshnikova> HenryG, ok, thanks :)
13:54:25 <HenryG> Not sure about oslo.db at the summit. rpodolyaka ?
13:55:04 <HenryG> akamyshnikova: But I highly recommend attending the summit anyway, for all openstack developers. :)
13:55:52 <rpodolyaka> HenryG: not sure, if I make to the summit this time
13:59:46 <HenryG> Well, I hope to have an informal session with any DB folks that are at the summit. We'll just discuss any items that are current at the time, and maybe discuss future plans.
14:00:32 <HenryG> But it looks like the big items will be behind us by then.
14:00:55 <HenryG> Thanks everyone!
14:01:01 <HenryG> #endmeeting