13:00:18 <HenryG> #startmeeting neutron_db
13:00:19 <openstack> Meeting started Mon Jun 23 13:00:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:23 <openstack> The meeting name has been set to 'neutron_db'
13:00:37 <HenryG> Agenda #link https://wiki.openstack.org/wiki/Meetings/NeutronDB#Agenda
13:00:48 <HenryG> #topic Blueprint
13:01:06 <HenryG> The spec has a +2! Thanks salv-orlando!
13:02:03 <HenryG> Assuming there is not much left on the BP/spec, let's talk about implementation
13:02:11 <HenryG> #topic Work in progress
13:02:40 <HenryG> The patch by akamyshnikova_ has hit a hiccup
13:02:59 <akamyshnikova_> I think the biggest question is updating the versions of sqlalchemy and alembic
13:03:20 <HenryG> #link https://review.openstack.org/96438
13:03:57 <HenryG> Right. I am not familiar with the process for updating global requirements.
13:04:24 <HenryG> Do we need to get that approved first, and how long does it take?
13:04:36 <HenryG> I assume all OpenStack projects are affected?
13:04:59 <akamyshnikova_> The oslo db will need this versions too
13:05:07 <akamyshnikova_> so I think yes
13:05:25 <rpodolyaka> hmm, I don't we need to update the global requirements
13:05:43 <rpodolyaka> the version number we have there is enough for us
13:06:09 <salv-orlando> “there” as neutron or oslo.db?
13:06:37 <rpodolyaka> global-requirements and hence in all projects
13:07:02 <HenryG> rpodolyaka: Jenkins comment on the patch: "
13:07:02 <HenryG> gate-neutron-requirements http://logs.openstack.org/38/96438/11/check/gate-neutron-requirements/f3239f5 : Incompatible requirement found; see https://wiki.openstack.org/wiki/Requirements"
13:07:13 * rpodolyaka looks
13:07:19 <salv-orlando> rpolodolyaka: obviously, thanks
13:08:00 <rpodolyaka> ahh, akamyshnikova_ updated the lower bound, I missed that
13:08:16 <rpodolyaka> yeah, this will obviously conflict with global requirements
13:08:42 <jlibosva> You should send a patch to openstack/requirements
13:08:46 <rpodolyaka> so the way we've been dealing with this in oslo.db so far is that we've been skipping the test if the version of sqlalchemy wasn't sufficient
13:08:53 <rpodolyaka> but this won't work for us in neutron
13:09:01 <rpodolyaka> as this is not something we can skip
13:09:20 <rpodolyaka> so yeah, we'll need to update global-requirements
13:09:48 <HenryG> Is this a big deal?
13:09:50 <rpodolyaka> 0.8.4 has been released for a while, so this should not be a problem for distros
13:09:58 <salv-orlando> rpodolyaka: you know sqlalchemy better than anyone else in this room. I don’t think there is any concern in upgrading minimum requirement to 0.8.4 in globa, what do you reckon?
13:10:11 <salv-orlando> ok I think you’ve already answered that
13:10:19 <rpodolyaka> yeah :)
13:10:25 <HenryG> What about alembic?
13:10:31 <rpodolyaka> 0.7.8 is a way too old
13:10:47 <rpodolyaka> AFAIR 0.6.2 was released about 5-6 months ago
13:11:22 * rpodolyaka haven't checked new LTSes, but 0.6.2 must be there
13:11:36 <HenryG> Sounds safe(ish) to me.
13:11:39 <salv-orlando> what’s the reason for pinning alembic to 0,6,2 (just curious)
13:12:07 <rpodolyaka> it adds the logic of unique constraints comparison
13:12:15 <salv-orlando> ok got it
13:12:18 <rpodolyaka> so no missing uniques detection without prior to 0.6.2
13:12:37 <rpodolyaka> the same is true for SA 0.8.4
13:13:39 <HenryG> So we should submit a request to openstack/requirements? Any volunteers?
13:13:50 <rpodolyaka> akamyshnikova_: ? I'll +1 :)
13:14:17 <akamyshnikova_> ok
13:15:08 <HenryG> #action akamyshnikova_ to submit request to  openstack/requirements to bump min versions of sqlalchemy and alembic
13:15:51 <salv-orlando> info for updating globa reqs: https://wiki.openstack.org/wiki/Requirements
13:16:02 <HenryG> Thanks salv-orlando
13:16:11 <akamyshnikova_> salv-orlando, thanks!
13:16:16 <HenryG> The other hiccup in the patch is:
13:16:21 <HenryG> "Cannot drop index 'firewall_rules_ibfk_1': needed in a foreign key constraint"
13:17:34 <akamyshnikova_> in my comment to Henry I describe why does this appear :) I think about some possible solutions.
13:18:27 <akamyshnikova_> currently this is about unsync models and migrations
13:18:38 <HenryG> akamyshnikova_: can you summarize your possible solutions? Or do you want to discuss in the review?
13:19:51 <HenryG> My understanding is we should have a migration before healing to sync the models with the db.
13:20:45 <HenryG> But I could be wrong.
13:21:45 <akamyshnikova_> the main idea is check foreign keys before checking indexes separately or when we checking index check if there is a foreign key.
13:23:45 <akamyshnikova_> In fact models almost sync with migrations except some arguable moments that are still on review or abandoned
13:23:46 <HenryG> You mean to do this within the healing migration?
13:24:51 <akamyshnikova_> yeah, in method remove_index or in separate one
13:25:28 <HenryG> OK, sounds good.
13:25:42 <HenryG> Any other questions on the WIP?
13:26:26 <HenryG> #topic Open discussion
13:27:41 <HenryG> I am still fuzzy on when exactly we should remove auto-generation of db schema from models at startup.
13:28:03 <HenryG> salv-orlando: ^^
13:28:56 <salv-orlando> HneryG: eventually
13:29:07 <HenryG> OK :)
13:29:17 <rossella_s> hello all, I just wanted to say that I am gonna work on adding a retry logic for failed db operations. I will file a spec this week, hopefully you guys can have a look :)
13:29:19 <salv-orlando> seriously, auto generation has a prerequisite which is bringing the migrations in sync with the models
13:29:43 <salv-orlando> other than that, you can go ahead with completing that work I think.
13:30:33 <HenryG> salv-orlando: I will at least keep the patch from going stale
13:31:15 <HenryG> rossella_s: sounds good. Feel free to add me as a reviewer so I see it
13:31:28 <rossella_s> HenryG: I will
13:31:30 <salv-orlando> rossella_s: are you talking about DBConnectionError, Deadlocks, or everything
13:32:33 <rossella_s> salv-orlando: DBConnectionError should be already handled, am I wrong? I was thinking of Deadlock as first step...I'd like to port the wrapper used in nova https://review.openstack.org/#/c/22276/3/nova/db/sqlalchemy/api.py
13:33:47 <salv-orlando> rossella_s: right. porting that deadlock wrapper is useful. altough I was wonder why is that not yet part of oslo.db, ropolyaka?
13:33:55 <salv-orlando> ropodolyaka: ^ ^
13:34:20 <salv-orlando> but maybe we’re digressing now. I will hand it over to HenryG and wait for open discussion for going back to this.
13:34:38 <HenryG> salv-orlando: we are in open discussion :)
13:35:07 <HenryG> And I was going to ask rpodolyaka about oslo.db
13:35:07 <rpodolyaka> salv-orlando: it is, but it might be difficult for neutron to reuse it
13:35:11 <rossella_s> HenryG: we have some time, right? 25 minutes left
13:35:22 <rossella_s> rpodolyaka: why difficult?
13:35:28 <rpodolyaka> salv-orlando: as neutron doesn't have this DBAPI layer the other project do
13:35:59 <HenryG> rpodolyaka: What are the plans to port neutron to oslo.db?
13:36:16 <salv-orlando> HenryG: that’s my call as I’m the liaison for neutron
13:36:35 <HenryG> salv-orlando: What are the plans to port neutron to oslo.db? :)
13:36:38 <rpodolyaka> HenryG: I'm going to upload a patch this week
13:36:42 <salv-orlando> I’m working on drafting a plan - I’d like to be able to push a spec by tomorrow
13:37:03 <salv-orlando> but from what I’ve gathered we have two blockers - one is schema auto generation
13:37:07 <salv-orlando> and the other is alembic.
13:37:37 <HenryG> In what way is alembic a blocker?
13:37:41 <salv-orlando> From what I gather oslo.db only supports sqlalchemy migrate atm.
13:37:52 <salv-orlando> I would like to make a complete “migration” to oslo.db
13:38:13 <salv-orlando> and use alembic from there. But there are ways around this problme, it’s not a show stopper
13:38:13 <rpodolyaka> salv-orlando: yeah, we have experimental alembic support but it's being polished
13:38:28 <rpodolyaka> salv-orlando: so it's not usable yet :(
13:38:48 <rpodolyaka> we'll ask Mike to help us to get it merged
13:40:01 <HenryG> OK it sounds like plans are in place for addressing the blockers. It will just take time.
13:40:53 <HenryG> Any other questions?
13:41:08 <rossella_s> salv-orlando: I will wait for your spec regarding the port to oslo db and then from there draft something about the retry logic
13:42:29 <salv-orlando> ok rossella_s
13:45:49 <HenryG> Thanks everyone
13:45:58 <HenryG> #endmeeting