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