13:00:13 <HenryG> #startmeeting neutron_db
13:00:14 <openstack> Meeting started Mon Aug 25 13:00:13 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:18 <openstack> The meeting name has been set to 'neutron_db'
13:00:37 <salv-orlando> aloha
13:01:42 <HenryG> I forgot to update the agenda, but we are basically going to talk about the on-going work items.
13:01:57 <HenryG> #topic Migration Unit Tests
13:02:23 <HenryG> akamyshnikova: Can you give a quick status?
13:03:25 <akamyshnikova> I've got merged two changes that tests was based on. So it is open. But there is problem with this necessary changes https://review.openstack.org/115203.
13:04:20 <HenryG> OK. So you need oslo.db to be released with that fix?
13:05:36 <akamyshnikova> New oslo.db just appear so, I think if we want to get tests merged in juno, do the following thing: add this fix in implementing test in neutron, and remove after oslo.db with this changes appear.
13:06:04 <HenryG> akamyshnikova: Sounds like a reasonable plan. Thanks.
13:06:16 <HenryG> akamyshnikova: anything else?
13:07:01 <akamyshnikova> HenryG, no. I've already do this https://review.openstack.org/76520 with todo comment. So I will work on refactor
13:07:58 <salv-orlando> that’s reasonable for me.
13:08:11 <HenryG> Thanks akamyshnikova
13:08:21 <HenryG> #topic Reorganize Migrations
13:08:36 <HenryG> cue salv-orlando ...
13:09:01 <salv-orlando> I thinkl we’re doing well there. All patches under review. No blocker so far.
13:09:39 <HenryG> I have a question.
13:10:21 <salv-orlando> HenryG: listening.
13:11:14 <HenryG> For the havana initial state patch, is there an "automated" way of checking the migration changes?
13:12:46 <salv-orlando> no there isnt’. If you want it as a requirement I’d have to keep the old migrations too in the source code tree
13:13:09 <salv-orlando> in order to compare that the new migration brings into the same state as if you would use the old path up to havana
13:13:43 <salv-orlando> I have been using jenkins and 3rd party CIs as a test. Once auto-generation has been removed, these CIs rely on migrations.
13:14:00 <salv-orlando> Success from these CIs on the patch is an indicator that the new initial DB state is sane.
13:14:36 <salv-orlando> Still it’s not 100% sure. If you want to have a unit tests for that, as I said, I’d need to stow the old migration somewhere to run the comparison
13:14:59 <HenryG> Thanks. I meant only to help verify for the review, not ongoing.
13:15:04 <salv-orlando> on the other, if you need the ability of verify it for your review without having to rely on your eyes...
13:15:41 <salv-orlando> I think the best way is to use the new code - and just run the first migration (havana initial)
13:15:46 <salv-orlando> then checkout master.
13:16:18 <salv-orlando> downgrade to folsom_initial and upgrade then to head. This should prove that havana_initial == havana_release
13:16:36 <salv-orlando> then using master downgrade again to havana
13:16:44 <salv-orlando> and checkout the new patch again
13:16:49 <salv-orlando> finally upgrade to head
13:16:57 <salv-orlando> I think that if havana_initial != havan
13:17:00 <salv-orlando> sorry...
13:17:14 <salv-orlando> havana_initial != havan_release you should get a failure at some point in this process
13:17:23 <salv-orlando> otherwise if you want punctual verification...
13:17:32 <salv-orlando> use sql inspector
13:17:57 <salv-orlando> on two databases - one generated using master and brought to havana_release
13:18:00 <HenryG> great, thanks salv-orlando, I will try those methods
13:18:13 <salv-orlando> and the other generated using this new patch with havana_initial
13:18:15 <salv-orlando> cool
13:18:48 <salv-orlando> But I reckon akamyshnikova has already done this check verifying that havana_initial is in sync with the models
13:20:04 <akamyshnikova> I'll checked it one more time for sure :)
13:20:07 <HenryG> I have checked that (I hope) with mysql.
13:20:54 <salv-orlando> akamyshnikova, HenryG: better to check several times. Usually there is nothing about my patches that should be trusted.
13:21:53 <HenryG> :)
13:22:00 <HenryG> Anything else salv-orlando?
13:22:09 <salv-orlando> not on this topic.
13:22:14 <HenryG> #topic Import All Models
13:22:24 <HenryG> jlibosva: hi
13:22:27 <jlibosva> HenryG: hi
13:22:56 <HenryG> You saw my comments in the review?
13:23:59 <jlibosva> HenryG: yes, I'm going to investigate the thing about some of plugins are not yielded from walk_packages. Other than that - I think logging is ok.
13:24:09 <jlibosva> HenryG: I will reply soon
13:24:36 <HenryG> Thanks jlibosva
13:25:15 <jlibosva> I'm more worried about consequences though
13:25:41 <jlibosva> More issues we find the more I'm convinced that having models in dedicated modules was the best idea
13:25:50 <HenryG> Like what I mentioned, the uncertainty of what code gets executed on imports?
13:26:51 <jlibosva> yes
13:27:02 <HenryG> #link https://review.openstack.org/#/c/112928/5/neutron/tests/unit/testlib_api.py
13:27:11 <salv-orlando> jlibosva: if we shuffle code around for all plugins we might complicate other situations. I’m thinking about packaging and the fact that we’ll probably end up splitting plugins in other repositories.
13:27:39 <jlibosva> salv-orlando: plugins could also have their own modules.
13:27:57 <HenryG> salv-orlando: One option is to keep the models in their current locations (directories) but put them in files with a well-known naming convention.
13:27:58 <jlibosva> salv-orlando: in common package could be only core models
13:28:10 <jlibosva> yeah, like keystone
13:29:46 <salv-orlando> jlibosva: only thing I can say is that if you feel strongly about moving all models to a single place try a patch for that. That’s the kind of patch I would feel shaky about merging late in the release cycle, but if you feel confident about it...
13:31:18 <HenryG> The importing of all models is only done during neutron-db-manage and unit tests.
13:31:27 <jlibosva> I feel more like Juno can survive with head.py
13:31:49 <HenryG> +1 to head.py for Juno. Least risk.
13:31:55 <salv-orlando> jlibosva: I feel we can have some more time to think about the right solution.
13:32:21 <salv-orlando> I reckon plugins might declare which module(s) contain their db models, and have a convention around that.
13:32:44 <salv-orlando> if developers don’t follow the convention then they’ll see their unit tests failing
13:33:05 <HenryG> That's kind of what head.py does.
13:33:07 <salv-orlando> jlibosva: who knows perhaps we can make head.py the “convention"
13:33:27 <HenryG> There were complaints about it on the ML.
13:33:30 <jlibosva> We can do better than that
13:33:35 <salv-orlando> I’d say let’s table this discussion at the moment. I know the pkg walk will raise a few eyebrwos anyway
13:34:30 <HenryG> Sounds good.
13:34:46 <HenryG> But we need https://review.openstack.org/108700 to go in ASAP.
13:35:14 <akamyshnikova> yes, very important changes
13:35:20 <HenryG> I keep getting complaints about neutron-db-manage autogenerate
13:36:18 <jlibosva> if people are complaining about head.py why nobody participated/replied to "Strategy for collecting models for autogenerate"
13:36:46 <jlibosva> just a rhetorical question ... :)
13:37:52 <HenryG> #topic Open discussion
13:38:01 <salv-orlando> jlibosva: well I complain all the time about the layout of the qwerty keyboard, even if I did not participate in the discussion
13:38:09 <salv-orlando> one bug for you guys: https://bugs.launchpad.net/neutron/+bug/1354218
13:38:10 <uvirtbot> Launchpad bug 1354218 in neutron "heal script is not idempotent" [High,New]
13:38:31 <jlibosva> salv-orlando: use dvorak :)
13:38:59 <salv-orlando> jlibosva: ah that might be better true. But I’m just too old to switch now. I don’t have enough neurons left in my brain
13:39:10 <HenryG> salv-orlando: I forgot about that bug :(
13:39:32 <salv-orlando> basically it’s a matrioska bug
13:39:41 <jlibosva> salv-orlando: Believe in yourself, I bet you can do it ;)
13:39:52 <akamyshnikova> I see this for the first time
13:39:55 <salv-orlando> one issue uncovering another issue. But I had to stop at the 3rd layer
13:39:58 <HenryG> salv-orlando: Do you want to re-assign it?
13:40:20 <salv-orlando> HenryG: Yeah I don’t want to any more work! I’m on strike.
13:40:52 <salv-orlando> akamyshnikova: I’ve assigned it to you… let me know if you need more info. Maybe it’s not a bug after all...
13:41:17 <akamyshnikova> salv-orlando, ok, thanks!
13:41:41 <akamyshnikova> salv-orlando, I will investigate this :)
13:41:58 <jlibosva> salv-orlando: akamyshnikova isn't this the error we saw on some specific sqlalchemy version?
13:42:15 <akamyshnikova> jlibosva, no
13:42:16 * jlibosva is talking about http://paste.openstack.org/show/91771/
13:42:21 * salv-orlando checking which one I run on my machines.
13:42:39 <akamyshnikova> jlibosva, this one...
13:43:01 <akamyshnikova> jlibosva, there was something really like this
13:43:48 <salv-orlando> akamyshnikova, jlibosva: this behaviour was found with sqla 0.9.7
13:44:15 <akamyshnikova> salv-orlando, problem with alembic if it is older that 0.6.4
13:44:33 <jlibosva> akamyshnikova: 0.8.4 ?
13:44:44 <salv-orlando> akamyshnikova: alembic on my system is 0.6.5
13:45:00 <jlibosva> ah, sorry. I meant sqlalchemy
13:45:05 <jlibosva> ignore me
13:45:09 <akamyshnikova> seems very strange...
13:45:52 <akamyshnikova> I've got error with _compiler_dispatch only with wrong alembic version
13:46:29 <salv-orlando> akamyshnikova: I run all the sorts of stuff on my dev machines. I need to reassess this. Probably something upgraded alembic since I reported the bug...
13:46:49 <salv-orlando> anyway do you reckon http://paste.openstack.org/show/91770/ and http://paste.openstack.org/show/91769/ should be applied?
13:48:09 <akamyshnikova> salv-orlando, although I never get this error, this may be OK
13:48:32 <akamyshnikova> salv-orlando, may be OK to do things to fix this :)
13:48:47 <akamyshnikova> I just want to check it :)
13:48:53 <salv-orlando> ok cool
13:54:01 <HenryG> Thanks everyone! If there is nothing else I will end the meeting.
13:54:10 <salv-orlando> adieuuuu
13:54:13 <akamyshnikova> Thanks, bye!
13:54:14 <jlibosva> thanks, bye :)
13:54:19 <HenryG> #endmeeting