13:00:30 <HenryG> #startmeeting neutron_db
13:00:32 <openstack> Meeting started Tue Jun  3 13:00:30 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:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:35 <openstack> The meeting name has been set to 'neutron_db'
13:00:52 <HenryG> Today's agenda:
13:00:58 <HenryG> #link https://wiki.openstack.org/wiki/Meetings/NeutronDB#Agenda
13:01:11 <HenryG> #topic Spec/Blueprint
13:01:13 <chuckC> hi
13:01:19 <HenryG> #link https://review.openstack.org/95738
13:01:32 <HenryG> #link https://blueprints.launchpad.net/neutron/+spec/db-migration-refactor
13:01:39 <HenryG> I have linked some bugs to the BP.
13:01:44 <HenryG> Please add any missing associated bugs.
13:01:50 <HenryG> (In the launchpad BP page, click on "Link a bug report".)
13:01:58 <HenryG> Some of those bugs may be abandoned. We'll discuss this shortly.
13:02:42 <HenryG> The questions raised in the spec review are design questions, so let's discuss those now.
13:02:59 <HenryG> #topic Design
13:03:13 <salv-orlando> I have missed the previous meeting - so if I’m talking about stuff already committed please just reply “sorry, already committed"
13:03:32 <akamyshnikova> yes I've got this document with some notes and related link to change #link https://docs.google.com/a/mirantis.com/document/d/10p6JKIQf_rymBuNeOywjHiv53cRTfz5kBg8LeUCeykI/edit
13:03:40 <HenryG> salv-orlando: good to have you here!
13:03:57 <salv-orlando> I am still “supporting” a model where the migrations are healed within the migration path; this is mostly to make it easier for operators.
13:04:10 <salv-orlando> I also think and I believe we all agree that we don’t need to support offline migrations
13:04:40 <salv-orlando> And I still think we can rework existing migrations, guaranteeing downgrade up to havana
13:05:42 <HenryG> salv-orlando: So you mean no separate migration timelines?
13:06:04 <salv-orlando> yes. But since you’re supporting an approach for a fresh start, this is probably not feasible?
13:06:49 <HenryG> I am going to ask akamyshnikova and jlibosva to offer their opinions.
13:07:24 <akamyshnikova> using healing migration have such plus that would be easier get context and won't be such problem that someone forgot to run --heal. But using separate script is also acceptable
13:08:07 <akamyshnikova> rpodolyaka, what do you think do we need a separate script?
13:08:22 <salv-orlando> I thionk there are two problem with an upgrade script. None of them is a show stopper
13:08:55 <salv-orlando> 1) operators should be aware of it and execute it prior to deploying juno. If the operator is a trunk chaser it should execute it immediately before rolling any juno commit
13:09:04 <rpodolyaka> akamyshnikova: I think, no. so it would be just another migration
13:09:26 <jlibosva> salv-orlando: why it cannot be run from neutron-db-manage? but not part of migration
13:09:31 <salv-orlando> 2) discontinuity - no downgrade. Tipically people don’t. But sometimes things do not go right, so you have to.
13:09:57 <HenryG> The trickiest issue I see is that before the healing the schema is not a known thing (it depends on the config). So how can we downgrade to that?
13:10:17 <jlibosva> I guess you still have the config
13:10:18 <salv-orlando> jlibosva: I am assuming you do not want to add conditional switches in neutron-db-manage to say if you’re going past icehouse then do first the script and then resume migration
13:10:45 <salv-orlando> I was think that we don’t need to keep all those hundreds of migrations we have.
13:11:24 <salv-orlando> if you install anything past icehouse. I would have a situation like the following:
13:11:46 <salv-orlando> from icehouse upwards first run healing migration and then any other migration that it might be added
13:12:08 <salv-orlando> from icehouse backward run healing migration again, and then a single, coalesced migration from going from icehouse to havana
13:12:23 <salv-orlando> as grizzly is not supported anymore - havana can be considered starting point
13:12:36 <salv-orlando> the healing migration, being idempotent
13:12:43 <salv-orlando> can be at multiple places in the migration path.
13:13:06 <salv-orlando> I think we all agree it will be idempotent, regardless of whether it’s a migration or a script?
13:13:15 <jlibosva> right
13:13:18 <salv-orlando> meaning that if you run it twice you don’t screw your database!
13:14:36 <akamyshnikova> no, I think running it twice won't be a problem.
13:15:08 <rpodolyaka> akamyshnikova: it will probably depend on how you 'heal' the schema :)
13:15:51 <HenryG> rpodolyaka: have you seen akamyshnikova 's WIP?
13:16:27 <rpodolyaka> HenryG: I saw some patch last week. Haven't seen updated stuff yet
13:16:56 * HenryG is looking for the patch ...
13:17:15 <rpodolyaka> https://review.openstack.org/#/c/96438/2 ?
13:17:27 <akamyshnikova> the last one is this #link https://review.openstack.org/96438
13:17:33 <akamyshnikova> yes :)
13:17:40 * rpodolyaka looks
13:18:35 <rpodolyaka> akamyshnikova: I'll some comments
13:18:42 <rpodolyaka> *leave
13:19:06 <akamyshnikova> of course, all comments are welcome
13:19:08 <salv-orlando> I think the concept would be pretty much “if this table is not there create it” or “if this column is not there, create it"
13:19:27 <salv-orlando> technically not super-difficult, but surely boring as hell
13:19:43 <HenryG> So are we agreeing that we'll aim for a "healing migration" and stop calling it a script?
13:19:51 <akamyshnikova> there I use alembic that find out all differences
13:20:04 <salv-orlando> HenryG: looking at Anna’s patch it could be easily script run withing a migration
13:20:05 <rpodolyaka> salv-orlando: probably, also missing unique constraints and indexes?
13:20:21 <salv-orlando> rpodolyaka: you’re tempting my pedantry…
13:20:59 <salv-orlando> So you can have a script for people who do not wish using migrations (if there’s anybody out there who runs for instance only on autogenerated schemas)
13:21:14 <salv-orlando> and the same script being executed within the migration path
13:21:53 <HenryG> I thought we are going to remove auto-generation?
13:24:46 <salv-orlando> Yes we are.
13:24:54 <salv-orlando> until that happens however people might still do that.
13:25:27 <salv-orlando> And also I was just looking for a good excuse to give users the double option of having an offline script to heal the database as well as a migration.
13:25:41 <HenryG> OK
13:26:32 <HenryG> So I assume the removing auto-generation of db schema from models at startup: that will have to be done some time after we have committed the healing?
13:26:33 <salv-orlando> Anyway I think we can move the technical discussions around design to gerrit, since the spec is there now.
13:26:58 <salv-orlando> HenryG: I think we can do that also in parallel, do you see a reason why we shouldn’t be able to do so?
13:27:32 <jlibosva> salv-orlando: IIRC Mark told me the db scheme is not the same when using neutron-db-manage and create_all()
13:27:42 <jlibosva> because of missing stuff in migrations
13:27:43 <HenryG> salv-orlando: if it goes in before then we can skip the extra script?
13:28:29 <salv-orlando> jlibosva: anna is looking after discrepancies
13:29:33 <salv-orlando> HenryG: I guess so.
13:29:59 <HenryG> So ...
13:30:12 <HenryG> 1) fix migrations bugs currently filed
13:30:20 <salv-orlando> Honestly however the devil is in the details here, so I’d rely on the outcome of the various jenkins jobs for the patch that remove the migrations
13:30:52 <jlibosva> migrations or auto-generation?
13:30:59 <HenryG> salv-orlando: I think we have all the bugs filed
13:31:18 <HenryG> 2) remove auto-generation
13:31:38 <HenryG> 3) Supply healing migration
13:31:43 <HenryG> 4) ...
13:31:49 <HenryG> 5) Profit!
13:32:02 <jlibosva> I was hoping for that!
13:32:46 <HenryG> I am still little fuzzy on the downgrade, but let's discuss that in the spec comments.
13:32:55 <salv-orlando> What is item #4?
13:33:02 <salv-orlando> pray that everything works?
13:33:19 <rpodolyaka> :)
13:33:41 <akamyshnikova> We all agreed  about not to do downgrade for healing script, am I right?
13:33:48 <jlibosva> If we will fix all the missing parts in migrations, does it have to be in healing script then?
13:34:48 <HenryG> akamyshnikova: My fuzzy understanding is the downgrade will be a one-time special to havana only.
13:34:57 <jlibosva> imo downgrade is not worth it
13:35:55 <HenryG> What I am not clear on is juno -> icehouse downgrade
13:36:41 <salv-orlando> I was thinking that the downgrade brings you in a parallel universe
13:36:43 <salv-orlando> ;)
13:36:55 <salv-orlando> where the parallel universe has a consistent “icehouse” db state
13:37:18 <HenryG> salv-orlando: is that really a downgrade? or a slidegrade?
13:37:31 <salv-orlando> but if you do not want to break space time continuum, then just kill the old migration path, and start a new one with juno
13:37:49 <salv-orlando> whatever it is it will give you an icehouse database you can use with the software
13:37:57 <HenryG> true
13:38:00 <salv-orlando> (I don’t know what a slidegrade is)
13:38:21 <HenryG> I meant sidegrade. It wasn't very funny.
13:38:23 <salv-orlando> Is it a downgrade done with powerpoint? :p
13:38:48 <salv-orlando> I see it’s pretty much like Doc’s diagrams on back to the future I guess...
13:39:02 <salv-orlando> you go back to icehouse but it’s not the icehouse you used to kniow
13:39:20 <HenryG> The downgrade to icehouse/havana can be worked on separately?
13:39:29 <salv-orlando> yes it can I guess
13:39:37 <HenryG> If so, we can keep it on a wishlist status.
13:40:29 <HenryG> Let's concentrate our efforts on the healing migration for now.
13:41:33 <HenryG> I will update the spec
13:41:52 <HenryG> Please keep the review comments coming
13:42:15 <HenryG> Any other design questions?
13:42:30 <akamyshnikova> ok, also I hope to see some comments to my WIP change.
13:42:34 <salv-orlando> HenryG: I like the diplomatic answer to say - yes we could do that but I’d rather not ;)
13:43:43 <HenryG> salv-orlando: If I wrote that you would -1 me
13:44:23 <salv-orlando> whatever works for operators works for me anyway, so if we don’t have a requirement for downgrades from juno to havana I’m fine with doing keeping the discontinuity
13:45:18 <HenryG> Is there an operators list? Should I ask there?
13:45:33 <salv-orlando> operators@lists.openstack.org
13:45:54 <salv-orlando> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
13:45:57 <HenryG> #action HenryG to ask about downgrade requirements on operators list
13:46:15 <HenryG> salv-orlando: thanks
13:46:35 <HenryG> moving on
13:46:41 <HenryG> #topic Testing
13:47:15 <HenryG> akamyshnikova: can you update me/us on what you are syncing from oslo?
13:48:54 <akamyshnikova> it was a module that created rpodolyaka that check models and migrations synchronization. As it had to be moved from oslo to oslo.db work on this stoped.
13:49:19 <HenryG> Is oslo.db a package?
13:49:35 <salv-orlando> afaik is still “incubating” is it?
13:49:42 <rpodolyaka> it's graduated
13:50:01 <rpodolyaka> we haven't cut the first release yet
13:50:02 <salv-orlando> ah good to know, so we need to do another big port in neutron as we’re doing for oslo.messaging
13:50:23 <rpodolyaka> I hope the transition will be fairly smooth
13:50:32 <rpodolyaka> no big changes needed
13:50:36 <HenryG> rpodolyaka: when will it be released?
13:50:56 <rpodolyaka> HenryG: asap, we are waiting for a few important patches to be merged first
13:51:17 <HenryG> I would rather go directly to the package if possible
13:52:21 <HenryG> rpodolyaka: will you be introducing oslo.db to neutron?
13:52:46 <rpodolyaka> HenryG: yeah, as soon as it's released :)
13:53:29 <HenryG> OK, please keep me up to date on the progress
13:53:36 <rpodolyaka> HenryG: sure, np
13:53:56 <HenryG> #topic Meeting time
13:54:13 <HenryG> Can we move the meeting to Mondays at 1300 UTC?
13:54:21 <akamyshnikova> yes :)
13:54:32 <jlibosva> np
13:54:52 <HenryG> rpodolyaka ?
13:55:46 <salv-orlando> mondays are fine for me fwiw
13:56:10 <HenryG> Great. I will update the wiki
13:56:23 <rpodolyaka> HenryG: works for me
13:56:25 <HenryG> #topic Open discussion
13:56:50 <HenryG> If there are no further questions I will end the meeting
13:57:15 <akamyshnikova> I have no questions
13:57:15 <HenryG> Thanks everyone for your time!
13:57:41 <HenryG> See you in the spec and code reviews!
13:58:16 <HenryG> #endmeeting