19:00:55 <dripton> #startmeeting db
19:00:56 <openstack> Meeting started Thu May 23 19:00:55 2013 UTC.  The chair is dripton. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:58 <boris-42> probably we should call devananda
19:01:01 <openstack> The meeting name has been set to 'db'
19:01:02 <boris-42> devananda ping
19:01:09 <devananda> pong
19:01:26 <boris-42> hi how are you?) have you a little bit time to discuss work around db?)
19:01:31 <devananda> ah! right. yes, sure :)
19:01:38 <boris-42> nice
19:01:45 <dripton> #topic havana-1
19:01:55 <dripton> Anyone have anything they're trying to get in for havana-1 that needs more eyes?
19:02:01 <boris-42> I would like to finish db-improve-archiving in H1
19:02:28 <boris-42> so devananda could you take a look at it pls?)
19:02:35 <dripton> boris-42: Are you just waiting for approvals?
19:02:42 <boris-42> yes=)
19:02:53 <boris-42> I fixed bug around indexes
19:03:10 <devananda> boris-42: it seemed (perhaps mistakenly) that the fix-old-migrations migrations went through several revisions
19:03:40 <devananda> i didn't follow too closely. was much being changed?
19:03:48 <boris-42> yes
19:03:53 <boris-42> there was a lot of changes
19:04:06 <boris-42> and I have copy pasted some of it
19:04:54 <devananda> k. action me to go review those pls :)
19:05:14 <dripton> reviews from others are helpful too even without +2 powers.  Some of the core reviewers wait until they see several +1s before they bring in their +2s
19:05:43 <devananda> indeed
19:05:47 <boris-42> yeah=)
19:05:55 <dripton> #action devananda to review db-improve-archiving patches.
19:06:29 <dripton> #topic bugs
19:06:42 <boris-42> Btw there are some new guys in our db team probably they also would like to say something
19:06:55 <dripton> #topic new people
19:06:59 <boris-42> yeah
19:07:05 <boris-42> hey guys are you here?)
19:07:12 <rpodolyaka> yep, Boris
19:07:20 <viktors> here
19:07:33 <devananda> o/
19:07:34 <rpodolyaka> I've been recently working on getting common Oslo DB code into Cinder
19:08:13 <rpodolyaka> and helping Boris with testing for db-improve-archiving
19:08:30 <rpodolyaka> I hope we can use this in other projects too when it's ready
19:08:51 <rpodolyaka> I have a few ideas to work in Nova and Quantum as well
19:09:03 <viktors> at the moment I'm working om rename all unique consraints in Nova database
19:09:24 <rpodolyaka> for Nova I would really like us to switch to Alembic, which seems to be quite superior tools comparing to SQLAlchemy-Migrate
19:09:42 <rpodolyaka> especially for maintaining of stable branchaes
19:09:44 <dripton> rpodolyaka: +1 on alembic, I tried fighting that fight in Grizzly.  But it's a huge disruptive change.
19:10:08 <rpodolyaka> dripton:  indeed
19:10:18 <devananda> if some of these things (oslo-db, alembic) will make Ironic development easier
19:10:36 <devananda> i'm happy to accept folks' patches to start making it happen from the ground up
19:10:41 <dripton> rpdolyaka: I have some code to 90% convert migrate migrations to alembic migrations, but the transition from one to the other is painful.
19:11:04 <dripton> devananda: so you're not doing db migrations in ironic at first.  How are you populating the DB?
19:11:35 <devananda> dripton: eh, i copied the existing migration code from nova. that said, i am not doing any _data_ migrations in ironic
19:11:38 <devananda> until we approach an RC
19:12:03 <dripton> devananda: ok, now I understand.  Seems reasonable since nobody needs to upgrade from 0.0001 to 0.0002
19:12:08 <devananda> right
19:12:18 <devananda> once we have an RC, we'll need a nova_bm -> ironic ETL tol
19:12:20 <devananda> tool
19:12:23 <devananda> and then have to worry about data
19:12:57 <dripton> viktors: Are you finding problems with the unique constraints as you go through them?
19:13:30 <boris-42> victors could you give us link to patch in oslo
19:13:39 <viktors> 1 min please
19:14:44 <viktors> It's path to Oslo to proceed error messages from db to human-readable view https://review.openstack.org/#/c/29888/
19:15:23 <viktors> It's migration to nova database https://review.openstack.org/#/c/30108/
19:16:00 <dripton> viktors: I will take a look at both.
19:16:17 <viktors> thanks )
19:16:32 <dripton> Are any of the new people PostgreSQL people?
19:16:43 <rpodolyaka> dripton: on transition to Alembic. It probably sounds crazy. But maybe it makes sense to maintain both Alembic and SQLAlchemy-Migrate migrations till we release Havana (thus providing a way for users to upgrade to it) and then drop SQLAlchemy-Migrate support?
19:17:26 <dripton> rpodolyaka: I think there would be resistance to the double maintainence, unless we could automate converting one to the other.  But that might work.
19:17:59 <eyerediskin> some db-api-tests waiting for +2 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/db-api-tests,n,z
19:18:54 <dripton> eyerediskin: awesome.  If we can pile some more +1s on them then the +2s will follow.
19:19:17 * dripton heard crickets in response to postgres.
19:19:23 <dripton> #topic bugs
19:19:35 <dripton> Nova had a bug day yesterday.  Did anyone find/fix any nasty DB bugs?
19:20:00 <boris-42> my migrations fix=))
19:20:09 <dripton> boris-42 wins.
19:20:52 <boris-42> ^_^
19:20:53 <uvirtbot> boris-42: Error: "_^" is not a valid command.
19:21:00 <dripton> I'm chasing a bug in db-archiving where the instances table doesn't all get archived, I think due to FK constraints.
19:21:13 <dripton> And trying to fix the postgres tempest gate which has been broken for a couple of weeks.
19:21:24 <devananda> are FKs enabled by default in production?
19:21:39 <devananda> i thought we had disabled them last year ...
19:21:59 <dripton> devananda: good question.  They're enable on the QA box that found this bug, but maybe that's not a real production config.
19:22:26 <devananda> k. either way, archiving shouldn't break because FK are on :)
19:22:27 <eyerediskin> default production config != real prioduction config
19:22:51 <dripton> devananda: right, and in my tests it doesn't break, but QA people can break anything.
19:23:15 <dripton> No other bugs that anyone needs help with?
19:23:27 <dripton> #topic blueprints
19:24:00 <dripton> boris-42 did you want to talk about other blueprints for havana?
19:24:16 <eyerediskin> how about to move @require_context/@require_admin_context from db/sqlalchemy/api.py to db/api.py?
19:24:29 <boris-42> yeah eyerediskin +1
19:24:57 <boris-42> eyerediskin could you pls describe why it is so important
19:25:03 <dripton> Does that help reduce code for the mysql fast path?
19:25:50 <eyerediskin> that help reduce code for other backends
19:25:58 <eyerediskin> a little)
19:26:13 <dripton> Is there a blueprint for it?  Or a patch?
19:26:16 <eyerediskin> nope
19:27:01 <dripton> If you do a blueprint then that'll smooth getting the patch approved.  It can be a very short one since it's such a simple change.  Or I guess it can be part of the existing bp for an alternate backend.
19:27:32 <boris-42> no dripton
19:27:47 <dripton> ?
19:27:52 <boris-42> I would like to explain a little bit more
19:28:12 <boris-42> comstud is working on mysql-db-impl
19:28:24 <comstud> mysqldb-db-impl
19:28:33 <comstud> (to clarify)
19:28:33 <boris-42> yeah=)
19:29:04 <boris-42> so we would like to remove contex from db.sqlalchemy.api layer to db.api layer
19:29:32 <boris-42> so we will avoid copy paste of tons of context
19:29:49 <boris-42> I mean @require_context and @require_admin_context..
19:30:28 <dripton> makes sense to me
19:30:41 <dripton> #topic open discussion
19:30:52 <dripton> anyone have anything else?
19:31:14 <boris-42> comstud what do you think about it ^
19:31:34 <comstud> Say again?
19:31:43 <comstud> Oh yeah...
19:31:50 <comstud> i moved some things already
19:31:58 <comstud> The problem with those decorators are...
19:32:02 <comstud> they assume model level API calls
19:32:14 <comstud> mysqldb stuff is all OOP, so they don't work
19:32:18 <comstud> because there's the extra 'self' argument.
19:32:47 <comstud> btw... I'm also in the process of splitting up sqlalchemy/models.py to support objects.
19:32:56 <comstud> I dunno how that affects the other work.. or if I'm duplicating effort.
19:33:12 <comstud> ie models.py -> models/base.py (or __init__.py)
19:33:15 <comstud> and then models/instance.py etc
19:33:24 <boris-42> ooO
19:33:26 <boris-42> =)
19:33:33 <devananda> comstud: i'm interested to see how you're doing that
19:33:41 <devananda> and see if i can use that in ironic
19:33:46 <devananda> rather than add it on later
19:33:50 <comstud> Cools
19:34:00 <comstud> I really just started this work today...
19:34:02 <boris-42> could I ask why do you that comstud?)
19:34:09 <comstud> I have a patch to remove module imports from models.py that I can throw up anytime
19:34:16 <comstud> boris-42: Sure
19:34:24 <comstud> I thought this layout would be clean:
19:34:27 <comstud> instance.py contains:
19:34:31 <comstud> the sqlalchemy model
19:34:37 <comstud> the Instance internal object
19:34:44 <comstud> that Instance internal object will have:
19:34:47 <comstud> @classmethod
19:34:50 <comstud> def get_by_uuid()
19:35:10 <comstud> this will break up that huge mess in api.py
19:35:24 <comstud> and separating it into separate files seemed like a good thing
19:35:52 <boris-42> so we will move from facade pattern to teach models=)
19:35:53 <comstud> That make sense?  Might be more clear when I get some WIP patches up :)
19:35:57 <boris-42> reach*
19:36:05 <dripton> looking forward to seeing the patches
19:36:27 <boris-42> so we will have in all models, methods that works with this model?
19:36:46 <boris-42> instead of one file with tons of methods?
19:36:58 <boris-42> comstud ^
19:37:06 <comstud> yeah
19:37:13 <comstud> methods will be on the object classes instead
19:37:37 <boris-42> so we will be able to switch models and use different backends?
19:37:38 <devananda> and for methods that interact with multiple models?
19:37:45 <boris-42> we will chose one=)
19:38:05 <comstud> right
19:38:07 <comstud> well
19:38:08 <boris-42> math.random(l)
19:38:09 <comstud> switch objects
19:38:14 <comstud> if I understand what you're saying
19:38:26 <boris-42> some other backend implement
19:38:30 <comstud> right
19:38:39 <comstud> that's what I'm trying to figure out right now with objects...
19:38:43 <boris-42> by the way we have to do something with tests..
19:38:52 <dripton> how do we ensure that all backends implement the same methods?
19:38:59 <boris-42> tests
19:39:03 <boris-42> tons of tests..
19:39:04 <comstud> dripton: tests that compare the backends
19:39:05 <comstud> :)
19:39:15 <dripton> that is the Pythonic answer
19:39:33 <boris-42> we have already tons of tests in test_db_api
19:39:50 <boris-42> oh they all should be then rewritten… to provide your changes comstud..
19:40:17 <boris-42> one more ton of code..
19:41:04 <dripton> Anyone have anything else?
19:41:28 <dripton> Thanks everyone, and remember to review patches!
19:41:31 <dripton> #endmeeting