13:01:32 <HenryG> #startmeeting neutron_db
13:01:33 <openstack> Meeting started Mon Jun 16 13:01:32 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:34 <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:01:50 <rpodolyaka> o/
13:01:59 <HenryG> akamyshnikova: jlibosva: hi
13:02:04 <jlibosva> hello
13:02:09 <HenryG> rpodolyaka: hi
13:02:16 <HenryG> salv-orlando: around?
13:02:53 <HenryG> #topic Blueprint
13:03:17 <HenryG> salv-orlando has provided details comments on the spec
13:03:35 <HenryG> I will address them and update it shortly
13:03:56 <HenryG> There is not much change affecting the implementation
13:04:19 <salv-orlando> aloha
13:04:25 <HenryG> But he did bring up an interesting idea about dealing with downgrades
13:04:40 <HenryG> salv-orlando: hi, good to have you here
13:04:54 <salv-orlando> and on the other hand I think we should not add too much to a single blueprint
13:05:25 <salv-orlando> my comments were aimed at getting rid of the plugin specific migrations which exist up to icehouse
13:05:25 <HenryG> So we'll look into the downgrade idea in a separate blueprint
13:05:35 <salv-orlando> this could be or could not be part of that blueprint
13:05:44 <salv-orlando> but I think efforts and assignees could be divided
13:06:06 <salv-orlando> the healing migration is already going to be quite an effort - better not to overload this blueprint
13:06:18 <HenryG> OK. I am leaning towards a separate BP
13:06:29 <salv-orlando> the only thing I would add to the current spec is to include also trunk chasers (see comment inline)
13:06:35 <rpodolyaka> +1
13:06:50 <HenryG> But it would need to go into Juno to be effective, right?
13:07:36 <HenryG> I am just about to push a new patch of the spec to adress all your comments
13:08:10 <jlibosva> I think healing at the end of current trunk timeline will require to collect models from current codebase, right?
13:08:38 <rpodolyaka> I think we'll need that anyway
13:08:47 <jlibosva> We will need models from Icehouse
13:08:51 <rpodolyaka> (if we are going to take the 'alembic-driven' approach)
13:09:01 <salv-orlando> Idk what’s the delta between icehouse and now
13:09:26 <rpodolyaka> probably not much, a few migrations
13:09:39 * rpodolyaka didn't check
13:10:09 <HenryG> So the two healings would differ by that delta?
13:10:38 <rpodolyaka> why would we need two healings?
13:10:44 <salv-orlando> rigth. We can’t ignore trunk chasers; but on the other hand we can’t chase the head of the migration history.
13:11:09 <salv-orlando> rpodolyaka: for deployers who run openstack off trunk and might alrady be past-icehouse.
13:11:16 <HenryG> rpodolyaka: see salv-orlando comment in spec about trunk chasing
13:11:32 <jlibosva> so why not putting it to trunk head only?
13:11:34 <rpodolyaka> salv-orlando: right, but we are going to add another migration script which will just call healing right?
13:11:38 <salv-orlando> but on the other hand if we decide not to care about them, we’d give just instructions to downgrade to icehouse, and then upgrade again
13:11:43 <salv-orlando> and deal with potential data loss
13:11:52 <rpodolyaka> salv-orlando: so we need to heal up to the 'current' moment
13:11:56 <rpodolyaka> not icehouse
13:12:02 <salv-orlando> rpodolyaka: yes indeed.
13:12:20 <HenryG> I guess that is option 3
13:12:23 <salv-orlando> we might just stick the migration in the current point in the timeline when it’s merged
13:12:25 <salv-orlando> and we’re done.
13:12:46 <salv-orlando> on the other hand I don’t want you guys to keep chasing a moving target.
13:13:01 <HenryG> Are we agreeing on that? Sounds easiest to me.
13:13:12 <rpodolyaka> we could 'freeze' new migrations for a week or two maybe?
13:13:15 <salv-orlando> I’ll try and get in touch with the people who can decide actual stuff for neutron and then get an embargo on migrations for new patches.
13:13:17 <HenryG> akamyshnikova's script is already at the head.
13:13:17 <rpodolyaka> when the healing script is ready
13:14:10 <rpodolyaka> I mean, if you use alembic, this part with which state of models to use is kind of orthogonal to actual healing going, you can use whichever state you want, just need to have it fixed up to some point
13:14:35 <HenryG> #agree to insert healing at head when it merges.
13:14:42 <HenryG> Thanks
13:14:57 <salv-orlando> rpodolyaka: if people in the meanwhile keep pushing migrations which need healing, you’ll chase a moving target.
13:15:20 <salv-orlando> I think it’s reasonable to ask that no new migration will have the migration_for_plugins stuff
13:15:21 <rpodolyaka> salv-orlando: agreed, but maybe we could -2 them for a short period of time?
13:15:58 <jlibosva> salv-orlando: isn't it happening every time someone sends a patch to migrations? There needs to be HEAD file updated
13:16:06 <salv-orlando> rpodolyaka: yes, we could. But the last time I started throwing -2s around I was surrounded by an angry mob ;)
13:16:13 <rpodolyaka> heh
13:16:39 <salv-orlando> jlibosva: that’s the standard issue, and it’s fairly easy to deal with. The problematic one is if one adds a migration which is plugin specific.
13:16:53 <salv-orlando> That will require us to change also the healing migration, not just the down revision
13:17:20 <jlibosva> aha
13:17:48 <HenryG> When the code is closer to "ready" we can require patches with migrations to be dependent on the healing patch?
13:18:45 <HenryG> That way they can't merge until the healing is merged, yet they won't get a -2.
13:19:15 <rpodolyaka> +1
13:19:46 <salv-orlando> HenryG: no worries I’m not afraid of angry mobs
13:20:00 <salv-orlando> I grew up in a bad neighborhood
13:20:21 <HenryG> :_
13:20:23 <HenryG> :)
13:20:51 <HenryG> OK, we have both alternatives.
13:21:02 <HenryG> Anything else about the BP?
13:21:20 <salv-orlando> nope. I’m ready to +2 once these little tweaks are made.
13:21:34 <HenryG> #topic Work in progress
13:21:37 <salv-orlando> Then we’ll have it verified and possibly approved by markmcclain
13:21:49 <HenryG> akamyshnikova: any updates?
13:23:06 <HenryG> rpodolyaka: What is the status of oslo.db ?
13:23:37 <rpodolyaka> HenryG: we've uploaded the initial release on PyPi but found  a small issue :(
13:24:03 <HenryG> rpodolyaka: small == soon fixed?
13:24:12 <rpodolyaka> HenryG: yep, it's already on review
13:24:23 <HenryG> rpodolyaka: thanks
13:24:25 <rpodolyaka> HenryG: the next release should be good to use
13:24:38 <HenryG> rpodolyaka: nice
13:24:38 <rpodolyaka> HenryG: will tag as soon as the fix is merged
13:25:17 <HenryG> Meanwhile we should all pull akamyshnikova's WIP patch and try it out.
13:25:35 <HenryG> And provide feedback.
13:26:17 <HenryG> #topic Open discussion
13:26:35 <salv-orlando> oslo.db?
13:27:09 <HenryG> salv-orlando: we plan to use it for testing. It has a framework for unit testing of migrations.
13:27:46 <HenryG> It's mentioned in the spec
13:27:50 <salv-orlando> HenryG: using it for testing? but not switching to it from neutron.openstakc.common
13:27:56 <salv-orlando> not referring to the spec.
13:28:08 <salv-orlando> I’m saying: should we migrate to it?
13:28:17 <salv-orlando> or is this meeting just about migrations?
13:29:08 <rpodolyaka> salv-orlando: the migration should be easy. I'm ready to help here
13:29:58 <rpodolyaka> HenryG: actually, model/migrations comparison test didn't make it into the initial release, but we are ready to merge it/tag a new release soon
13:31:05 <HenryG> OK, we'll monitor the situation and use oslo.db only if it doesn't impede our progress
13:32:22 <HenryG> If there are no further questions I'll end here
13:32:57 <HenryG> #endmeeting