17:00:07 <kiall> #startmeeting designate
17:00:08 <openstack> Meeting started Wed Jan  8 17:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:11 <openstack> The meeting name has been set to 'designate'
17:00:14 <ijw> rkukura: it's fairly nonspecific with respect to ml2 at the moment, but you could check https://docs.google.com/document/d/1svN89UXKbFoka0EF6MFUP6OwdNvhY4OkdjEZN-rD-0Q/edit# (that is very explicitly my take on how to do it and not by any stretch the agreed approach)
17:00:17 <kiall> Hey guys
17:00:29 <kiall> Happy new year etc etc :) Who do have around today?
17:00:35 <vinod> here
17:00:42 <eankutse> happy new year! :-)
17:00:44 <rkukura> ijw: Thanks
17:00:50 <mugsie> o/
17:00:54 <tsimmons> Hey guys
17:01:02 <betsy> here
17:01:26 <kiall> So - Lets dive right in then..
17:01:31 <kiall> First topic was from jmcbride
17:01:32 <kiall> #topic esignate mini-summit is January 27 to 29
17:01:35 <kiall> #topic Designate mini-summit is January 27 to 29
17:02:00 <artom> o/
17:02:01 <eankutse> let's skip for now
17:02:12 <kiall> eankutse: oh, joe AFK?
17:02:20 <eankutse> yes
17:02:29 <kiall> Okay - We'll leave that to next week then
17:02:32 <tsimmons> oh wait
17:02:41 * kiall waits
17:02:41 <kiall> :)
17:02:47 <tsimmons> I think he's typing :P
17:03:14 <jmcbride> I'm here guys
17:03:20 <kiall> Cool :)
17:03:48 <kiall> Okay - So, we need to start thinking about the agenda for the face to face meet in Austin at the end of Janurary
17:04:20 <kiall> From my point of view, I want to get as much input about what you guys want rather than myself or graham putting the agenda together!
17:04:33 <jmcbride> yes, we started brainstorming some topics, here is what I have:
17:04:36 <imsplitbit> o/
17:04:44 <jmcbride> 1. Some team building
17:04:58 <jmcbride> 2. Figure out server pools
17:05:59 <jmcbride> 3. Find ways to improve our development process (in particular, breaking down work and adding to transparency on progress)
17:06:22 <jmcbride> 4. Blueprint review
17:06:35 <jmcbride> 5. code code code!
17:06:56 <jmcbride> 6. v2 breakdown and finish
17:07:29 <jmcbride> Thoughts?
17:07:35 <mugsie> looks good
17:07:56 <kiall> Okay, I reckon we'll fill up the two a half days with that lot - I think #3 is probably the most important from my point of view
17:07:57 <rjrjr> agreed
17:08:03 <eankutse> looking good
17:08:25 <rjrjr> what dates in january?
17:08:31 <jmcbride> kiall: agreed
17:08:40 <tsimmons> January 27 to 29
17:08:41 <kiall> rjrjr: Jan 27th through 29th
17:09:20 <kiall> I'll be flying to Austin on the .. umm.. 26th or so, and heading to Seattle on the afternoon of the 29th
17:09:32 <mugsie> as will I
17:10:00 <rjrjr> sorry, was the austin face to face info published somewhere?  been out of it for a few weeks...
17:10:35 <kiall> rjrjr: jmcbride has organized it
17:10:50 <rjrjr> k
17:11:08 <jmcbride> rjrjr: it hasn't been published yet - we mostly just worked it out towards the end of the year 2013 via IRC and other discussions.
17:11:38 <kiall> Okay - So, I'll spend some time over the next week trying to take ^ list, and put together some more detail on what to discuss for each.
17:12:08 <jmcbride> kiall: if you'd like, I can draft a target agenda to fill out the days and run it by you and everyone
17:12:11 <kiall> #action kiall put together an agendawiki page based on ^, fill with as much detail as possible.
17:12:18 <kiall> jmcbride: ah - great :)
17:12:38 <kiall> I'll leave it to you so
17:12:56 <kiall> Lets come back to this next week once that page is up then..
17:12:59 <kiall> #topic Filtering Blueprint
17:13:04 <eankutse> yes
17:13:12 <eankutse> Based on discussions with Kiall
17:13:29 <kiall> This one is from eankutse, the BP looks great.. I do have a few comments though
17:13:31 <eankutse> I put together a blueprint for Filtering (Search) feature
17:13:34 <kiall> #link https://wiki.openstack.org/wiki/Designate/Blueprints/Filtering_API
17:13:37 <eankutse> •	https://blueprints.launchpad.net/designate/+spec/filtering
17:13:37 <eankutse> •	https://wiki.openstack.org/wiki/Designate/Blueprints/Filtering_API
17:13:57 <eankutse> I need some feedback when you all get some time
17:14:01 <eankutse> to look at it
17:14:08 <eankutse> in the next couple of days
17:14:10 <eankutse> :-)
17:14:19 <kiall> Sure - I've given it a look over, and have some feedback.. Not sure if anyone else has yet though ;)
17:14:32 <eankutse> cool
17:14:40 <kiall> The first thing that stood out for me was the /zones/ipaddresses endpoint
17:14:50 <eankutse> yea...
17:15:13 <kiall> I'm not sure I totally agree, as it's a special case for IPs versus a generic method.. e.g. What about CNAME values etc?
17:15:32 <eankutse> those might be on recordset
17:15:50 <kiall> I think a better option might be to have a /records endpoint in addition to /zones/{id}/records
17:16:25 <kiall> That endpoint wouldn't be filtered by zone, so a /records?filter=bla would get the same results
17:16:44 <kiall> Thoughts?
17:16:52 <eankutse> the goal being that we can have a privleged user filter across all zones
17:17:03 <eankutse> belonging to all tenants
17:17:14 <kiall> Yea, and "normal" users would have access to /records too, but filtered to just their tenant
17:17:32 <eankutse> that should work
17:17:42 <eankutse> Thx. I'll modify
17:17:43 <kiall> The thing I don't like about that, is the duplication .. And I know mugsie will call me up on that ;)
17:18:20 <eankutse> mugsie: what do you think?
17:18:25 <mugsie> yeah, I personaly disagree with the spearate endpoints
17:18:54 <mugsie> for me personally, I like the logical sub reasource style API
17:19:17 <artom> Get rid of /zones/{id}/records entirely?
17:19:27 <mugsie> i know that then causes problens for searching across things.. so i am not sure how we do that
17:19:33 <artom> Leave just /records, behaving as described by kiall and eankutse above...
17:19:54 <kiall> artom: no, that's the duplication part.. /zones/{id}/records would stay, but /zones/{id}/records/{id} would probably move to /records/{id}
17:20:12 <mugsie> which is the bit i dont like
17:20:12 <artom> Ah, right.
17:20:28 <kiall> and /zones/{id}/records would essentially be an alias for /records?zone_id={id}
17:20:29 <mugsie> you should be able to walk the tree of resources
17:20:45 <rjrjr> kiall, i like that.
17:21:09 <mugsie> however, it does mean urls in the future wont be as clear
17:21:40 <eankutse> mugsie: I see your argument for "ReSTfulness" here
17:21:55 <eankutse> and opaqueness
17:21:59 <mugsie> eg /zones/<id>/records/<id>/recordsets/ is obvoiusly recordsets in the record<id> in zone <id>
17:22:28 <mugsie> instead of /recordsets?record=<id>
17:23:27 <mugsie> personally, url query params should be used for small changes, not filtering sub resources
17:23:38 <mugsie> (imo)
17:24:09 <kiall> I personally think having a top level /records and /recordsets is the better choice, it's not perfect, but not awful either..
17:24:30 <kiall> anyone else have strong opinions either way?
17:24:48 <rjrjr> what is the other option to filter across zones?
17:25:05 <rjrjr> i just see /records allowing that.
17:25:09 <kiall> mugsie: BTW, so what would you suggest as the alternative to filter accross all records
17:25:32 <kiall> e.g. as an admin trying to locate records without knowing which zone/rrset it's in?
17:25:42 <mugsie> people like Jira etc generally use a /search end point, that can allow freeform searching
17:26:06 <artom> "search" is hardly a resource ;)
17:26:10 <mugsie> and then the search doesnt have to be tied to a particular type of resource either
17:26:18 <artom> But I can see that working...
17:26:37 <tsimmons> I could see a /records endpoint just for admins to do operations on random records, but then for individual tenants keeping the zone/id/records/id as well.
17:26:39 <artom> It makes a single "weird" endpoint, as opposed to them being all over the place.
17:26:40 <mugsie> they can walk the responce, and use the self links to do operations on the results
17:27:01 <kiall> A generic search endpoint that can match against anything? records/zones/rrsets/tsig keys?
17:27:13 <mugsie> yeah, depending on what you have access to
17:27:23 <artom> Perhaps /search/{resource_type}?
17:27:29 <tsimmons> Or you could have search/zones, etc
17:27:33 <kiall> I'm not sure I'd want to try and make that work without bringing in something like ElasticSearch/Lucene/etc.. Which I really don't think is an option
17:27:33 <betsy> I like that idea
17:27:57 <rjrjr> so, /search/records?  why not just /records then?
17:28:01 <kiall> tsimmons: is /search/records not the same thing really as /records ?
17:28:06 <mugsie> no
17:28:18 <artom> Because /search/zones, /search/keys etc
17:28:44 <tsimmons> Pretty much, but you generlize all search in /search
17:28:47 <mugsie> it allows us to keep the decent urls, and and can allow us to create predefined searches etc in the furture
17:29:02 <kiall> Also - Bear in mind that, I'm not aware of any OpenStack API that offers true "Search" (as against simple filtering) .. I'm not sure that's a convention we should break
17:29:43 <tsimmons> If you can't have records without zones it seems a little odd to have an endpoint for all of them. But I can understand the need to just view all records.
17:29:54 <tsimmons> Probably shouldn't break convention though...
17:30:22 <mugsie> not many other projects have true sub resources though
17:30:34 <kiall> tsimmons: yea, I personally think having the duplication (i.e. /records and /zones/../records) is the best choice from a not amazing set of choices.
17:30:59 <tsimmons> If /records were admin-only I don't really have a problem with it. As long as zones/id/records/id stays.
17:31:02 <kiall> mugsie: true, our data is naturally tree structured
17:31:22 <kiall> tsimmons: I could agree with that ..
17:31:36 <tsimmons> It seems a little cleaner to keep every search under one space to me though.
17:31:37 <mugsie> how do you do this style of search in nuetron for example? say an admin trying to find all floating IPs
17:31:41 <mugsie> ?
17:31:53 <kiall> GET /floating_ips?all_tenants=1
17:31:54 <jmcbride1> Surely we are not the only project with this problem, do we have examples from other projects to pull from?
17:32:19 <mugsie> you could have /search?resource=blah - and then the rest of the filter
17:32:33 <mugsie> and make the resource arg mandatory for the time being
17:32:52 <mugsie> and if we decide to ever have a true search, we can do it wioth breaking things
17:32:58 <mugsie> without*
17:33:17 <kiall> jmcbride1: I've not seen anything similar in other projects, but it's been a while since I looked.
17:34:28 <kiall> Humm.. So.. I really dislike /search?resource=blah
17:34:51 <mugsie> why?
17:34:57 <mugsie> its a filter ;)
17:35:20 <tsimmons> I'm more of a fan of /search/resource?name=blah personally.
17:35:26 <eankutse> So, in the interest of getting to other agenda items for today, should we think through these option for a while and pick up in IRC?
17:35:27 <kiall> Anyway - tsimmons's suggestion of making the admin-only, and thus subject to change, is a good one..
17:35:37 <mugsie> eankutse: good plan
17:35:43 <tsimmons> ^agree
17:35:50 <mugsie> people can dump comments on the wiki?
17:35:56 <eankutse> yes
17:35:58 <rjrjr> yes
17:35:58 <kiall> We can pick almost anything now and get the meat of the implementation done.. Without worrying too much about the what the final URL structure will be
17:35:59 <betsy> good idea
17:36:15 <tsimmons> We can look over the other projects and see if there's anything similar.
17:36:29 <kiall> Okay - Anyone with strong opinions, let's leave them on the wiki at the bottom of the BP
17:37:09 <kiall> Anyone else have other comments on that BP? That was the only real thing that caught my eye
17:37:15 <tsimmons> That's here https://wiki.openstack.org/wiki/Designate/Blueprints/Filtering_API it was hashtag linked earlier.
17:37:39 <eankutse> Kiall: that was a big/important one. Thx all
17:37:42 <eankutse> :-)
17:38:05 <kiall> Okay - Moving on so :) Next was from vinod ..
17:38:17 <kiall> #topic APIs for managing TLDs
17:38:48 <vinod> I had some comments/questions on the change and wanted to bring them up
17:38:58 <vinod> The TLDs are stored in the central storage.  They are not sent to the backend.
17:39:14 <vinod> By default now there are no TLDs.  Should designate be prepopulating the database with some default TLD values.  If so any suggestions on where this should go?
17:40:24 <kiall> Well, I guess the choice is between 1) Defaulting to the IANA list, 2) Defaulting empty, and treating that as "anything is allowed", 3) Defaulting empty, and treating that as "nothing is allowed"
17:41:02 <tsimmons> I don't know how extensive the IANA list is, but number 1 seems the best option to me if it doesn't impede anything.
17:41:04 <vinod> Currently the behavior is (3)Defaulting empty, and treating that as "nothing is allowed"
17:41:10 <kiall> I would be fine with either #1 or #2, but wouldn't want to see #3 - The less pain to get things setup, the better
17:41:19 <mugsie> i like 1
17:41:21 <betsy> tsimmons:agree
17:41:44 <kiall> tsimmons: the disadvantage to using the IANA list is, it changes when new TLDs are launched
17:41:50 <kiall> Which is happening a hell of a lot more now that it used it
17:42:41 <kiall> I'm not sure that's really that big of an issue though, every few months, sync the default list up
17:42:41 <mugsie> true
17:42:47 <tsimmons> Eh, if there was a generally comprehensive list that was default and then could be updated easily with the new list, that wouldn't be too bad right? Basically you just want to get the big ones.
17:42:50 <tsimmons> Yeah.
17:43:16 <eankutse> 1) sounds good to me since it is the "equivalent" of reading from the config file
17:43:32 <kiall> The IANA and Mozilla Public Suffix lists probably cover well over 90%
17:43:45 <mugsie> any issue with licences for them?
17:43:55 <mugsie> if not, I say we use them..
17:44:08 <jmcbride> What if option #2 was targetted for now, with a future blueprint to add the pull from the IANA/mozilla lists and sync with them?
17:44:47 <kiall> jmcbride: yea, we do want to support people who don't care if the TLDs are valid etc.. So, that's probably a pretty good option.
17:45:11 <kiall> Also - designate-manage could have a command added to download the lists and sync
17:45:38 <kiall> mugsie: re licences, 99.9% sure they are both fine to use
17:45:49 <tsimmons> a designate-manage command would be snazzy.
17:45:53 <kiall> We already include them as *.sample today, and I checked that last time
17:46:18 <vinod> kiall: With this change I am removing the lists
17:46:46 <kiall> vinod: yea, I meant I had checked the licences before when we first included the lists :)
17:47:05 <ekarlso> ello :p
17:47:13 <kiall> So - Anyone think there's a better option than #2? Default empty, accept anything
17:47:20 <ekarlso> ran late :)
17:47:38 <vinod> That looks like a good option - with the current bp I will make option (2) as the default
17:47:47 <mugsie> cool
17:48:05 <kiall> great :) vinod, did you have anything else on that BP to discuss?
17:48:40 <abramley> :q
17:48:45 <vinod> I will add another bp to get the information in the lists into the api
17:49:03 <kiall> vinod: okay :) Lets move on so.
17:49:06 <kiall> Next item was from betsy / vinod ...
17:49:07 <kiall> #topic Case-sensitivity in Domain Names
17:49:13 <kiall> Not really sure what this one is about :D
17:49:23 <vinod> Also to make it clear - if the tld db is empty then the behavior is to allow everything and if there is something in the tld db then start enforcing the rules
17:49:36 <mugsie> vinod: yup
17:49:45 <vinod> On the topic of case sensitivity
17:50:22 <vinod> We have a vagrant implementation where we see that we can create domains with different cases - e.g. hp.com and HP.com can both be created
17:50:37 <vinod> s/implementation/installation
17:50:50 <kiall> That shouldn't happen - ever.
17:50:55 <vinod> On another installation we do not see this behavior
17:50:57 <betsy> That's what we were thinking
17:51:14 <betsy> Did something change recently?
17:51:40 <kiall> I would imagine the DB is set as case sensitive?
17:51:55 <eankutse> the storage, huh?
17:52:00 <kiall> Or the unique index is somehow missing
17:52:33 <kiall> I mean, a mysql table can be configured to either case sensitive, or in-sensitive. I don't believe we specify a default while creating the tables
17:52:45 <vinod> Is the db set as case sensitive in one of the config files?
17:52:46 <betsy> Ah. That must be it.
17:53:35 <eankutse> since there is no designate specific logic for this
17:53:39 <betsy> We're using sqlite with the vagrant set up
17:53:41 <eankutse> I think you are right on
17:53:45 <kiall> Humm
17:53:45 <eankutse> must be the db
17:53:54 <kiall> Migration #21 might be the cause
17:54:06 <kiall> #action Check into migration #21 and case sensitivity
17:54:18 <kiall> Running out of time, So I'll check into that after the meet
17:54:23 <eankutse> what does migration #21 do?
17:54:41 <kiall> Set's the character set to UTF8, rather than accepting the database default.
17:54:53 <eankutse> thx
17:54:57 <kiall> But - We might have needed to use utf8_general_ci there instead
17:55:20 <kiall> Okay - 5 mins to go.
17:55:24 <kiall> #topic Open Discussion
17:55:36 <kiall> So - I have an off-agenda item..
17:56:11 <kiall> I'd like to propose mugsie for "core", he's pretty consistently doing good reviews etc.. so I reckon it's a good fit
17:56:22 <kiall> Following openstack tradition, that gets put to a vote.
17:56:43 <kiall> Thoughts?
17:56:59 <jmcbride> How many core members should we target?
17:57:15 <jmcbride> And who is a core member today?
17:57:30 <betsy> I second mugsie as a core member
17:57:33 <kiall> I don't think there's a "good" number,
17:57:56 <artom> Does there have to be a target? As long as the person knows the project, does good reviews and is willing to put in the time/energy...
17:57:59 <kiall> today it's myself, betsy, and from back in the day, ekarlso
17:58:26 <eankutse> I second mugsie
17:58:34 <tsimmons> +1 for mugsie
17:58:35 <artom> The more core the merrier, means patches get in faster ;)
17:58:36 <jmcbride> artom: agreed.
17:59:01 <jmcbride> We definitely need more than 2…
17:59:02 <vinod> +1 for mugsie
17:59:03 <kiall> Okay - Anyone disagree?
17:59:14 <jmcbride> +1 for mugsie
17:59:33 <ekarlso> I think we need someone *outside* of HP son as well :p
17:59:33 <kiall> With about 30 seconds to go, and nobody voting against ..
17:59:42 <ekarlso> +1 mugsie
17:59:42 <rjrjr> agreed.  +1
17:59:44 <kiall> ekarlso: betsy is outside HP
17:59:50 <ekarlso> kiall: she's core ?
17:59:52 <ekarlso> coolio
17:59:56 <ekarlso> then I'm silenced :)
17:59:57 <kiall> and, anyone is free to propose anyone..
18:00:32 <kiall> Okay then - Congrats mugsie
18:00:35 <tsimmons> Woot
18:00:37 <jmcbride> woot!
18:00:41 <mugsie> \o/
18:00:42 <kiall> and - we're eating into trove's time now :)
18:00:44 <tsimmons> #link http://robhirschfeld.com/2014/01/06/openstack-defcore/ may be of general interest. Whenever you have a chance.
18:00:58 <jmcbride> One quick topic note: Designate Meetup - We need a communication plan for including the community (e.g. setup a "summit" page with details, sign-up info, remote participation info). I can do that
18:01:22 <mugsie> jmcbride: cool, there is a meeting section in the blueprints page
18:01:26 <kiall> jmcbride: Let's move to #openstack-dns before we take all of troves time :)
18:01:28 <kiall> #endmeeting