13:00:40 <HenryG> #startmeeting neutron_db
13:00:41 <openstack> Meeting started Mon Jul 28 13:00:40 2014 UTC and is due to finish in 60 minutes.  The chair is HenryG. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:44 <openstack> The meeting name has been set to 'neutron_db'
13:01:02 <HenryG> Agenda #link https://wiki.openstack.org/wiki/Meetings/NeutronDB#Agenda
13:01:44 <HenryG> Basically just want to go over how things are going
13:01:54 <HenryG> #topic Unit Tests
13:02:45 <HenryG> akamyshnikova: what dependencies need to get approved here?
13:03:08 <akamyshnikova> We need this requirements https://review.openstack.org/109238
13:03:43 <salv-orlando> HenryG, akamyshnikova it should be approved soon
13:03:53 <HenryG> akamyshnikova: salv-orlando: thanks
13:03:57 <akamyshnikova> then three changes: https://review.openstack.org/81334, https://review.openstack.org/109253, https://review.openstack.org/108731
13:04:35 <akamyshnikova> also there is problem with functional tests and mysql_python requirements
13:05:01 <salv-orlando> akamyshnikova: do you habe a bug and/or a patch for that?
13:06:04 <HenryG> akamyshnikova: I have not followed up with Maru on that yet. I will try again this week.
13:06:27 <akamyshnikova> salv-orlando, I just talked with SergeyLukjanov  and marun. marun said that he will investigate this error. But I didn't heard anything since that time :(
13:07:38 <salv-orlando> akamyshnikova: that is good. If there is a bug that can be filed for this I would advice to do that and target juno-3 so that the core team and the PTL will be aware that there’s this thing to look at
13:08:06 * salv-orlando I can barely remember my name these days...
13:08:23 <akamyshnikova> salv-orlando, ok, I will file a bug about that
13:08:36 <HenryG> salv-orlando: Maru is probably lumping it under https://bugs.launchpad.net/neutron/+bug/1336172
13:08:38 <uvirtbot> Launchpad bug 1336172 in neutron "Neutron functional job is broken" [Critical,In progress]
13:10:10 <akamyshnikova> hm.. error log seems to be different from that I got
13:10:46 <salv-orlando> akamyshnikova: cool… perhaps file the bug anyway and then we’ll look at it with marun and see what to do with it
13:10:57 <salv-orlando> worst case we’ll mark it as invlalid…
13:11:09 * salv-orlando adds dislexia to his problems.
13:11:34 <akamyshnikova> salv-orlando, ok
13:11:49 <HenryG> #action akamyshnikova to file bug for functional tests with mysql_python requirements
13:12:36 <HenryG> OK, looks like unit tests work is progressing. Let's move to the next topic.
13:12:50 <HenryG> #topic Cleanup
13:13:47 <HenryG> Lots of separate things going on to clean things up after healing.
13:14:06 <HenryG> Anything in particular that anyone wants to discuss?
13:15:01 <salv-orlando> I think we’re moving pretty well
13:15:05 <jlibosva> How are we gonna test consolidation of DB models?
13:15:13 <jlibosva> 3rd party CI is enough?
13:15:27 <HenryG> jlibosva: How big is the change? Will people be shocked when they see it?
13:15:55 <salv-orlando> jlibosva: what do you mean aby testing consolation? have you got already a patch for that?
13:16:00 <jlibosva> HenryG: I plan to do a lot of "small" patches. People will be definitely shocked :)
13:16:23 <jlibosva> salv-orlando: I'm working on that. I have local changes, haven't pushed it to review yet
13:16:54 <salv-orlando> jlibosva: no problem I don’t need to see code now. I just want to understand what you’re trying to do.
13:17:02 <jlibosva> some plugins contain modules with models only, so it's more like movement of file and updating path where models are used
13:17:03 <salv-orlando> this way I will make sure nobody is shocked
13:17:19 <jlibosva> salv-orlando: I'm talking about https://bugs.launchpad.net/neutron/+bug/1346658
13:17:20 <uvirtbot> Launchpad bug 1346658 in neutron "All DB model classes should be consolidated into one directory" [Undecided,New]
13:17:47 <HenryG> jlibosva: I think the existing testing should be OK. If we can move the models and nothing breaks, we should be OK.
13:17:57 <salv-orlando> jlibosva: right. Yes this is something we need to do for alembic autogenerate
13:18:17 <salv-orlando> jlibosva: discussion on this can be moved to the bug report or offline I guess
13:18:24 <jlibosva> ok
13:18:26 <jlibosva> thanks
13:19:06 <HenryG> #topic Grenade
13:19:25 <salv-orlando> salv-orlando and akamyshnikova are doing other cleanup activity as stated in the blueprint reorganize-migrations. But if that’s not relevant for this meeting we’ll skip on that
13:19:59 <HenryG> #topic Cleanup
13:20:38 <HenryG> salv-orlando: This is the time when everyone is together, so please feel free to discuss or ask questions now if needed.
13:20:48 <salv-orlando> there are two things for wider discussion
13:21:27 <salv-orlando> akamyshnikova has a patch that will allow us to have an additional healing step, which will be needed for enabling us to remove conditional logic from havana to icehouse migrations
13:21:59 <salv-orlando> the code is good but I think we can make it better by reducing the size of the module for icehouse models leveraging the frozen models we already have (or viceversa)
13:22:16 <salv-orlando> on the other hand I have a patc for removing conditional migrations from icehouse to healing
13:22:35 <salv-orlando> which can stay as it is or leverage akamyshnikova work. Your opinion is welcome.
13:23:08 <salv-orlando> Further, one thing that came out of all this work is that we need to document that we won’t support offline migrations for juno. But I think we all already agree on that
13:23:12 <salv-orlando> And last thing
13:23:46 <salv-orlando> I am about to push a rather large change with a havana_initial migration. I will remove all folsom and grizzly migrations. Does anybody has an opinion on this?
13:25:30 <HenryG> salv-orlando: No opinion from me, other than I would like to see it made available.
13:26:18 <jlibosva> I wonder how are you gonna do that? similar to folsom_initial?
13:27:36 <HenryG> salv-orlando: This will be for new deployments? Folks will get havana_initial and then migrate to icehouse and then juno?
13:28:02 <salv-orlando> HenryG, jlibosva: it will be just a new starting point in the migration history.
13:28:28 <salv-orlando> we have no point in keeping history for unsupported releases. I think also nova has a similar concept.
13:29:00 <salv-orlando> so havana_initial will replace all migrations up to havana_release including folsom_initial
13:29:12 <HenryG> salv-orlando: Great! I remember this from your spec.
13:29:33 <salv-orlando> and while I was doing this patch I realized that I’m also doing the poor man’s version of model consolidation
13:29:54 <salv-orlando> which is importing all modules with models in the alembic env
13:30:12 <salv-orlando> but that can be adjusted according to which patch betweend this and jlibosva’s land first
13:30:17 <jlibosva> salv-orlando: you still can do that by importing head
13:30:24 <jlibosva> neutron.db.migration.models.head
13:30:27 <salv-orlando> there’s no need to enforce a precise order I guess
13:30:46 <salv-orlando> jlibosva: right. I realized that once I manually imported all models and put the donkey hat on my head
13:30:52 <jlibosva> :)
13:32:29 <HenryG> Sounds good. Anything else on the cleanup topic?
13:33:13 <salv-orlando> nope from me
13:33:28 <HenryG> #topic Grenade
13:33:36 <HenryG> I didn't have Grenade in the agenda but I wanted to give the opportunity for any status.
13:35:04 <HenryG> I see https://review.openstack.org/106000 has merged
13:36:34 <HenryG> And grenade seems to be passing generally in the gate!
13:36:44 <HenryG> Time to set it back to voting?
13:37:45 <salv-orlando> HenryG:  I think it is ok to switch it back to voting. markmcclain also wanted to do a patch around the same kind of work jlibosva did but I don’t think it’s a requirement to make it voting
13:38:03 <salv-orlando> jlibosva: did you already had a patch to make grenade job voting?
13:38:15 <HenryG> Who has the power to flip the switch?
13:39:05 <salv-orlando> HenryG: you need to submit a patch to openstack-infra/config
13:39:17 <salv-orlando> if nobody has done that yet I’ll do that. I’ve done it befor.e
13:40:52 <HenryG> salv-orlando: OK, thanks. Seems jlibosva may have stepped out, but I don't see any patches from him for this.
13:41:00 <jlibosva> sorry, I'm back
13:41:47 <jlibosva> I haven't sent patch to enable voting for grenade this time
13:42:32 <jlibosva> I still see an issue with grenade time to time that it randomly doesn't start one of neutron service/agents after upgrade. I have no idea what the culprit could be
13:43:03 <salv-orlando> jlibosva:  indeed I was pointing out I see a 26% failure rate
13:43:10 <jlibosva> I'd rather enable voting once we nail this down. It doesn't happen with nova-network.
13:43:26 <salv-orlando> jlibosva: sounds a sensible thing to do.
13:43:44 <HenryG> jlibosva: Is there a bug filed for that?
13:43:47 <jlibosva> HenryG: no
13:43:50 <salv-orlando> btw https://review.openstack.org/109238 is now going trough the gate queue
13:43:51 <jlibosva> I'll file one
13:44:32 <HenryG> jlibosva: thanks
13:44:40 <HenryG> salv-orlando: Yay!
13:44:47 <akamyshnikova> salv-orlando, great!
13:45:00 <HenryG> #topic Open discussion
13:45:16 <akamyshnikova> I've got one thing for open discussion
13:45:27 <salv-orlando> go ahead akamyshnikova
13:46:34 <akamyshnikova> I was doing reviews on Friday and find out a lot of changes with migrations where downgrade does not work at all. So today I filed a bug about this https://bugs.launchpad.net/neutron/+bug/1349345
13:46:36 <uvirtbot> Launchpad bug 1349345 in neutron "Neutron does not contain checks for running migration upgrade->downgrade->upgrade" [Medium,New]
13:46:55 <akamyshnikova> I think this is kind of testing we also need
13:47:22 <HenryG> akamyshnikova: I very strongly agree.
13:47:28 <jlibosva> The question could also be "who needs downgrades?", are there any ops using that?
13:48:18 <rpodolyaka1> it's a controversial question :)
13:48:53 <rpodolyaka1> we had a discussion on that at Hong Kong summit
13:49:10 <rpodolyaka1> the outcome was: generally, you don't need them and backup would be a better choice
13:49:14 <rpodolyaka1> but if you do rolling upgrades
13:49:18 <rpodolyaka1> they might be useful
13:49:43 <rpodolyaka1> as while you are doing an upgrade, the data changes
13:49:52 <HenryG> Downgrading is more like a "panic button"? ;)
13:49:54 <rpodolyaka1> and if you need a roll back, backup won't be enough
13:50:04 <rpodolyaka1> Im not sure this works
13:50:13 <rpodolyaka1> but rackspace guys claim they do that :P
13:50:47 <jlibosva> ok, if there is a usecase for it, we should support it I guess
13:51:31 <akamyshnikova> jlibosva, in fact most part of projects have this kind of testing (nova, ceilometer, etc) so it seems to be reasonable for as to have it
13:51:49 <salv-orlando_> I have been disconnected for a bit. My opinion on downgrade is that if they are possible they should be supported properly.
13:52:06 <salv-orlando_> It is not up to us to state whether people need them or not.
13:52:12 <HenryG> Yes. If we provide downgrade() functions then they should work properly.
13:52:15 <jlibosva> I agree that testing is needed if we support the feature. So in this case, yeah, I agree :)
13:53:29 <HenryG> I saw many of akamyshnikova's comments on the broken downgrades in reviews. IMO people were just being lazy :(
13:54:24 <HenryG> Unit tests for downgrade would solve that.
13:55:06 <akamyshnikova> HenryG,  yes :) so it better to test this :)  I start working on this today.
13:55:53 <HenryG> Also it would be nice if the autogeneration did 99% of the work in creating the downgrade().
13:58:27 <HenryG> Anything else?
13:58:37 <akamyshnikova> HenryG, no
13:58:56 <HenryG> Thanks everyone!
13:59:02 <HenryG> #endmeeting