13:01:33 <HenryG> #startmeeting neutron_db
13:01:34 <openstack> Meeting started Mon Jun  9 13:01:33 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:37 <openstack> The meeting name has been set to 'neutron_db'
13:02:07 <HenryG> Agenda https://wiki.openstack.org/wiki/Meetings/NeutronDB
13:02:17 <HenryG> We'll keep it short today
13:03:05 <HenryG> I had an action item from last week, to ask operators how important downgrade is to them.
13:03:40 <HenryG> However, after checking with Mark McClain and Salvatore, the new plan is to support downgrade.
13:03:53 <HenryG> Because we think we can do it as a migration.
13:04:31 <HenryG> The downgrade direction will basically do nothing for the (un)healing migration.
13:04:31 <akamyshnikova> to support downgrade but do not drop any tables?
13:04:39 <HenryG> akamyshnikova: correct.
13:04:59 <akamyshnikova> HenryG, ok
13:05:43 <HenryG> So if a deployment downgrades from the healing migration (or later), it will end up with all tables.
13:06:04 <HenryG> This is deemed not to be a problem, since the tables are not used.
13:06:49 <HenryG> It should be documented so deployers are not concerned when they encounter it.
13:07:16 <HenryG> I have updated the spec to reflect this.
13:08:14 <akamyshnikova> I look though spec it looks good to me
13:08:20 <HenryG> Most of the work will now lie in getting the migration right, https://review.openstack.org/96438
13:09:00 <HenryG> jlibosva brought up a tough question, about how to include the models from icehouse for diff
13:09:41 <jlibosva> I was thinking about creating a separate module containing icehouse models...that's like copy paste.
13:09:59 <akamyshnikova> I was thinking about that too
13:10:27 <akamyshnikova> but I think we need some other ideas about this
13:10:55 <HenryG> Sounds like we have one plan. Let's work on that and see where it gets us.
13:10:57 <jlibosva> I think there is no way how to get models from previous versions and we need persistence here.
13:11:38 <jlibosva> I have one thing for Open discussion later
13:11:52 <akamyshnikova> ok, in next patch set I will do changes according this idea
13:12:13 <HenryG> Thanks akamyshnikova
13:12:18 <jlibosva> akamyshnikova: if you want, I can provide such module so you can focus on healing script
13:13:36 <akamyshnikova> jlibosva, thanks! It will be great if you help with that :)
13:13:48 <HenryG> great
13:13:56 <HenryG> #topic Open Discussion
13:13:56 <jlibosva> akamyshnikova: ack, I'll start working on that once I'm finished with my current work
13:14:13 <jlibosva> yay
13:15:13 <jlibosva> basically current healing script that gathers models from code is capable of syncing db state according to those models.
13:15:45 <jlibosva> that brings up a question why we can't use it generally for db migrations
13:15:58 <HenryG> It depends on what code base you have present
13:16:20 <jlibosva> so does current migrations because they contain migration scripts
13:16:40 <HenryG> You mean automate generation of migrations?
13:17:52 <jlibosva> well, using the healing script for db scheme changes, migration scripts could contain only data migrations
13:18:24 <jlibosva> maybe there are some bigger cons that I don't see, so I'd like to know your opinion
13:19:25 <HenryG> This is outside the immediate scope of the healing migration work, right?
13:19:33 <jlibosva> yes
13:20:04 <HenryG> I don't have enough expertise to give an answer.
13:20:27 <jlibosva> ok, maybe ML will be better then
13:20:38 <jlibosva> thanks
13:21:19 <HenryG> Could you start an email thread maybe? I think you should get feedback from Mark and Salvatore at least, and perhaps the sqlalchemy author who now works on openstack.
13:22:07 <jlibosva> HenryG: got it on my todo list
13:22:17 <HenryG> jlibosva: thanks!
13:22:30 <HenryG> Any other questions?
13:23:14 <jlibosva> nope
13:23:18 <akamyshnikova> I don't  have any at this point
13:25:43 <HenryG> #endmeeting