17:00:08 <kiall> #startmeeting Designate
17:00:08 <kiall> Heya
17:00:09 <openstack> Meeting started Wed Nov 13 17:00:08 2013 UTC and is due to finish in 60 minutes.  The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:13 <openstack> The meeting name has been set to 'designate'
17:00:25 <eankutse> here
17:00:43 <kiall> Hey guys - Who's about?
17:00:54 <eankutse> here
17:00:55 <vinod1> here
17:01:38 <kiall> Cool - A few of the HP folks are at a conference in the UK at the moment, so aren't about
17:02:23 <eankutse> Kiall: good job at the Openstack conf
17:02:23 <kiall> So - I frankly forgot to publish the agenda at all .. Will try and remember to get that out earlier than on the day (or at all!)
17:02:31 <kiall> thanks eankutse :)
17:02:38 <eankutse> I hate demos tho :-)
17:02:41 <kiall> Still trying to catch back up after the week away!
17:02:50 <kiall> Yea - Demos fail, not sure what I was thinking :D
17:03:17 <kiall> So .. Straight to it I suppose :)
17:03:18 <artom> kiall, for serious, I thought you were going to demo a known-working installation with some queries.
17:03:20 <artom> Not install from scratch.
17:03:20 <kiall> #topic OpenStack Summit
17:03:54 <kiall> artom: Yea, I had the start -> finish install in under 5 mins down .. But fat fingered something on stage
17:04:11 <kiall> Anyway :) I think it still went well :)
17:04:30 * CaptTofu \o
17:04:31 <kiall> CaptTofu did most of the talking, so I didn't get too much of an opportunity to ruin it :)
17:04:44 <CaptTofu> kiall: Ruth said you did great
17:04:56 <artom> Oh, CaptTofu is Patrick!
17:05:02 * artom puts a face on nick.
17:05:03 <CaptTofu> aha!
17:05:05 <kiall> Anyway - Had some good talks with people at the conference about Designate, starting to see more and more interest.. Which is obviously great!
17:05:06 <betsy> I just got here
17:06:08 <kiall> #link http://www.youtube.com/watch?v=0jLFnw0joO8
17:06:14 <kiall> For those who haven't seen it ;)
17:07:10 <kiall> Anyway - One of the more interesting conversations was with RedHat, who said something along the lines of "there seeing customer demand for Designate"
17:07:25 <eankutse> cool
17:07:30 <betsy> nice
17:07:33 <kiall> I think that says alot about the gap we're filling :)
17:07:47 <betsy> So, any talk about us getting incubated?
17:08:07 <betsy> I know we were waiting for the next step until after the conf
17:08:14 <kiall> Plenty of Q's about it, but I left most of them at "We're going to discuss it post-summit"
17:08:32 <kiall> #action kiall to put incubation on next weeks agenda
17:09:12 <kiall> So - Won't spend too long on the Summit, but just wanted to say it went well, and we're seeing more and more interest :)
17:09:18 <kiall> #topic Havana Release
17:09:43 <kiall> Moments before the Summit, we released the "Havana" / 2013.2 version, and cut a "stable/havana" branch ..
17:10:15 <kiall> I wanted to give an explanation of how that works, and what's acceptable etc in the stable branch (based on what the other OS projects allow into stable branches)
17:10:47 <kiall> Lots of the Summit talk was about handling more and more projects becoming OpenStack
17:11:27 <kiall> The main gripes were things like: Not following the conventions in advance, not having the CI infrastructure in place in advance, and the usual "We should stick to IaaS" suggetions
17:12:00 <kiall> Re conventions, over the last few weeks/months we've made big strides towards following the conventions
17:12:44 <kiall> things like how the launchpad blueprints  / bugs are tracked, cutting a stable branch, actually doing a release etc.. but we have more to go - mostly around how we do CI testing
17:13:04 <kiall> (Thanks mugsie for sorting the blueprints/bugs out BTW - If your here!)
17:13:28 <kiall> So, now that we have this stable/havana branch, it's intended to be bugfix only where no new features land.
17:14:02 <kiall> i.e. People should be able to run that branch and upgrade each and every commit in it seamlessly ..
17:15:03 <kiall> vinod1's patch for SDL fixes a pretty serious bug, but technically, adds features too.. So, we need to be careful to leave the default behaviours unchanged if we want to merge that into stable/havana
17:16:15 <kiall> How that actually happens is, all patches MUST land on master first, sit there for a while until we're happy it's solid, then we `git cherry-pick` (and possibly amend) the commit and `git-review` again, it'll be proposed to the stable/havana branch as a new review
17:16:40 <kiall> Any Q's? :)
17:17:06 <vinod1> Should we have a different fix for the SDL for havana vs icehouse?
17:17:54 <kiall> vinod1: for the particular case, I think the fix your doing is the cleanest fix possible. So, No, I think we merge that patch through. But..
17:18:15 <kiall> In the stable/havana branch, the public suffix list should be disabled by default, instead only using the IANA list
17:18:25 <kiall> Leaving the existing behaviours unchanged
17:19:32 <kiall> Making that happen is bacially, `git checkout stable/havana && git cherry-pick YourReviewSha1 && set default public suffix list file to "None" && git commit -a --amend && git-review`
17:19:43 <kiall> (Once it's landed in master etc)
17:20:04 <vinod1> How long are branches active - i.e. how long would we need to maintain stable/havana before it becomes deprecated?
17:20:50 <kiall> vinod1: So, I believe the norm in OpenStack is to abandon all but security fixes once a new stable/* branch is cut
17:21:53 <kiall> i.e master will eventually turn into stable/icehouse in ~6 months, where stable/havana will turn into security fix only mode
17:22:01 <kiall> (At least - that's what I think the conventions are..)
17:23:59 <kiall> Okay .. So - Last thing on Havana release, I'll be maintaining .deb's for both stable/havana and master, if others know how debian/ubuntu packaging works.. Happy to get help with that :)
17:24:46 <kiall> Okay :) Moving on so ..
17:24:59 <kiall> #topic SDL Patch
17:25:28 <kiall> vinod1 has a patch up for review on fixing the "SDL issue" (i.e. customers registering "co.uk." in Designate, blocking "company.co.uk."
17:25:40 <artom> kiall, overflow from previous topic, but a couple of guys here have plans/intentions to package for Debian.
17:26:15 <artom> You spoke to Ignace at the summit, and we'll talk it over next week, so more concrete info then. But just FYI for now :)
17:26:36 <kiall> Cool :)
17:27:00 <kiall> Anyone have comments on the SDL fix? I know I'm pretty happy with how it's looking, with some minor comments like:
17:27:01 <kiall> 15:38 <kiall> vinod1: I was actually thing the same thing a few minutes ago .. I think the public suffix and IANA list parsing etc belongs isolated from everything else, exposing 1 method "is_effective_tld", which returns True/False..
17:27:03 <kiall> 15:38 <kiall> Then the remainder of the checks are in the central/service.py file, to later be abstracted away along with the record_name etc checks
17:27:15 <eankutse> I am in the middle of looking at it
17:27:21 <eankutse> mainly learning
17:27:33 <kiall> Re where the PSL/IANA lists checks should go, vs things like the single label checks
17:27:45 <betsy> I haven't really looked at it yet either :(
17:28:21 <kiall> No worries :) Just wanted to check if others had comments!
17:28:24 <artom> Can't say I've looked at it in enough details to have an opinion.
17:28:33 <artom> Other than what I already posted.
17:28:54 <vinod1> So kiall to clarify - are you saying that it is okay to have the accepted list checks and the 1 label check in effectivetld.py?
17:30:00 <kiall> vinod1: so, I think effectivetld.py should concern itself with parsing the IANA and Public Suffix lists, and checking if a domain is equal to one of the list items
17:30:48 <kiall> e.g. 1 public method is_effective_tld('example.com.') (which returns False) / is_effective_tld('co.uk.') (which returns True)
17:31:45 <kiall> Then, the other checks go back in central/service.py, and get moved later into a "central/validations.py" (or something) with the domain/record/etc checks all in there rather than the main service class
17:32:00 <vinod1> okay
17:32:17 <vinod1> mugsie also had a comment about raising all the exceptions in one place
17:32:40 <vinod1> With the change that you suggested, taking care of mugsie's suggestions too should be easy
17:32:57 <kiall> I think all the exceptions end up being raised in central/service.py after that, and then eventually somewhere else (when we start clearning central/service.py out)
17:33:59 <kiall> (Side track: central/service.py is getting too big, and concerns itself with way too many things at once.. hence starting with vinod1's SDL patch, we'll try and turn related code into modules that can be used by central/service.py)
17:35:13 <kiall> Okay .. Moving on so :)
17:35:29 <kiall> #topic Open Discussion
17:35:48 <eankutse> I proposed a new blueprint - https://blueprints.launchpad.net/designate/+spec/zone-search
17:36:41 <kiall> eankutse: reading
17:36:46 <eankutse> k
17:37:48 <kiall> I wonder, does this duplicate https://wiki.openstack.org/wiki/Designate/APIv2#Filtering (Which I'm still working on .. Slowly. 2 fulls days starting tomorrow AM dedicated to it ;))
17:38:34 <kiall> One piece it adds, which we don't have explicitly called out in the V2 spec, is searching across "all tenants".
17:38:48 <eankutse> We can take this up in the IRC after looking at both blueprints
17:39:33 <eankutse> k
17:39:38 <kiall> eankutse: cool :) I'll have another read of it on the train home, mugsie is also one of the better people at figuring out how an API should look.. I'll ping him to add some comments if he can
17:40:17 <eankutse> cool
17:40:32 <vinod1> The blueprint that eankutse proposed would primarily help support
17:40:52 <kiall> Either way, I was planning on getting the core pieces of V2 API back up for review before the end of the week, which would be the new API endpoints/format, but none of the new features like this.. So this piece is certainly open for the taking :)
17:41:54 <kiall> (I've found 2 whole days to dedicated to writing code, with no colleagues around to distract, so I'm hopeful i'll get it done before the end of the week ;))
17:42:13 <CaptTofu> I won't distract either :)
17:42:36 <kiall> Too late -  Just got a distraction email ;)
17:42:40 <betsy> We'll probably be around to distract you tho ;)
17:42:45 <CaptTofu> hah
17:43:19 <kiall> Anyway - Any other stuff to discuss? (Before I start on my last thing that is!)
17:43:28 <artom> dnssec?
17:43:52 <kiall> Hah - Now that's a topic and a half :)
17:44:04 <artom> A couple of guys here were asking about it, saying it's going to be almost required in the coming months/year.
17:44:13 <artom> Tell me about it ;)
17:44:39 <kiall> Probably not enough time to discuss that this week, do you want to drop it on the agenda for next week? Maybe an intro discussion figuring out what our requirements are? It's coming up on everyones radar :)
17:44:52 <artom> Yeah, it's not urgent.
17:45:05 <kiall> (Also had lots of DNSSEC related questions at the summit)
17:45:35 <artom> I'll do my homework and learn more about how it works.
17:46:36 <kiall> Okay .. Well, My last thing then! We've been more active between meetings in #openstack-dns - Rather than waiting a whole week to discuss in-review stuff, blueprints etc etc, we're doing it much closer to "real time". I love it :) And just want to encourage that over waiting for the weekly meet!
17:47:14 <artom> Hah, sweet, I was starting to do the reverse since it seems like the established way of doing things.
17:47:16 <eankutse> Yes :-)
17:47:50 <kiall> artom: hah - I knew it was a good thing to bring up ;)
17:48:06 <artom> I'm an impatient bastid.
17:48:42 <kiall> I'd *personally* like to see these meetings last 30 mins, rather than an hour, with Discussion/Homework in-between, Decisions here.. But that's just me :)
17:48:58 <kiall> Thoughts? :)
17:49:04 <betsy> Kiall: sounds good to me
17:49:19 <artom> The only thing about real-time IRC is it gets difficult(er) to track stuff.
17:49:40 <artom> There's no trac or redmine or something similar that can be used?
17:49:49 <eankutse> is there a bot?
17:49:54 <kiall> Channel logs are published here http://eavesdrop.openstack.org/irclogs/%23openstack-dns/
17:49:55 <artom> (If people want, obviously)
17:50:15 <kiall> And launchpad.net/designate is ~= trac/redmine!
17:50:16 <artom> That's not very searchable ;)
17:50:41 <kiall> artom: plain text is searchable as hell `wget --recursive && grep ` :P
17:51:00 <artom> Grrrr ;)
17:51:06 <kiall> eankutse: by bot, I assume you mean channel logging bot?
17:51:11 <eankutse> yes.
17:51:19 <eankutse> You answered
17:51:34 <kiall> Cool - Just checking :)
17:51:38 <CaptTofu> who here was interested in mysql-bind? I have been remiss in getting that done
17:51:39 <kiall> Meeting logs are also here BTW: http://eavesdrop.openstack.org/meetings/designate/2013/
17:52:31 <kiall> Not sure I remember who asked about that .. Sorry!
17:52:35 <artom> I just want to avoid stuff said on IRC being left in logs only - hence why I did that summary on vinod1's patchset for example.
17:53:10 <kiall> artom: yea, I totally agree. There's a balance to be had between IRC/Gerrit/Launchpad - we'll need to find the right one!
17:53:49 <betsy> artom: Yes. That was very helpful
17:54:17 <artom> But other yeah, the more chatter the merrier :)
17:54:21 <artom> *otherwise
17:56:06 <kiall> Okay - Any other comments/topics etc before we close out? :)
17:57:04 * kiall assumes not :)
17:57:05 <vinod1> get your lunch/dinner/nutrition and back to work :-)
17:57:07 <eankutse> none
17:57:24 <kiall> vinod1: lol .. I'll try ;)
17:57:37 <betsy> none for me
17:57:51 <artom> Nada here.
17:57:54 <kiall> Okay - Thanks all :)
17:58:17 <kiall> #action kiall to update agenda earlier (for real this time)
17:58:20 <kiall> #endmeeting