18:00:37 #startmeeting trove-bp-review 18:00:38 Meeting started Mon Jul 28 18:00:37 2014 UTC and is due to finish in 60 minutes. The chair is cp16net. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:41 The meeting name has been set to 'trove_bp_review' 18:00:52 o/ 18:00:57 o/ 18:00:57 o/ 18:01:00 0/ 18:01:07 o/ 18:01:19 o/ 18:01:22 btw i'm filling in for SlickNik today 18:01:25 o/ 18:01:32 #link https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting 18:01:32 o/ 18:01:54 looks like we have one blueprint to talk about from boden 18:02:04 #topic Dynamic extension loading using stevedore 18:02:28 #link https://blueprints.launchpad.net/trove/+spec/dynamic-extension-loading 18:02:41 boden: take it away 18:03:07 I think the BP wiki describes it in full #link https://wiki.openstack.org/wiki/Trove/DynamicExtensionLoading 18:03:30 the idea is to use stevedore to load our api extensions to permit consumers to bind in extensions outside the current single path mechanism 18:04:13 note -- a concern posed by Denis on the email list #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/041363.html 18:04:46 the concern is if we are moving to pecan (or something else like falcon) is it worth refactoring this extension discovery and loading right now 18:05:08 do we have any idea when that is going to happen? 18:05:21 i *think* those are separate concerns 18:05:28 I say extensions should be separate 18:05:33 sounds like it.. pecan would still require stevedore 18:05:34 we talked about this in Atlanta and said it wasn't anytime soon. 18:05:55 in the email it was suggested pecan in the "K" timeframe 18:06:23 that suggestion has been made in two contexts now, and it would be a good thing to either ratify it as the official position, or shut down the rumor. 18:06:37 it was also suggested in the context of the WSGI email thread. 18:06:48 maybe someone on core could opine on this 18:07:11 IMO -- if by moving to pecan we are saying extension discovery / loading chagnes then I agree; maybe we hold off... however I tend to think the discovery / loading is separate from pecan but would need to investigate more 18:07:23 boden: everything looks good, only on your POC you are changing an openstack oslo lib, other than that it looks clean 18:07:24 Seems like our typical dilemma- we want to make Trove better but are told some future OpenStack framework will change everything we do so we shouldn't even begin. :( 18:08:04 boden: +1 they should be separate things 18:08:12 grapex: I think you made a reasonable point on that topic in the metadata thread last week 18:08:23 we can always refactor if/when pecan lands 18:08:29 peterstac: +1 18:08:33 peterstac: +1 18:08:43 grapex: +1 18:08:47 robertmyers: +1 18:08:51 boden: +1 18:08:52 amrith: +2 18:08:54 vipul: +1 18:08:55 I do have 1 open question on this BP tho 18:08:55 amrith: +1 18:08:56 To be clear, I don't like the idea of saying "wait, maybe Pecan won't support this." I think good code is flexible 18:08:58 so that's a total of +4 18:09:05 ;) 18:09:12 is denis_makogon around ... 18:09:13 amrith: Too bad! We're going to use up this half-hour come hell or high-water! 18:09:18 the open question is on backwards compat (for upgrade and the like)... 18:09:19 j/k! 18:09:35 I guess not 18:09:54 In the BP wiki I proposed a few ideas... seems liket he safest is to leave the existing loading by path in the code and only load extensions from path when they have not been loaded via stevedore 18:09:55 thoughts 18:09:55 boden: i'm not sure i understand what you are ask 18:10:19 boden: ah, since this was deperecated years ago in oslo, I think it is safe for us to change 18:10:21 lol 18:10:26 OK 18:10:55 any other questions / concerns? 18:11:07 if you can destroy all the history of the previous version 18:11:11 :) 18:11:20 ha 18:11:26 if building a new package means the extensions continue to load.. then we don't need ot worry about backwards compat 18:11:57 i think we all have been wishing for this change for a while now 18:12:03 vipul - yes true from a trove proper perspective... but if consumers had copied "custom" extensions into the extension path they will not be loaded 18:12:40 IMO that's a case we shoudln't need to handle.. if you have private code.. it's your responsibility to retrofit that code in whatever way needed 18:12:51 vipul: +1000 18:12:53 vipul: +1 18:13:07 vipul: +1 18:13:11 this is not an api contract 18:13:54 just we never cleaned up after it was deprecated in oslo 18:14:06 so this is our bad 18:14:12 ok 18:14:14 so we should vote on this... 18:14:41 choices are +1 or -1? 18:15:13 amrith: +1, -1, or +1_or-1_based_on_future_conversations 18:15:30 #startvote Dynamic extension loading using stevedore? Yeah, Naw, maybe_later 18:15:31 Begin voting on: Dynamic extension loading using stevedore? Valid vote options are Yeah, Naw, maybe_later. 18:15:32 Vote using '#vote OPTION'. Only your last vote counts. 18:15:42 #vote Yeah 18:15:43 Yeah 18:15:44 #vote Yeah 18:15:46 #vote Yeah 18:15:48 #vote Yeah 18:15:49 #vote Yeah 18:15:49 #vote Yeah 18:15:51 #vote Yeah 18:15:52 #vote Yeah 18:16:01 #vote Yeah 18:16:04 cp16net: One option should've been Alright alright 18:16:08 boden can't vote ;) 18:16:17 sorry 18:16:25 isn't that a conflict of interest thing ... Just kidding. Boden can vote ;) 18:16:45 candidates cast their own ballots too ;) 18:16:48 * cp16net waits for more votes 18:16:57 #vote Yeah 18:16:57 * robertmyers waits for cp16net 18:17:12 #endvote 18:17:13 Voted on "Dynamic extension loading using stevedore?" Results are 18:17:14 Yeah (9): boden, robertmyers, amrith, peterstac, tvoran, cp16net, vipul, dougshelley66, grapex 18:17:22 nice 18:17:34 looks like that was all thats on the agenda 18:17:39 thanks for playing 18:17:47 well done cp16net 18:17:49 #endmeeting