17:01:14 <kiall> #startmeeting Designate
17:01:15 <openstack> Meeting started Wed Apr 16 17:01:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:18 <openstack> The meeting name has been set to 'designate'
17:01:25 <kiall> Heya - who's about? :)
17:01:27 <mugsie> o/
17:01:29 <vinod> here
17:01:38 <jmcbride> howdy
17:01:43 <tsimmons> o/
17:01:52 <rjrjr> here
17:02:22 <kiall> #topic Review action items from last week
17:02:29 <richm> here
17:02:51 <kiall> 2 items - 1 I was told was one after I added it, and other was to organize the hangout. So.. Both done.
17:02:54 <betsy> o/
17:03:03 <kiall> #topic DNSpy update
17:03:12 <kiall> I missed who added this item? :)
17:03:32 <vinod> Joe added this
17:03:32 <jmcbride> I added this
17:03:48 <jmcbride> Unfortunately emmanuel is not here at the moment, as he has the best detail.
17:04:17 <vinod> But from what he mentioned, notify works well with DNS Pythin
17:04:18 <jmcbride> I know he is working through it and having some success… hasn't hit any major issues.
17:04:22 <kiall> jmcbride: ah, will he be here before the end of the meet? If so, Let's come back to it/
17:04:32 <vinod> No not today
17:04:48 <jmcbride> no, but my thought was mostly around what we want to do with dnspy and the diy
17:04:55 <vinod> AXFR works as a client he needs to checkout as a server
17:05:00 <kiall> vinod: Okay..
17:05:20 <jmcbride> I think he will be done soon and I thought I'd bring it up so we have what we need on diy to make a decision
17:05:26 <betsy> kiall: How’s the DIY coming?
17:06:18 <kiall> betsy: exactly as it was a few months ago - I'm confident it's relatively easy to implement, I think it's a *slightly* better option, but am open to both DIY and DNSpy
17:06:53 <jmcbride> I would imagine the two could probably be swapped out without to much impact.
17:07:00 <kiall> You might have noticed the # of reviews from me has jumped over the last week, finally managing to organize time etc :)
17:07:20 <betsy> I know. I’m impressed
17:07:48 <vinod> especially with the late nighters like yesterday :-)
17:08:00 <kiall> jmcbride: yea, swapping one for the other should actually be easy enough
17:08:40 <jmcbride> OK, I think we can probably move on.  The main takeaway I think is the DNSpy might be an option to go with initially for mDNS then swap out later in the event we are not ready to address DIY yet.
17:08:47 <kiall> Anyway - I'm personally open to both routes, I do think DIY is going to give us more control - but that's very much "It'll be useful at some point in the future" thing
17:09:20 <kiall> jmcbride: yea, essentially the same as my thinking :)
17:09:26 <jmcbride> sweet
17:10:08 <kiall> Once the next BP (also the next topic) is implemented, we should be pretty close to being able to actually implement these choices
17:10:27 <kiall> So - Anything else on this topic before we move on?
17:10:41 <vinod> No
17:10:50 <kiall> #topic Clarify details mdns-structured-rdata
17:10:55 <vinod> #link https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS#Update_the_Record_object_to_make_available_the_structured.2C_as_well_as_textual_representations_of_the_records.27s_RData
17:11:19 <vinod> I wanted to clarify my understanding before I get started on this.
17:11:22 <vinod> Currently designate/objects has an object for record. This object (designate.objects.Record) would provide from_text, to_text methods. designate.objects.base would provide a from_dict, to_dict methods. The various types of records supported ("A", "AAAA", "CNAME", "MX", "SRV", "TXT", "SPF", "NS", "PTR", "SSHFP") would each have a separate type that inherit from designate.objects.Record. Storage's get_record, find_record and find_records would be ab
17:13:56 <kiall> vinod: Sorry, misundersood the first time a wrote a totally wrong comment.. Typing again ;)
17:15:15 <kiall> So - Yes, for e.g. "MXRecord" would inherit from Record, it would provide (to|from)_text methods (for the API), and in the next BP, (to|from)_dnpy methods
17:16:00 <kiall> Storage's methods would then be updated to accept/return the appropriate object, rather than the generic "Record" class
17:16:27 <vinod> ok.  the next part of my question
17:16:28 <vinod> For storage's create_record, update_record to take in one of these record types (rather than a dict that as it is currently) and be able to create/update it, we would need to modify either the central and/or api layer to supply one of the record types rather than a dict. Should this be done as another blueprint?
17:17:32 <kiall> Eventually, we should end up in a place where we can go recordset = storage.get_recordset(12345) ; recordset.to_dnspy(), which that would then be pushed out over the wire in response to queries etc
17:17:59 <kiall> vinod: I actually consider that a bug in the o.m switchover, previous to the o.m migration, our own objects 100% passed over the wire to the API layer
17:18:44 <kiall> So .. I do think that bug needs to be fixed so we can avoid unnecessary dict<-->object conversions where there not needed
17:19:03 <kiall> I was actually looking at it about an hour ago, but haven't found the cause yet
17:19:16 <betsy> kiall: o.m switchover?
17:19:27 <mugsie> oslo.messageing
17:19:48 <betsy> OK. I thought it was oslo something, but couldn’t think what the m was for
17:19:51 <kiall> The switch from the depreciated oslo-incubator "rpc" stuff to the replacement oslo.messaging lib
17:20:06 <kiall> Sorry - should have explained :)
17:20:19 <betsy> np
17:20:37 <vinod> ok kiall i will let you fix that bug - since you have more knowledge there
17:21:47 <kiall> Sure :)
17:22:36 <kiall> Okay .. So, vinod - I assume this means you're going to take that BP?
17:22:42 <vinod> yes
17:23:09 <kiall> Cool - I'll get that bug sorted as soon as I can - Hopefully today.
17:23:14 <vinod> also wanted to check - is Graham doing the api validation for the various record types?
17:24:01 <mugsie> vinod: not at the moment - just the current objects - but when that BP merges, I can update
17:24:01 <vinod> asking since kiall mentioned something to this effect yesterday
17:24:05 <kiall> mugsie was adding validation pieces to your objects stuff, which would let us centralize the validations into something that can be used by both the API and Central and mDNS etc
17:24:47 <kiall> i.e. anything based on those objects could then be validated, including the RRType specific objects
17:25:09 <mugsie> yeah, it would just be updating schemas
17:25:57 <kiall> Okay - Anything else on this topic before we move onto Open Discussion? (Short agenda today)
17:26:26 <vinod> Everything clarified
17:27:02 <kiall> #topic Open Discussion
17:27:41 <kiall> Any other topics today? :)
17:27:46 <jmcbride> Design time at the summit
17:28:00 <kiall> Ah yes - I saw that got scheduled, but I cant see when it was scheduled for!
17:28:11 <kiall> mugsie: did you get an email or anything?
17:28:16 <jmcbride> Mugsie started on this topic and he and I have been looking into finding more time to review blueprints, etc.
17:28:38 <mugsie> kiall: nope, nothing
17:28:55 <mugsie> I assume I will get an email from Beth at some point
17:29:08 <jmcbride> Mugsie: what was the name of the program/event you submitted it under?
17:29:20 <mugsie> Design Summit
17:29:28 <jmcbride> OK.  Another option for time is https://www.openstack.org/blog/2014/03/call-for-proposals-open-source-openstack-summit/
17:29:33 <mugsie> yeah
17:29:44 <mugsie> I would say we go for it
17:29:54 <jmcbride> "it’s an opportunity for these projects to hold small design summits with their community members."
17:30:12 <jmcbride> The more time available, the better.  I'll go ahead and submit.
17:30:17 <kiall> It sounds like that's the same thing you did mugsie?
17:30:27 <mugsie> nope, its a new side track
17:30:32 <mugsie> not part of the design summit
17:30:39 <mugsie> we got offical design summit time
17:30:56 <mugsie> and this would be extra time -its a full 1/2 day sesion
17:31:10 <jmcbride> How much time did you secure?
17:31:20 <mugsie> I can work wit jmcbride to put in an application for the new side session
17:31:32 <mugsie> I don't know - I have never been to a design summit
17:31:43 <mugsie> kiall: any idea how long thre design sessions go on for>
17:31:44 <mugsie> ?*
17:31:45 <kiall> mugsie: there all different lengths from memory
17:32:07 <mugsie> Isay we go for it - the more exposure the better
17:32:10 <mugsie> I say*
17:32:15 <kiall> summit.openstack.org/cfp/details/196 says "Scheduled"... I'm assuming that means there's a schedule *somewhere*
17:32:36 <mugsie> yeah - but I don't think it is public yet
17:32:43 <mugsie> they said they would let us know by friday
17:32:47 <jmcbride> OK, lets go for it. Can we assume the usual suspects from HP, RedHat, eBay and Rackspace will make it?
17:32:57 <mugsie> me anyway
17:33:02 <richm> yes
17:33:56 <kiall> jmcbride: yep, definitely
17:34:05 <mugsie> jmcbride: you free after this? we can put it in this evening if possible
17:34:46 <jmcbride> #action Joe Work with mugsie to get an application in for https://www.openstack.org/blog/2014/03/call-for-proposals-open-source-openstack-summit/
17:34:51 <mugsie> cool
17:34:58 <jmcbride> yes, I'm free
17:36:16 <mugsie> anythign else?
17:36:31 <betsy> I’m good
17:36:59 <kiall> Not from me, I'm already semi-distracted right now (dragged into another conversation as I'm apparently the only person who can still login to the server.. heh)
17:37:14 <betsy> :)
17:37:47 <vinod> nothing from me
17:38:15 <kiall> Cool, Okay.. vinod I'll ping you once I've figured out the bug :)
17:38:32 <kiall> Thanks all :) See you in #openstack-dns ....
17:38:41 <kiall> #endmeeting