18:00:57 <SlickNik> #startmeeting trove-bp-review
18:00:58 <openstack> Meeting started Mon Jun 23 18:00:57 2014 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:01 <openstack> The meeting name has been set to 'trove_bp_review'
18:01:26 <SlickNik> Agenda at:
18:01:31 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting#Agenda_for_Jun_23
18:01:59 <SlickNik> Giving people a few minutes to show up.
18:02:02 <boden> o/
18:02:39 <dougshelley66> o/
18:02:43 <glucas> o/
18:02:43 <amrith> 0/
18:02:45 <kevinconway> o/
18:02:51 <peterstac> o/
18:02:53 <amcrn> o/
18:02:53 <esp> o/
18:02:53 <iccha1> o/
18:02:57 <grapex> o/
18:03:02 <tvoran> o/
18:03:02 <schang> o/
18:03:18 <SlickNik> Okay, let's get started.
18:03:21 <cp16net> hio
18:03:37 <SlickNik> #topic Heat integration
18:03:48 <SlickNik> #link https://blueprints.launchpad.net/trove/+spec/full-heat-integration
18:03:50 <vgnbkr> o
18:04:22 <SlickNik> denis_makogon?
18:04:33 <amrith> he's not online
18:04:37 <amrith> not even away ...
18:04:55 <SlickNik> hrm, also it seems to me that we discussed this last week and there were a couple of concerns.
18:05:00 <kevinconway> did you check dmakogan_ipod?
18:05:09 <SlickNik> There was a mailing list topic about it as well.
18:05:34 <SlickNik> Let's move on.
18:05:54 <SlickNik> I'll follow up with him offline if he had some specific question regarding it.
18:06:06 <SlickNik> #topic Configurable DB plugins
18:06:22 <SlickNik> #link https://blueprints.launchpad.net/trove/+spec/configurable-db-plugins
18:06:26 <boden> that's mine... BP in full is here: https://wiki.openstack.org/wiki/Trove/ConfigurableDBPlugins
18:06:35 <boden> anyone get a chance to review?
18:06:37 <SlickNik> #link https://wiki.openstack.org/wiki/Trove/ConfigurableDBPlugins
18:06:42 <SlickNik> boden: I did.
18:07:19 <SlickNik> Also had a chance to bounce some ideas off of a couple of other folks regarding this.
18:07:23 <boden> SlickNik -- comments / concerns / etc?
18:08:38 <dougshelley66> boden - i had that question last week about whether other projects were doing this. Don't know if you had a chance to look into that
18:08:58 <SlickNik> Had a couple of concerns: 1. Can you define a scenario that uses this? I understand the part about the custom schemas, but what good would it do if trove wasn't aware of the said schemas.
18:09:01 <boden> dougshelley66 -- I didn't see others doing this
18:09:10 <SlickNik> And 2. Are there other OS Projects doing this.
18:09:15 <mriedem> does anyone here know if there was a conscious decision to make trove_api_workers default to None rather than 1 like trove_conductor_workers?
18:10:03 <vgnbkr> boden: why could the extra data not just be stored in a separate database?  Why does Trove need to address this?
18:11:56 <boden> SlickNik -- re (1); adding a in-house extension / plugin which builds on trove... for example db logs which maintains details about when logs where captured... yes i know there is such a bp already, but for sake of arg one could add an API extension for it and then add db plugin to support the schema by leveraing trove's based sqlalchemy framework rather than re-implementing
18:13:07 <boden> SlickNik  #2 -- haven't seen it done elsewhere
18:14:39 <SlickNik> I'm also a bit concerned about migrations. You do mention a path for migrations of custom tables. But my concern is around the custom migration scripts clobbering / overriding the schemas we're creating during normal trove migrations, which would end up causing subtle bugs.
18:14:53 <grapex> boden: I think I get what you're saying, but I think it would be difficult to make a facility like that upstream that would be as flexible as you'd want. You'd find yourself having to go back upstream for every tweak, and each time you'd be bombarded by questions which you (in my guess) wouldn't be able to give examples / reasons for. It would probably take just as long as if you made a seperate database and the featu
18:14:53 <grapex> re wouldn't be easily understood.
18:15:49 <vgnbkr> My concern with this is that it closely couples trove implementation to user implementation.  These sorts of changes would make it difficult for Trove to change its implementation in the future, for no real benefit to Trove.
18:16:42 <vgnbkr> There may be cases where functionality is not possible without Trove support, but this just seems like a convenience feature.
18:17:05 <SlickNik> vgnbkr: agreed.
18:17:31 <SlickNik> I think this requires some cross-openstack discussion as well.
18:17:58 <SlickNik> The way we do sqlalchemy migrations is consistent with the rest of the OpenStack projects and has wider implications.
18:18:23 <boden> SlickNik -- in my PoC the plugins were totally separate tables in the database so overall seems low risk, however I can take these comments and re-think for next week
18:19:25 <boden> vgnbkr -- it does couple at the api /session level, but not higher... it allows those lower-level abstractions to leveraged easily to build upon whats in upstream trove core
18:20:02 <boden> SlickNik + vgnbkr; let me think on this for another week and we can revisit again next week... I've been side-tracked a bit lately on some non-openstack work so need to re-group
18:21:26 <SlickNik> boden: Sounds good. Can you perhaps also send out a thread on the ML asking for some cross-project feedback for this (or revive the old one?). I'd be curious to see what folks from other OS projects think about this.
18:22:42 <boden> SlickNik -- sure... just so we are on the same page tho; I'm talking about leveraging the sqlalchemy abstrations at the api/session level... these have not changed for awhile
18:23:44 <SlickNik> boden: yes, I understand.
18:23:47 <vgnbkr> boden: Right, but what if next year Openstack decides to use some other technology besides SqlAlchemy?
18:23:48 <SlickNik> boden: Thanks!
18:24:50 <cp16net> is that it?
18:25:14 <boden> cp16net - for my BP yes... I will take up deeper discussion off-line
18:25:18 <SlickNik> vgnbkr: That's a whole separate can of worms, and has been discussed at a couple of previous summits IIRC. (Folks decided against it IIRC)
18:25:35 <SlickNik> #topic Open Discussion
18:25:44 <cp16net> boden: sounds godo
18:26:13 <SlickNik> Did anyone have anything for open discussion related to BPs?
18:26:13 * mriedem didn't realize this was a meeting :)
18:26:27 <boden> I have question about implementing a BP... a bit off topic but I have your attention :)
18:27:25 <boden> I'm implementing https://blueprints.launchpad.net/trove/+spec/pluggable-conductor-manager which is effectively a new conductor conf property... do we need UTs for this? I haven't see trove or others really testing these via UTs
18:27:54 <SlickNik> boden: Let's talk about that after the meeting.
18:28:06 <SlickNik> That's all for now.
18:28:09 <SlickNik> #endmeeting