17:01:21 <kiall> #startmeeting Designate
17:01:22 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:23 <Sukhdev> bye
17:01:26 <openstack> The meeting name has been set to 'designate'
17:01:32 <ekarlso> ey dns folks
17:01:32 <kiall> Agenda: https://wiki.openstack.org/wiki/Meetings/Designate
17:01:55 <kiall> Wow - IRC lagged like 30 seconds :/
17:02:13 <eankutse> eankutse
17:02:13 <kiall> Who's about today?
17:02:16 <mugsie> o/
17:02:18 <kiall> brb - reconnecting!
17:02:24 <eankutse> k
17:02:43 <betsy> o/
17:02:45 <richm> hello
17:02:55 * artom is half around.
17:03:09 <msisk> here
17:03:12 <jmcbride> reporting for duty
17:03:16 <rjrjr_> here
17:03:37 <kiall> Okay - back :)
17:03:41 <kiall> #topic Review action items from last week
17:03:52 <kiall> First up is: vinod update the Getting Involved Section in the documentation for suggested lines of code / commit
17:04:09 <eankutse> vinod stepped away for 1 sec
17:04:13 <kiall> 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 <kiall> Ah.. Well, No worries.. Moving on
17:04:42 <kiall> Next: (all) review/add new blueprints as needed to track smaller work items
17:05:01 <kiall> I've personally not had a chance to break up any of the blueprints, has anyone else?
17:05:16 <eankutse> i have not added any blueprints ;-)
17:05:32 <mugsie> not yet, i have a dreakdown in my head though
17:05:37 <kiall> I know ekarlso has filed a sub-BP for the pagination stuffs (to be discussed in a few mins)
17:05:54 <kiall> Okay - Well, Let leave that for next week again
17:06:01 <kiall> #action (all) review/add new blueprints as needed to track smaller work items
17:06:05 <mugsie> proably should be a standing item for a while
17:06:14 <kiall> mugsie: agreed
17:06:18 <eankutse> yep
17:06:32 <kiall> Next: Betsy and Rich to followup on incubation status wrt v2 and mini-dns
17:06:47 <betsy> I talked with Anne Gentle yesterday
17:06:47 <kiall> (agenda is pretty full today, hence working fast.. Tell me to slow down if needed ;))
17:07:01 <betsy> I'm in the process of writing up an email about it now
17:07:13 <betsy> Should go out later today
17:07:24 <mugsie> cool
17:07:37 <kiall> 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 <richm> 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 <kiall> Quick aside - Alex Barclay from HP, our dev manager, has been asked to start looking into designate incubation.
17:08:41 <kiall> Okay.. Moving on again real quick :)\
17:08:43 <kiall> Next: Rich to document the minidns concerns on the wiki spec
17:08:45 <betsy> Anne pretty much felt the same way
17:09:00 <betsy> She did mention that there are already 4 projects ahead of us that have applied for incubation
17:09:02 <kiall> I'm not sure if ^ got worked out in the post-meeting discussions or not, richm?
17:09:38 <richm> 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 <kiall> 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 <betsy> ok
17:10:00 <richm> but that should not hold up minidns design/progress
17:10:03 <kiall> #action kiall to review current incubation applications and new "limits" on # per cycle
17:10:14 <kiall> richm: K - Thanks :)
17:10:23 <kiall> #topic API v2 Pagination
17:10:47 <ekarlso> link: https://blueprints.launchpad.net/designate/+spec/api-v2-pagination
17:10:53 <ekarlso> or how to do that ;)
17:11:11 <kiall> 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 <mugsie> yup
17:11:23 <kiall> #link https://blueprints.launchpad.net/designate/+spec/storage-pagination-support
17:11:28 <ekarlso> there ya go
17:11:53 <kiall> ^ 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 <eankutse> looks like marker/limit is the practice so far in Openstack
17:12:21 <richm> I'm all for code sharing/reuse
17:12:44 <kiall> Yea - I asked ekarlso to review all the current APIs, the patterns they use are in the parent / main BP
17:13:32 <kiall> 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 <vinod> none from me
17:13:54 <richm> +1
17:13:56 <betsy> agree
17:14:14 <kiall> Okay - I'll mark the sub-BP as approved, and we'll get it started :
17:14:43 <ekarlso> ok!
17:14:48 <kiall> #topic Review abstract proposals for Openstack Summit in Atlanta
17:14:52 <ekarlso> see ya folks for today ;)
17:15:10 <kiall> ekarlso: hope your not late to pick her up ;) Enjoy!
17:16:07 <kiall> 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 <kiall> I know Tim and Graham have both written abstracts, do you guys have links handy?
17:16:43 <kiall> I believe this is tims: https://docs.google.com/a/managedit.ie/document/d/1xIprT3xEzujFPWJhVGnIKRdsB7gkmpgTgo0DfG3Ml4s/edit
17:17:23 <vinod> Abstract for the workshop
17:17:26 <vinod> #link https://wiki.openstack.org/wiki/Designate/Atlanta/Workshop_1
17:17:27 <kiall> #link https://docs.google.com/document/d/1xIprT3xEzujFPWJhVGnIKRdsB7gkmpgTgo0DfG3Ml4s/edit?usp=sharing
17:17:34 <kiall> mugsie: do you have your link handy?
17:17:38 <mugsie> #link https://docs.google.com/document/d/1D6FcXMiWMvFTIggWiRu3VajVTnerCFDErTdafcSyxl0/edit?usp=sharing
17:18:05 <mugsie> We start at Tims and work our way donw?
17:18:08 <mugsie> down*
17:18:13 <richm> Tim's looks good to me - does it overlap with kiall's or mugsie's?
17:18:43 <kiall> 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 <mugsie> a little with mine, but n ot too much
17:19:07 <vinod> One overlap is about the Nuetron floating IPs
17:19:47 <mugsie> yeap. i think it is from 2 different view points though
17:19:47 <kiall> #link https://etherpad.openstack.org/p/DesignateAustinWorkshop2014-01
17:19:51 <kiall> ^ the original outlines
17:20:06 <mugsie> kiall: they are on https://wiki.openstack.org/wiki/Designate/Atlanta
17:20:10 <mugsie> #link https://wiki.openstack.org/wiki/Designate/Atlanta
17:20:17 <kiall> Ah - I missed that page
17:21:21 <mugsie> so, any changes to tims?
17:21:26 <kiall> 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 <richm> Sounds good to me
17:22:32 <eankutse> Maybe Tim's can be a little more focused
17:22:39 <betsy> Yeah. I think that works
17:22:43 <jmcbride> One question about the abstracts, should we put all of our "wood behind one arrow", e.g. pick one talk?
17:22:46 <eankutse> it looks pretty broad
17:23:04 <mugsie> i think seen as there is only 2 being submitted, we should be ok
17:23:15 <betsy> mugsie: agree
17:23:19 <jmcbride> What about the proposed workshop?
17:23:35 <jmcbride> 2 talks + workshop = 3
17:23:38 <mugsie> i think that stands on its own merits
17:23:41 <kiall> Workshop proposal looks perfect :)
17:23:41 <betsy> I think we should still propose that, as it's in a separate bucket, so to speak
17:24:06 <kiall> Yea - I absolutely think the WS is a great idea.
17:24:16 <mugsie> i see tims abstract as an updated version of what kiall gave in Hong Kong
17:24:38 <eankutse> mugsie: so you think the breath of it is fine
17:24:39 <eankutse> ?
17:24:55 <eankutse> s/breath/breadth
17:24:55 <mugsie> mine is aimed at operators, and your workshop is aimed at anyone who is interested
17:25:01 <eankutse> ok
17:25:02 <mugsie> i think so...
17:25:07 <eankutse> k
17:25:10 <mugsie> but I am open to correction
17:25:25 <eankutse> that sounds good
17:25:31 <betsy> mugsie: I think you're correct
17:25:35 <kiall> 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 <eankutse> kiall: yes
17:26:40 <richm> 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 <kiall> 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 <mugsie> any changes to the workshop? i think is looks good -  what we are trying to get across
17:27:14 <kiall> (Not intending to stop the discussion now with ^, just getting it out there)
17:27:28 <mugsie> well, see if there is any changes people want
17:27:59 <kiall> 1 other point we discussed was giving the talks jointly between the various companies... Who's still up for that?
17:28:08 <mugsie> +1
17:28:11 <jmcbride> +1
17:28:15 <richm> I am - looks like I am going
17:28:16 <kiall> (We need presenter names for the submissions)
17:28:16 <vinod> #agree
17:28:27 <jmcbride> We should try to appoint at least 2 people (one from each organization) to run the talks
17:28:54 <eankutse> Joint presentations will help incubation, I agree
17:29:22 <eankutse> +1
17:29:27 <jmcbride> I would like to participate on talk 1.
17:29:27 <betsy> +1
17:29:30 <kiall> 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 <betsy> kiall: sounds good
17:30:14 <richm> +1 - I would be happy to do either one
17:31:10 <jmcbride> 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 <jmcbride> ^ for all the Rackspace participation that is.
17:32:07 <jmcbride> How about this: RedHat + RAX for talk 1 (with a cameo from Kiall)
17:32:20 <kiall> jmcbride: any idea when you'll find out?
17:32:27 <jmcbride> kiall: nope
17:32:37 <kiall> Ok
17:32:59 <jmcbride> for talk two, it would be cool to see Mugsie lead it, with backup from ??
17:33:16 <mugsie> i am open to suggestions
17:33:38 <mugsie> I think you could probably get 3 on talk 1 - its more topics, that can be broken down
17:33:51 <mugsie> mine splits into 2 i think
17:33:56 <kiall> 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 <jmcbride> kiall: I think your contributions thus far speak for them selves… Designate is your legacy :)
17:34:53 <kiall> One of the reasons I'd like all you guys to be main faces of these ;)
17:35:04 <eankutse> Kiall should do a "live" from-scratch demo :-)
17:35:11 <mugsie> could I suggest RAX + richm + (short bit of) kiall for Talk 1?
17:35:17 <jmcbride> 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 <kiall> eankutse: lol .. happy to. I'll get it right this time :P
17:35:29 <eankutse> :-)
17:35:39 <jmcbride> +1 mugsie on could I suggest RAX + richm + (short bit of) kiall for Talk 1?
17:35:40 <richm> works for me
17:36:00 <jmcbride> +1 on live demo!
17:36:15 <kiall> SO .. That'd be tim (assuming approval) / richm with a teeny bit from me on T1? I'm happy with that..
17:36:40 <mugsie> and then me + 1 RAX  for talk 2?
17:37:00 <kiall> Names came be changed later for these BTW.. But better to get a general idea before they are submissted
17:37:02 <kiall> submitted*
17:37:08 <jmcbride> mugsie: yes
17:37:12 <jmcbride> Is Artom going?
17:37:33 <kiall> I think he said he wasn't going to be able to.. Not 100% sure.
17:37:34 <artom> Haha.
17:37:35 <artom> No.
17:37:35 <jmcbride> What about Ron?
17:37:46 <rjrjr_> i'm going to try and be there.
17:37:59 <artom> Unless I pay for my own stuff, I suppose.
17:38:09 <jmcbride> rjrjrj_: would you like to work with mugsie on talk 2?
17:38:32 <rjrjr_> that sounds okay.  let me get an okay to go in the next couple of days.
17:39:05 <mugsie> cool
17:39:13 <kiall> Okay .. So lets say, mugsie + rjrjr_ will give T2, failing approval for rjrjr_, mugsie + someone else to be decided later?
17:39:20 <mugsie> bingo
17:39:37 <jmcbride> Cool.
17:39:39 <kiall> artom: too bad :(
17:39:50 <richm> Sounds good
17:40:05 <jmcbride> artom: :(
17:40:45 <kiall> 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 <kiall> That time work for people/
17:40:57 <kiall> ?*
17:41:04 <rjrjr_> yes
17:41:05 <mugsie> yup
17:41:20 <jmcbride> yes
17:41:30 <kiall> (The WS propose looks good as is, and will probably just have a whole pile of names on it..)
17:41:45 <betsy> perfect
17:41:50 <kiall> #action Regroup on Talks+WS at 17:00 UTC tomorrow (Thursday)
17:42:05 <kiall> #topic import-tlds - right place to put it
17:42:37 <vinod> 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 <vinod> we talked about having a bulk api for import-tlds to overcome these 2 issues
17:42:55 <vinod> 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 <vinod> Joe do you have any other comments to add on this?
17:43:15 <kiall> 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 <kiall> or .. ^ what he said ;)
17:44:19 <kiall> I'm thinking everyone is in agreement on those points already?
17:44:27 <hub_cap> kiall: i agree
17:44:33 <kiall> hub_cap: good for you.
17:44:34 <kiall> :P
17:44:37 <hub_cap> :)
17:44:50 <mugsie> sounds good
17:45:00 <kiall> You know you just agreed to being our b*tch for the next cycle?
17:45:03 <kiall> ;)
17:45:16 <kiall> vinod / jmcbride ?
17:45:45 <cweid> o/
17:45:49 <vinod> nothing else from me
17:45:53 <vinod> checking with Joe
17:46:43 <kiall> Okay - Let's assuming it's a "Yes" and come back at the end if it's not :)
17:46:47 <vinod> Joe agrees too
17:46:50 <kiall> Getting close on time ;)
17:46:57 <kiall> #topic API v2 Structured Record Format
17:46:59 <jmcbride> hub_cap, Betsy is about to get medieval on yah!
17:47:01 <kiall> #link https://wiki.openstack.org/wiki/Designate/Blueprints/APIv2StructuredData
17:47:10 <hub_cap> jmcbride: :)
17:47:19 <kiall> #link https://blueprints.launchpad.net/designate/+spec/api-v2-structured-data-format
17:47:42 <kiall> #link https://review.openstack.org/#/c/71944/ (<-- Very much WIP, started as an experiment)
17:48:05 <betsy> I have to admit I haven't had time to review them
17:48:38 <eankutse> I've been following the WIP. I need to look at the latest updates
17:48:39 <kiall> 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 <kiall> eankutse: there's not too much new, other than the very experimental wire protocol stuff was killed.
17:49:16 <eankutse> k
17:49:33 <kiall> 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 <eankutse> so the intent is to make it possible for a given installation to pick and define what RR types they support?
17:49:51 <kiall> (Not expecting people to have read it yet - just finished writing the BP wiki a hour or wo ago)
17:50:17 <kiall> 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 <kiall> Implementing them together was really the "only way", as both really depend on each other.
17:51:06 <eankutse> thx
17:51:44 <kiall> 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 <betsy> kiall: sounds good
17:52:03 <richm> Is the string type needed for some sort of legacy application?
17:52:46 <kiall> 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 <richm> Ok
17:53:14 <kiall> Take someone setting up Google Apps - The number of SRV recrods to get Google Talk going is huge (about 10)
17:53:30 <kiall> most people will have no clue which of the example records map to the actual fields
17:54:30 <kiall> 6 mins left.. Rushing, We'll come back to that next week..
17:54:31 <kiall> #topic Mini-DNS, what next?
17:54:53 <kiall> So - The big-one with like 6 mins to go.. Perfect ;)
17:55:05 <betsy> :)
17:55:16 <artom> Overflow into #openstack-dns afterwards?
17:55:22 <mugsie> I think this falls under the 'big pcture bp' idea
17:55:35 <mugsie> where one person drives it, and has side meeting
17:55:39 <kiall> 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 <eankutse> yes
17:56:37 <mugsie> +1
17:56:42 <eankutse> And also with perceived issues
17:56:44 <kiall> #action kiall to condense mini-summit dicussions into MiniDNS spec
17:56:47 <eankutse> for further consideration
17:56:56 <mugsie> (multiple specs ;))
17:57:01 <kiall> 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 <kiall> mugsie: overall vision spec ;) Implementation will be small pieces :D
17:57:28 <artom> kiall, why ditch dnspython?
17:57:40 <richm> can we salvage it at all?
17:57:50 <artom> Not to shoehorn it everywhere, but if it can be useful in places...
17:58:18 <eankutse> so dnspython + some glue code?
17:58:32 <artom> eankutse, I think it needs more than glue ;)
17:58:40 <kiall> 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 <eankutse> agree
17:58:44 <betsy> I thought there was some concern about the reliability of dnspython
17:58:44 <artom> But it can handle some of the to/from wire stuff.
17:59:25 <rjrjr_> dnspython seems like the correct direction.
17:59:36 <betsy> 1 minute left
18:00:04 <kiall> 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 <kiall> Lets move to #openstack-dns
18:00:16 <kiall> #endmeeting