17:01:21 #startmeeting Designate 17:01:22 Meeting started Wed Feb 12 17:01:21 2014 UTC and is due to finish in 60 minutes. The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:23 bye 17:01:26 The meeting name has been set to 'designate' 17:01:32 ey dns folks 17:01:32 Agenda: https://wiki.openstack.org/wiki/Meetings/Designate 17:01:55 Wow - IRC lagged like 30 seconds :/ 17:02:13 eankutse 17:02:13 Who's about today? 17:02:16 o/ 17:02:18 brb - reconnecting! 17:02:24 k 17:02:43 o/ 17:02:45 hello 17:02:55 * artom is half around. 17:03:09 here 17:03:12 reporting for duty 17:03:16 here 17:03:37 Okay - back :) 17:03:41 #topic Review action items from last week 17:03:52 First up is: vinod update the Getting Involved Section in the documentation for suggested lines of code / commit 17:04:09 vinod stepped away for 1 sec 17:04:13 I saw from the meeting logs last week that 350 was discussed, seems sane and along the times of what we discussed at the mini-summit.. 17:04:27 Ah.. Well, No worries.. Moving on 17:04:42 Next: (all) review/add new blueprints as needed to track smaller work items 17:05:01 I've personally not had a chance to break up any of the blueprints, has anyone else? 17:05:16 i have not added any blueprints ;-) 17:05:32 not yet, i have a dreakdown in my head though 17:05:37 I know ekarlso has filed a sub-BP for the pagination stuffs (to be discussed in a few mins) 17:05:54 Okay - Well, Let leave that for next week again 17:06:01 #action (all) review/add new blueprints as needed to track smaller work items 17:06:05 proably should be a standing item for a while 17:06:14 mugsie: agreed 17:06:18 yep 17:06:32 Next: Betsy and Rich to followup on incubation status wrt v2 and mini-dns 17:06:47 I talked with Anne Gentle yesterday 17:06:47 (agenda is pretty full today, hence working fast.. Tell me to slow down if needed ;)) 17:07:01 I'm in the process of writing up an email about it now 17:07:13 Should go out later today 17:07:24 cool 17:07:37 I talked with Monty, He's of the opinion that we reapply.. That V2 being in progress won't hurt us, and that MiniDNS is "The only sane way to do it" (or something along those lines) 17:07:51 I spoke to Mark (RH TC) - he says that minidns and v2 should not have an impact on incubation, and that in general designate looks good 17:08:13 Quick aside - Alex Barclay from HP, our dev manager, has been asked to start looking into designate incubation. 17:08:41 Okay.. Moving on again real quick :)\ 17:08:43 Next: Rich to document the minidns concerns on the wiki spec 17:08:45 Anne pretty much felt the same way 17:09:00 She did mention that there are already 4 projects ahead of us that have applied for incubation 17:09:02 I'm not sure if ^ got worked out in the post-meeting discussions or not, richm? 17:09:38 kiall: yeah, I still need to do some more homework before I can make intelligent comments about minidns with respect to ipa integration 17:09:41 betsy: humm - I know theres a "limit" per-cycle .. Let's leave that for next week though, I think we have too full an agenda to get into it today :) 17:09:49 ok 17:10:00 but that should not hold up minidns design/progress 17:10:03 #action kiall to review current incubation applications and new "limits" on # per cycle 17:10:14 richm: K - Thanks :) 17:10:23 #topic API v2 Pagination 17:10:47 link: https://blueprints.launchpad.net/designate/+spec/api-v2-pagination 17:10:53 or how to do that ;) 17:11:11 Okay - So, we discussed this to death before, but ekarlso is about to start work on it.. I just wanted to confirm everyone is happy with the proposed method of making this happen (marker/limit vs page/per_page) 17:11:22 yup 17:11:23 #link https://blueprints.launchpad.net/designate/+spec/storage-pagination-support 17:11:28 there ya go 17:11:53 ^ the first "Sub Blueprint" for the storage part, it's not a full spec - since it's already defined in the APIv2 spec 17:12:09 looks like marker/limit is the practice so far in Openstack 17:12:21 I'm all for code sharing/reuse 17:12:44 Yea - I asked ekarlso to review all the current APIs, the patterns they use are in the parent / main BP 17:13:32 Anyway - Has anyone got any concerns over following this pattern? Otherwise, we can press on with getting the Storage layer updated with this. 17:13:49 none from me 17:13:54 +1 17:13:56 agree 17:14:14 Okay - I'll mark the sub-BP as approved, and we'll get it started : 17:14:43 ok! 17:14:48 #topic Review abstract proposals for Openstack Summit in Atlanta 17:14:52 see ya folks for today ;) 17:15:10 ekarlso: hope your not late to pick her up ;) Enjoy! 17:16:07 So - I've not written an abstract for the talk I was supposed to (sorry!) a mix of time constraints, and I'm not confident there's enough content to have a whole talk on it. 17:16:34 I know Tim and Graham have both written abstracts, do you guys have links handy? 17:16:43 I believe this is tims: https://docs.google.com/a/managedit.ie/document/d/1xIprT3xEzujFPWJhVGnIKRdsB7gkmpgTgo0DfG3Ml4s/edit 17:17:23 Abstract for the workshop 17:17:26 #link https://wiki.openstack.org/wiki/Designate/Atlanta/Workshop_1 17:17:27 #link https://docs.google.com/document/d/1xIprT3xEzujFPWJhVGnIKRdsB7gkmpgTgo0DfG3Ml4s/edit?usp=sharing 17:17:34 mugsie: do you have your link handy? 17:17:38 #link https://docs.google.com/document/d/1D6FcXMiWMvFTIggWiRu3VajVTnerCFDErTdafcSyxl0/edit?usp=sharing 17:18:05 We start at Tims and work our way donw? 17:18:08 down* 17:18:13 Tim's looks good to me - does it overlap with kiall's or mugsie's? 17:18:43 richm: mine is non-existant, there's not enough unique content IMHO, and I failed to find enough time to write it. 17:18:46 a little with mine, but n ot too much 17:19:07 One overlap is about the Nuetron floating IPs 17:19:47 yeap. i think it is from 2 different view points though 17:19:47 #link https://etherpad.openstack.org/p/DesignateAustinWorkshop2014-01 17:19:51 ^ the original outlines 17:20:06 kiall: they are on https://wiki.openstack.org/wiki/Designate/Atlanta 17:20:10 #link https://wiki.openstack.org/wiki/Designate/Atlanta 17:20:17 Ah - I missed that page 17:21:21 so, any changes to tims? 17:21:26 I personally think Both Tim's and Grahams abstracts are good, and that "Talk 3", then one I was supposed to write (sorry :() should have the Mini-DNS / NSUpdate detail piece merged into Grahams 17:22:08 Sounds good to me 17:22:32 Maybe Tim's can be a little more focused 17:22:39 Yeah. I think that works 17:22:43 One question about the abstracts, should we put all of our "wood behind one arrow", e.g. pick one talk? 17:22:46 it looks pretty broad 17:23:04 i think seen as there is only 2 being submitted, we should be ok 17:23:15 mugsie: agree 17:23:19 What about the proposed workshop? 17:23:35 2 talks + workshop = 3 17:23:38 i think that stands on its own merits 17:23:41 Workshop proposal looks perfect :) 17:23:41 I think we should still propose that, as it's in a separate bucket, so to speak 17:24:06 Yea - I absolutely think the WS is a great idea. 17:24:16 i see tims abstract as an updated version of what kiall gave in Hong Kong 17:24:38 mugsie: so you think the breath of it is fine 17:24:39 ? 17:24:55 s/breath/breadth 17:24:55 mine is aimed at operators, and your workshop is aimed at anyone who is interested 17:25:01 ok 17:25:02 i think so... 17:25:07 k 17:25:10 but I am open to correction 17:25:25 that sounds good 17:25:31 mugsie: I think you're correct 17:25:35 eankutse: I think so, 1 general "What we do, general arch, general direction" is useful for giving a good overview.. WIth another being aimed more at people already sold on the concept of designate 17:26:05 kiall: yes 17:26:40 yeah, I think Graham's is more in depth in a few topics which would be of primary interest to operators and developers with an interest in DNS 17:26:59 These are due Friday from memory.. I think we should sync up again tomorrow at 17:00 UTC (same as this meet) for an hour to do any final cleanups, and walk through the submission. 17:27:02 any changes to the workshop? i think is looks good - what we are trying to get across 17:27:14 (Not intending to stop the discussion now with ^, just getting it out there) 17:27:28 well, see if there is any changes people want 17:27:59 1 other point we discussed was giving the talks jointly between the various companies... Who's still up for that? 17:28:08 +1 17:28:11 +1 17:28:15 I am - looks like I am going 17:28:16 (We need presenter names for the submissions) 17:28:16 #agree 17:28:27 We should try to appoint at least 2 people (one from each organization) to run the talks 17:28:54 Joint presentations will help incubation, I agree 17:29:22 +1 17:29:27 I would like to participate on talk 1. 17:29:27 +1 17:29:30 Okay .. So HP/RAX/RH all up for that? Why don't we let Tim and Graham decide on who they want for their talks? And the WS would be a free-for-all, since hands on deck will be useful 17:29:54 kiall: sounds good 17:30:14 +1 - I would be happy to do either one 17:31:10 From RAX perspective, we don't have approval yet on who all is attending. So lets plan to put my name on things for now (might change). 17:31:23 ^ for all the Rackspace participation that is. 17:32:07 How about this: RedHat + RAX for talk 1 (with a cameo from Kiall) 17:32:20 jmcbride: any idea when you'll find out? 17:32:27 kiall: nope 17:32:37 Ok 17:32:59 for talk two, it would be cool to see Mugsie lead it, with backup from ?? 17:33:16 i am open to suggestions 17:33:38 I think you could probably get 3 on talk 1 - its more topics, that can be broken down 17:33:51 mine splits into 2 i think 17:33:56 jmcbride: Sounds good for Talk 1.. I'd actually like to take a back-seat and let you guys give the meat of the presentations :) 17:34:30 kiall: I think your contributions thus far speak for them selves… Designate is your legacy :) 17:34:53 One of the reasons I'd like all you guys to be main faces of these ;) 17:35:04 Kiall should do a "live" from-scratch demo :-) 17:35:11 could I suggest RAX + richm + (short bit of) kiall for Talk 1? 17:35:17 It is noble for you to back-seat for a little - I still expect we would reference your prior talks and point accolades where they belong. 17:35:23 eankutse: lol .. happy to. I'll get it right this time :P 17:35:29 :-) 17:35:39 +1 mugsie on could I suggest RAX + richm + (short bit of) kiall for Talk 1? 17:35:40 works for me 17:36:00 +1 on live demo! 17:36:15 SO .. That'd be tim (assuming approval) / richm with a teeny bit from me on T1? I'm happy with that.. 17:36:40 and then me + 1 RAX for talk 2? 17:37:00 Names came be changed later for these BTW.. But better to get a general idea before they are submissted 17:37:02 submitted* 17:37:08 mugsie: yes 17:37:12 Is Artom going? 17:37:33 I think he said he wasn't going to be able to.. Not 100% sure. 17:37:34 Haha. 17:37:35 No. 17:37:35 What about Ron? 17:37:46 i'm going to try and be there. 17:37:59 Unless I pay for my own stuff, I suppose. 17:38:09 rjrjrj_: would you like to work with mugsie on talk 2? 17:38:32 that sounds okay. let me get an okay to go in the next couple of days. 17:39:05 cool 17:39:13 Okay .. So lets say, mugsie + rjrjr_ will give T2, failing approval for rjrjr_, mugsie + someone else to be decided later? 17:39:20 bingo 17:39:37 Cool. 17:39:39 artom: too bad :( 17:39:50 Sounds good 17:40:05 artom: :( 17:40:45 Okay - Let's move on for the moment, and come back tomorrow with the 2 talk proposals tweaked and names on them.. We'll regroup 17:00 UTC tomorrow for an hour to get the final things tweaked and submitted? 17:40:55 That time work for people/ 17:40:57 ?* 17:41:04 yes 17:41:05 yup 17:41:20 yes 17:41:30 (The WS propose looks good as is, and will probably just have a whole pile of names on it..) 17:41:45 perfect 17:41:50 #action Regroup on Talks+WS at 17:00 UTC tomorrow (Thursday) 17:42:05 #topic import-tlds - right place to put it 17:42:37 Like we talked yesterday 2 of the issues with the current import-tlds in designate is that (1) you need ssh access to the box where central and designate run (2) The user running import-tlds is not logged 17:42:48 we talked about having a bulk api for import-tlds to overcome these 2 issues 17:42:55 Joe mentioned that apart from the bulk api, he wanted the current tool as is for (1) initial population of the tlds when a new Designate system is up. (2) an easy way to import TLDs for people trying out Designate. 17:43:04 Joe do you have any other comments to add on this? 17:43:15 I think we discussed this in #openstack-dns yesterday, where we talked about how designate-manage might be the wrong place (for accountability). And came to the conclusion that we leave it there for now, and replace it once we have bulk API actions (which can be applied to the TLD apis too..) 17:43:21 or .. ^ what he said ;) 17:44:19 I'm thinking everyone is in agreement on those points already? 17:44:27 kiall: i agree 17:44:33 hub_cap: good for you. 17:44:34 :P 17:44:37 :) 17:44:50 sounds good 17:45:00 You know you just agreed to being our b*tch for the next cycle? 17:45:03 ;) 17:45:16 vinod / jmcbride ? 17:45:45 o/ 17:45:49 nothing else from me 17:45:53 checking with Joe 17:46:43 Okay - Let's assuming it's a "Yes" and come back at the end if it's not :) 17:46:47 Joe agrees too 17:46:50 Getting close on time ;) 17:46:57 #topic API v2 Structured Record Format 17:46:59 hub_cap, Betsy is about to get medieval on yah! 17:47:01 #link https://wiki.openstack.org/wiki/Designate/Blueprints/APIv2StructuredData 17:47:10 jmcbride: :) 17:47:19 #link https://blueprints.launchpad.net/designate/+spec/api-v2-structured-data-format 17:47:42 #link https://review.openstack.org/#/c/71944/ (<-- Very much WIP, started as an experiment) 17:48:05 I have to admit I haven't had time to review them 17:48:38 I've been following the WIP. I need to look at the latest updates 17:48:39 This starts getting the APIv2 structured format in place, and as part of it, happens to make the RRType's into plugins. 17:49:01 eankutse: there's not too much new, other than the very experimental wire protocol stuff was killed. 17:49:16 k 17:49:33 I'm just bringing it up as it looks like the pattern I started with will work, so, we should review and see if anyone has concerns. 17:49:47 so the intent is to make it possible for a given installation to pick and define what RR types they support? 17:49:51 (Not expecting people to have read it yet - just finished writing the BP wiki a hour or wo ago) 17:50:17 eankutse: It's a mix of that, and allowing for both the string and dict representations of each RRType in the API 17:50:55 Implementing them together was really the "only way", as both really depend on each other. 17:51:06 thx 17:51:44 Anyway - Just wanted people to know that was there ^, and that it'll be in a decent shape to discuss properly next week.. Please have a look :) 17:52:02 kiall: sounds good 17:52:03 Is the string type needed for some sort of legacy application? 17:52:46 richm: the string type is often simpler to copy and paste from various docs etc, and is what some people are familiar with.. 17:52:54 Ok 17:53:14 Take someone setting up Google Apps - The number of SRV recrods to get Google Talk going is huge (about 10) 17:53:30 most people will have no clue which of the example records map to the actual fields 17:54:30 6 mins left.. Rushing, We'll come back to that next week.. 17:54:31 #topic Mini-DNS, what next? 17:54:53 So - The big-one with like 6 mins to go.. Perfect ;) 17:55:05 :) 17:55:16 Overflow into #openstack-dns afterwards? 17:55:22 I think this falls under the 'big pcture bp' idea 17:55:35 where one person drives it, and has side meeting 17:55:39 I think, the next steps are to take all the discussions we had at the mini-summit, and get the mini-dns BP updated with some implementation details.. 17:56:22 yes 17:56:37 +1 17:56:42 And also with perceived issues 17:56:44 #action kiall to condense mini-summit dicussions into MiniDNS spec 17:56:47 for further consideration 17:56:56 (multiple specs ;)) 17:57:01 We also need to decide on DIY or dnspython .. I'm of the opinion that DIY is going to give us the best results with the least pain .. 17:57:17 mugsie: overall vision spec ;) Implementation will be small pieces :D 17:57:28 kiall, why ditch dnspython? 17:57:40 can we salvage it at all? 17:57:50 Not to shoehorn it everywhere, but if it can be useful in places... 17:58:18 so dnspython + some glue code? 17:58:32 eankutse, I think it needs more than glue ;) 17:58:40 Not ditch it per-se, just not necessarily use it for this piece. It's API is quite.. clunky.. and we're going to end up doing mappings all over the place between DNS Python objects, and ours. 17:58:41 agree 17:58:44 I thought there was some concern about the reliability of dnspython 17:58:44 But it can handle some of the to/from wire stuff. 17:59:25 dnspython seems like the correct direction. 17:59:36 1 minute left 18:00:04 betsy: I'm personally pretty sure dnspython will be reliable.. I think it's the awkwardness of the API, combined with it having much more than we need in there, and the conversions between DNS Python objects and our own.. Performance wise, I think we're going to do better DIY 18:00:11 Lets move to #openstack-dns 18:00:16 #endmeeting