17:03:19 <mugsie> #startmeeting Designate
17:03:19 <openstack> Meeting started Wed Jun 25 17:03:19 2014 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:19 <betsy> o/
17:03:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:22 <openstack> The meeting name has been set to 'designate'
17:03:24 <timsim> o/
17:03:37 <eankutse> here
17:03:41 <mugsie> #topic Action Items from last week
17:03:44 <dtx00ff> here
17:03:54 <mugsie> all to review owner transfer spec @ https://review.openstack.org/#/c/100267/
17:04:01 <mugsie> that was done, and merged
17:04:11 <mugsie> kiall Assuming no -1's, +A #100336 - done
17:04:19 <richm> I'm sort of here
17:04:20 <mugsie> mugsie to validate pools BPs are up to date with summit session notes and decisions before Monday, giving Monday/Tuesday as review time to people ;)
17:04:27 <mugsie> #link https://review.openstack.org/#/c/101298/
17:04:43 <mugsie> I have this on the agenda for later, so we will come back top the spec itslef
17:04:44 <jaycaz1> hacking update is done and merged
17:04:54 <mugsie> kiall to put dividing up pools BPs on next agenda - done
17:05:06 <mugsie> #topic IP Address Filtering
17:05:17 <mugsie> Who was this?
17:05:20 <jaycaz1> that was me
17:05:31 <mugsie> cool, - you have the floor
17:05:52 <jaycaz1> All right, well I've been charged with adding filtering, but it turns out that much of it has been implemented, to our surprise
17:06:17 <betsy> What’s the blueprint for filtering?
17:06:41 <mugsie> #link https://blueprints.launchpad.net/designate/+spec/filtering
17:06:47 <jaycaz1> #link https://wiki.openstack.org/wiki/Designate/Blueprints/Filtering_API
17:06:56 <jaycaz1> both of these
17:07:16 <jaycaz1> the main question I have is this:
17:07:49 <jaycaz1> we know we want a tenant to be able to filter by address within a single recordset using /zone/id/recordsets/id/records?data=...
17:08:02 <mugsie> yup
17:08:16 <jaycaz1> and, from what eankutse has specified, we would like to have an all_tenants option for admins
17:09:06 <jaycaz1> but should there also be an option for individial tenants to be able to search for an address through all their zones with one command?
17:09:30 <jaycaz1> something similar to what admins would be able to do, but just within everything the tenant owns
17:09:31 <mugsie> for filtering (in my opinion) no
17:09:40 <betsy> is that more of a serach function than filtering?
17:09:53 <jaycaz1> I suppose so
17:09:56 <mugsie> I think that would fall under the search plugin we discussed in atlanta
17:10:07 <jaycaz1> however, would the all_tenants option not be search also?
17:10:26 <jaycaz1> or is there a table of records for admins to filter?
17:10:35 <jaycaz1> sorry, I'm just not familiar with the details
17:10:49 <mugsie> jaycaz1, they would not be able to filter on records from all teneants
17:10:59 <betsy> The bp isn’t marked as approved. Is it worth it for everyone to review the bp and get the details finalized?
17:11:10 <mugsie> they may be able to filter across all zones - but no sub resources
17:11:42 <jaycaz1> okay, so then would filtering by address across all tenants not be possible for admins then?
17:11:58 <mugsie> not as far as i would have read that spec
17:12:24 <mugsie> (or discussed before) - i think they were all based around the search plugin
17:12:29 <timsim> Unless there was a specific v2/records v2/recordsets endpoint I guess?
17:12:42 <jaycaz1> that was discussed in an earlier IRC meeting
17:12:51 <jaycaz1> the possibility of adding another endpoint like that
17:13:11 <mugsie> v2/records etc? yeah
17:13:32 <jaycaz1> so, if that was added, would filtering be possible then?
17:13:58 <mugsie> possibly - but it would break our current api design
17:14:08 <betsy> I thought we had discussed earlier having a filtering functionality and a search funtionality with a separate endpoint
17:14:23 <mugsie> yeah -  the idea was to fix this with a search enbdpoint
17:14:32 <betsy> But those discussions never got finalized, as I remember
17:14:44 <mugsie> we did some high level talking in atlanta
17:14:44 <timsim> So filtering Recordsets by RData is out of the question?
17:15:19 <mugsie> timsim, i think so at the moment
17:15:31 <eankutse> timsim: you mean for A record?
17:16:21 <jaycaz1> right now, you can filter the records in a single recordset, by data
17:16:21 <timsim> I mean we can filter records in a recordset right now.
17:16:30 <jaycaz1> so for A records, that would be filtering by address
17:17:42 <mugsie> timsim, i think we changed that actually, so you should be able to filter recordset by type - i think recordsets now have a type associated with them
17:17:52 <betsy> Yes
17:18:03 <mugsie> #link https://wiki.openstack.org/wiki/Designate/Blueprints/Recordset_Record_API_Redesign
17:18:09 <betsy> And when I get my changes checked it, there won’t be a record resource any more
17:18:43 <timsim> recordset/id/records/?data=1.2.% works. Yeah you can filter recordsets by type. But if you take away the records endpoint, shouldn't you extend the filtering to actually filter the records?
17:19:00 <timsim> as well as the type of the rrset?
17:19:23 <mugsie> yes, I think so - that will need to be added to the filtering API BP
17:19:38 <mugsie> eankutse, you still looking after that?
17:19:52 <eankutse> not at the moment
17:19:56 <timsim> mugsie: I think jaycaz is doing that now.
17:19:56 <jaycaz1> I made some changes to it recently
17:20:05 <mugsie> ok - cool
17:20:12 <timsim> As far as filtering across all tenants though, we're thinking that should be more of a search function?
17:20:15 <betsy> We should assign the bp to jaycaz1
17:20:25 <jaycaz1> If we have a solid idea of what should be done, I'd be more than happy to fix the bp
17:20:34 <mugsie> #action jaycaz1 to investigate filtering on record data via recordsets API endpoint
17:20:51 <mugsie> jaycaz1, and you have the action to look at it ;)
17:20:53 <rjrjr_> update the BP and let's review?
17:20:56 <mugsie> yeah
17:21:29 <mugsie> timsim, yes - i think for recordset / record data filtering across tenants, that would be a search
17:21:54 <mugsie> filtering should only reduce the entries returned from an endpoint
17:22:13 <mugsie> and at the moment, admins have no way of getting all records across designate
17:22:29 <mugsie> they can get all zones, but not recordsets
17:22:41 <timsim> mugsie: Right, so with that logic searching for a zone system-wide would be the same thing. Basically any admin system-wide thing needs to be in a search function.
17:22:47 <mugsie> (the recordset list is inheritantly limited to a zone)
17:23:17 <mugsie> well, if an admin did a v2/zones?all_tennants=true  that could allow it
17:23:17 <rjrjr_> timsim: seems that way.
17:23:30 <mugsie> but I would prefer a search method
17:23:35 <mugsie> (for consistancy)
17:23:49 <rjrjr_> search across zones, filter within zone
17:23:50 <timsim> mugsie: Is that how you get all zones?
17:24:08 <mugsie> eh.... not sure if that ever got implemeted
17:24:33 <mugsie> it was brought up as a possiblity a while ago
17:24:41 <timsim> Yeah I don't think you can actually get all zones in the system
17:24:46 <mugsie> but I don't think we ever agreed on it
17:25:09 <timsim> I agree that basically all of that functionality other than narrowing down already apparent resources should be in a search module.
17:25:22 <jaycaz1> If admins canot get all zones, then would the all_tenants option be a search feature instead of a filtering feature?
17:25:41 <mugsie> yesh
17:25:44 <mugsie> yeah*
17:26:21 <mugsie> anything else on this item
17:26:22 <mugsie> ?
17:26:41 <betsy> So what’s the action?
17:27:07 <mugsie> jaycaz1, to investigate the filtering of record data from the recordset endpoint
17:27:17 <mugsie> and update the filtering api bp
17:27:42 <timsim> We're good.
17:27:43 <jaycaz1> I could also add something about search on the wiki and move the features that were on the filtering bp over
17:27:45 <mugsie> and we need to discuss the search endpiont i detail at some point soon
17:27:48 <betsy> So now action on the search functionality
17:27:52 <jaycaz1> the ones that belong in search, not filtering
17:27:54 <betsy> ok
17:28:11 <mugsie> betsy: i think we could spend a whole meeting on search ;)
17:28:22 <betsy> oh, yeah
17:28:25 <mugsie> ok, moving on
17:28:30 <mugsie> #topic Pools BP - Overview
17:28:36 <mugsie> #link https://review.openstack.org/#/c/101298/
17:28:43 <betsy> that was supposed to be ‘no’ action
17:28:59 <mugsie> ah - that make more sense ;)
17:29:07 <betsy> :D
17:29:08 <mugsie> have people seen ^ ?
17:29:17 <timsim> Not me.
17:29:22 <betsy> nope
17:29:32 <mugsie> It is a WIP (aka ready for comment)
17:29:32 <vinod1> I wanted some clarification on GET /v2/pools/<pool-id>/servers/<server-id>
17:29:39 <mugsie> vinod1 - shoot
17:30:02 <timsim> Is there a place to see it rendered?
17:30:07 <mugsie> this is a first draft, waiting for people to put in put, ad show up my memeory ;)
17:30:10 <betsy> yes
17:30:10 <mugsie> yeap
17:30:13 <vinod1> essentially how nameserver, hostname, hosts are related/different
17:30:19 <vinod1> #link http://docs-draft.openstack.org/98/101298/1/check/gate-designate-specs-docs/f195cd5/doc/build/html/specs/juno/server-pools.html
17:30:45 <mugsie> vinod1, for most installations, they will be the same
17:31:10 <mugsie> but if you are a large provider - a nameserver is a collection of hosts, with a hostname
17:31:29 <mugsie> and the hostname may point to a loadbalencer, which points at the hosts
17:31:56 <mugsie> so this allows us to have a single VIP, that is backed my multiple hosts
17:32:17 <vinod1> so end users who want to get dns names resolved use nameserver?
17:32:27 <mugsie> yes
17:32:34 <mugsie> that is what is shown to users
17:33:13 <vinod1> where/how would the pool mgr resolve the hostname and hosts (from names to ips?)
17:33:43 <mugsie> whatever the dns resolvers are on the machine running the pool mgnr
17:33:52 <mugsie> or you can just put ips in as the hosts
17:34:05 <mugsie> the pool manager will only talk to the hosts
17:34:42 <vinod1> so the nameserver is what goes out in the SOA records - correct?
17:34:52 <mugsie> yes
17:35:19 <vinod1> and the hosts are what the pool mgr notifies the zone changes?
17:35:27 <mugsie> yeap
17:35:54 <vinod1> when a new zone is created - what would the pool mgr do?
17:36:21 <mugsie> use the backend to create the zone on each host
17:36:49 <mugsie> (we will have the simplified backends remember, they are now going to be loaded in the pool manager
17:36:57 <vinod1> so we would still need backends for creation (and deletion?)
17:36:57 <mugsie> not in central)
17:37:17 <mugsie> yes - pools doesn;t remove that unfortunatly
17:37:20 <rjrjr_> creation, deletion of zones and TSIG keys.
17:37:29 <mugsie> rjrjr_, yup good point
17:37:31 <shakamunyi> mugsie++
17:38:05 <vinod1> so coming back to the nameserver, hostname, hosts - is hostname used anywhere?
17:39:24 <mugsie> vinod1: eh ... nope
17:39:33 <mugsie> ( i think I typo'd)
17:39:52 <mugsie> and yeah - i did
17:40:05 <shakamunyi> vinod1 AFAIK no
17:40:26 <vinod1> so can we remove it - to make things simpler?
17:40:35 <mugsie> yeah, that was a left over from a previous daft
17:40:45 <mugsie> it should have come out
17:40:53 <mugsie> I will fix that
17:41:14 <mugsie> any other questions?
17:41:26 <vinod1> none from me
17:41:28 <mugsie> if you havent had time to read it, just leave comments on the review
17:41:39 <mugsie> (thats why we created the -specs repo)
17:42:12 <mugsie> #topic Pools BP - Divide Work Items
17:42:30 <mugsie> So - at the bottom there is a table of work items
17:43:19 <mugsie> if people are interested - just leave a comment / email me / ping me on IRC / speak now / send a carrier pidgon*
17:43:44 <vinod1> Are there dependencies between the workitems?
17:43:46 <mugsie> * I really want someone to do the carrier pidgin
17:43:59 <mugsie> there is some
17:44:09 <timsim> Might have to be a carrier eagle from here.
17:44:20 <mugsie> timsim, true
17:44:28 <rjrjr_> about carrier pigeon, i'll see what i can do. 8^)
17:44:37 <mugsie> :)
17:45:06 <mugsie> there is a ton of work - we are very dependant on miniDNS first though
17:45:50 <mugsie> any questions / comments?
17:46:07 <eankutse> mugsie: we determined that some pools work can proceed now
17:46:16 <eankutse> right?
17:46:21 <rjrjr_> mugsie: looks good.  we'll get back to you in the next day or so.
17:46:29 <mugsie> yeap - the central / storage stuff can go in
17:46:48 <mugsie> (we will have a config item for a while that defines the "default_pool"
17:46:50 <vinod1> mugsie if you could add the dependencies/what can start now etc in the notes section - that would be helpful
17:46:57 <mugsie> yeap
17:47:13 <mugsie> #action mugsie define dependancies for Pool BP
17:47:26 <betsy> Will we need separate bp’s for those work items like we did for mini dns?
17:47:51 <betsy> And the cool dependency tree that resulted?
17:47:55 <mugsie> betsy: depends on how large that are
17:48:01 <mugsie> they*
17:48:06 <vinod1> Folks planning to take action items - putting in your name in the notes section might be helpful to ensure we don't duplicate efforts
17:48:30 <mugsie> but most likely - and we can use the current bps on launchpad
17:49:01 <mugsie> yeap - or comment in line on the table
17:49:09 <eankutse> mugsie: just want to check my understanding on mini dns and server pool dependencies
17:49:15 <eankutse> for create/delete
17:49:21 <mugsie> yup
17:49:28 <eankutse> pools do not depend on mini dns right?
17:49:34 <eankutse> only for updates
17:49:37 <mugsie> yup
17:50:01 <eankutse> ok. So all that work for pools can proceed along with mini dns
17:50:06 <mugsie> yeah
17:50:11 <eankutse> cool
17:50:36 <mugsie> if the notify stuff gets done - that would be a huge step for pools
17:51:01 <eankutse> yes
17:51:02 <eankutse> agreed
17:51:06 <mugsie> anything else?
17:51:20 <mugsie> ok
17:51:24 <mugsie> #topic Open Discussion
17:51:36 <mugsie> anyone have anything?
17:51:36 <rjrjr_> information about mini-summit?
17:52:08 <mugsie> I don't have any personally - Kiall has been dealing with it
17:52:21 <vinod1> mugsie: do you know the venue of the minisummit (address)?
17:52:25 <mugsie> but I can get it from him / get him to ping you tomorrow?
17:52:25 <timsim> We haven't heard anything from Joe
17:52:51 <mugsie> I *think* it is in Seattle - the last i was told anyway
17:52:58 <rjrjr_> i am a probably, but i need details (dates, location, etc.)
17:53:08 <mugsie> it is 701 Pike St, Seattle, WA 98101
17:53:40 <mugsie> (the office address anyway)
17:53:54 <rjrjr_> do you know which dates?
17:54:01 <mugsie> eh - let me look
17:54:36 <mugsie> July 27 to 29 is what I have
17:54:44 <mugsie> but I thought iot was going to be 2 days
17:54:45 <mugsie> it*
17:55:01 <vinod1> July 27 is a Sunday
17:55:26 <mugsie> but again - will get Kiall (who has been dealing with our HP side, to confirm tomorrow)
17:55:35 <rjrjr_> okay
17:55:48 <mugsie> I had one item - the mailing list
17:56:39 <mugsie> can people try and keep an eye, and reply to designate stuff on the -dev list? Just as we are now incubated - this will cause the traffic to increase
17:56:57 <eankutse> okay
17:57:02 <eankutse> :-)
17:57:05 <rjrjr_> yes (i might have to join)
17:57:08 <mugsie> we have been pretty good so far
17:57:18 <betsy> mugsie: good point
17:57:19 <mugsie> but just to help build the community
17:57:25 <timsim> I'll have to fix my subscription, I go on there and it says I should be getting stuff, but I get nothing.
17:57:29 <vinod1> if i put a filter for designate on the mailing list - i do not get any mails
17:57:34 <timsim> ^^^ that
17:57:35 <mugsie> humm
17:57:36 <vinod1> any ideas?
17:57:51 <vinod1> so i have to remove all filters and then i start seeing mails - all of them
17:57:56 <mugsie> #action mugsie investigate designate mailing list filter
17:58:07 <mugsie> I have no idea - i get all the emails
17:58:18 <timsim> I'll start getting them and filter it myself for now.
17:58:31 <mugsie> I have them go to a folder, unless they have designate in the title
17:58:57 <mugsie> oh, one final note - on saturday our git repo is moving
17:59:16 <mugsie> we will be openstack/designate instead of stackforge/designate
17:59:34 <mugsie> so on monday you may have to update your git remotes
17:59:48 <mugsie> and we are out of time
17:59:50 <eankutse> incubation stuff
17:59:50 <eankutse> huh?
18:00:07 <eankutse> bye
18:00:08 <mugsie> eankutse, yeap - we are now part of the openstack org
18:00:11 <mugsie> :D
18:00:16 <mugsie> #endmeeting