17:01:01 <mugsie> #startmeeting Designate
17:01:02 <openstack> Meeting started Wed Feb 19 17:01:01 2014 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:06 <openstack> The meeting name has been set to 'designate'
17:01:15 <mugsie> whos here?
17:01:20 <richm> present
17:01:21 <betsy> o/
17:01:30 <eankutse> here
17:01:42 <kiall> heya
17:01:42 <rjrjr_> here
17:01:48 <tsimmons> Here (sort of, on my phone)
17:02:02 <mugsie> #topic Review action items from last week
17:02:16 <mugsie> kiall to review current incubation applications and new "limits" on # per cycle
17:02:40 <mugsie> kiall: any update?
17:02:53 <kiall> So - I've left looking into incubation stuff to Alex for the moment, I'll organize a call with him soon to sync up
17:02:58 <mugsie> cool
17:03:00 <mugsie> Regroup on Talks+WS at 17:00 UTC tomorrow (Thursday)
17:03:09 <mugsie> that was done, and 3 talks were submitted
17:03:17 <mugsie> kiall to condense mini-summit dicussions into MiniDNS spec
17:03:43 <kiall> ehh.. I totally forgot about that item.. Apologies, next week.
17:03:43 <mugsie> this to be moved to next week kiall?
17:03:47 <mugsie> ok
17:03:55 <mugsie> #action kiall to condense mini-summit dicussions into MiniDNS spec
17:04:11 <mugsie> #topic review/add new blueprints as needed to track smaller work items
17:04:34 <eankutse> looks like this was for all
17:04:38 <mugsie> I have started to do this, and I have noticed that all of the new bp's filled are much shorter
17:04:57 <mugsie> yup, we said this was to be standing, so unless anyoine has a question, i will move o
17:05:00 <mugsie> on*
17:05:02 <kiall> Yep - minidns needs the same treatment, once the spec is refreshed
17:05:11 <mugsie> #topic mini-dns, what next?
17:05:28 <mugsie> i think this relates to ^
17:05:38 <mugsie> unless kiall you have an update?
17:05:51 <kiall> Next steps are on me again right now - refresh the spec, split blueprints, and get that POC code together.
17:06:16 <mugsie> #action kiall: MiniDNS -  refresh the spec, split blueprints, and get that POC code together.
17:06:32 <mugsie> ok to ove on?
17:06:36 <mugsie> move*
17:06:51 <kiall> Nothing from me right now, too many other things on my plate this week
17:07:22 <mugsie> ok
17:07:25 <mugsie> #topic What should we call "miniDNS"?
17:07:41 <mugsie> before we get into a 90min debate about this
17:07:47 <mugsie> I have a suggestion
17:08:06 <mugsie> for next week we all put our Ideas in the wiki (in the meeting page)
17:08:14 <mugsie> and a simple vote in 7 days time
17:08:18 <kiall> I thought this was going to be listed as a future item?
17:08:33 <betsy> mugsie: excellent idea
17:08:50 <mugsie> I moved it up, purely as it is going to start getting referneced everywhere soon
17:09:12 <mugsie> #action All: Put name ideas for miniDNS on wiki
17:09:18 <mugsie> any other comments?
17:09:36 <rjrjr_> sounds good
17:09:41 <eankutse> cool
17:09:48 <mugsie> #topic Icehouse 2 Release - 2014-02-19 (mugsie)
17:09:57 <eankutse> on Mini DNS
17:09:59 <eankutse> POC
17:10:05 <eankutse> can we spend a couple of minutes
17:10:06 <eankutse> ?
17:10:15 <mugsie> cool.
17:10:17 <eankutse> Been looking at dnspython for miniDNS POC. Looks like dnspython is more of a Client-side library. So while it can send an AXFR query, it cannot send an AXFR response.
17:10:17 <eankutse> Will look around a bit more to see if there are other python libraries out there that are more Server-side centric that can respond to AXFR queries.
17:10:22 <mugsie> #topic MiniDNS POC
17:10:45 <kiall> eankutse: I believe it can, it just don't have a "send response" method
17:10:48 <eankutse> Does anyone else know about dnspython who could confirm?
17:10:56 <eankutse> ok.
17:11:12 <kiall> the core of dnspython, and the piece we're interested in, is the protocol parser
17:11:25 <eankutse> ok
17:11:43 <eankutse> I'll check that out
17:11:45 <eankutse> thx
17:11:54 <kiall> It should be a case a building up the appropriate objects, and calling o.to_wire() to serialize it
17:12:11 <eankutse> great!
17:12:29 <richm> for the wiki to put the list of names - which page should we use - https://wiki.openstack.org/wiki/Designate ?
17:12:41 <mugsie> #link https://wiki.openstack.org/wiki/Meetings/Designate
17:12:48 <mugsie> i would say there, in an Agenda Item
17:12:53 <richm> ok
17:13:06 <mugsie> #topic Icehouse 2 Release - 2014-02-19 (mugsie)
17:13:25 <mugsie> I suggesting we make an 12 release today
17:13:41 <mugsie> all bugs / bp's filed against it are fix commited / implemented
17:14:15 <mugsie> does that seem ok?
17:14:15 <kiall> I'd like to get https://review.openstack.org/#/c/74655/ and https://review.openstack.org/#/c/73717/ merged if we do.. Both small + simple changes
17:14:30 <kiall> "Ensure default DB connection strings use unique defaults" and "Default state-path to /var/lib/designate"
17:14:38 <mugsie> OK
17:15:17 <mugsie> anything else people think is required?
17:15:43 <vinod> i think we need betsy's blacklist fix
17:15:49 <vinod> yet to be done
17:16:03 <vinod> this is the issue that ekarlson bought up yesterday
17:16:05 <betsy> I was just going to ask that
17:16:23 <tsimmons> It'll mess up DB migrations for people using MySQL of
17:16:24 <betsy> mysql isn't happy with it over 255
17:16:27 <kiall> vinod: Yea, agreed.. Ideally we fix that before putting it into a release
17:16:30 <tsimmons> If there isn't a fix.
17:16:38 <mugsie> yup
17:16:42 <betsy> Changing it back to 255 fixes it
17:16:45 <betsy> I can put that in today
17:16:59 <mugsie> for i2 i think ^ is aceptable
17:17:09 <kiall> betsy: I think switching to a varchar will do it..
17:17:28 <kiall> actually.. it already is
17:17:31 <betsy> It is showing up as a varchar, which is what's puzzling
17:17:39 <betsy> The error is a key size error
17:17:48 <betsy> Even changing it to 280 gave the same error
17:17:56 <betsy> I was playing with it all night
17:18:28 <betsy> 255 is probably big enough anyway
17:18:37 <betsy> Unless someone has another suggestion
17:18:41 <kiall> betsy: lets shrink it to 255 with another migration, and we can increase it with a fix later if needs mbe
17:18:46 <mugsie> +1
17:18:57 <betsy> That was my other question
17:19:10 <betsy> Do I have to do another migration on top of the one I did or can I change the migration I did?
17:19:23 <mugsie> will that migration not break stuff if left in?
17:19:33 <kiall> betsy: generally, once a migration is in.. you should avoid touching it if at all possible.
17:19:51 <kiall> since this migration works (until you try querying the table), I'd add another on top to reduce it
17:19:52 <betsy> I know, but then I thought the same thing mugsie just brought up
17:20:03 <betsy> It doesn't work on a mysql migration
17:20:14 <tsimmons> I believe I got the error during the migration.
17:20:15 <kiall> Really? The Jenkins slave runs it just fine!
17:20:17 <betsy> The table won't even get set uo
17:20:34 <betsy> I know, but when I have a mysql db set up, the install blows up
17:20:34 <mugsie> i would say we should fix the migration
17:20:42 <betsy> Tim had the same problem
17:21:21 <kiall> mugsie: the issue with "fixing" the migration is, it leaves anyone who's already ran it with a different DB
17:21:36 <kiall> But.. If it's blowing up for some people, there's not much choice
17:21:38 <mugsie> yes, but the issue with the migration is it blows up peoples db ;)
17:21:51 <betsy> Ikr?
17:22:00 <betsy> I kept going back and forth in my own mind
17:22:01 <vinod> how about deleting that migration and adding a new one?
17:22:11 <betsy> Same thing as fixing this one
17:22:14 <mugsie> vinod: same issue
17:22:23 <kiall> vinod: same issue, the # is tracked inside the DB
17:22:55 <kiall> betsy: lets talk after, it should be possible to remove the content of that migration, and conditionally create / size down in the next one
17:22:57 <mugsie> so i think we are agreed
17:23:16 <betsy> okay. Let's continue discussion afterwards
17:23:21 <mugsie> ok, cool
17:23:48 <mugsie> after a patch for 1282164 land i will release
17:23:52 <mugsie> lands*
17:24:10 <mugsie> #topic Icehouse 3 Release - 2014-03-06 (mugsie)
17:24:28 <mugsie> kiall: want to run though this
17:24:30 <mugsie> ?
17:24:51 <kiall> Sure..
17:25:37 <kiall> So.. i3 is due March 6th.. I think we should do everything we can to hit that date, and aim have all user facing stuff "complete" (e.g. any remaining end-user API changes etc)
17:26:08 <kiall> The reasoning being .. We want to demonstrate we can hit these dates for incubation..
17:26:19 <betsy> kiall: agreed
17:26:23 <kiall> (We haven't been so far..)
17:26:42 <eankutse> and we identified what it is that we'd like in it right?
17:26:55 <mugsie> as part of this I think we need to log any and all bugs with V2 API by friday, and then prioritse them
17:27:00 <kiall> So .. We need to identify all remaining gaps in APIv2, and what the minimal changes in order to get the user facing piece right
17:27:03 <eankutse> we marked the blueprints that we want in it
17:27:42 <kiall> eankutse: no, we need to circle back and identify exactly whats missing
17:27:57 <mugsie> #link https://launchpad.net/designate/+milestone/icehouse-3
17:28:04 <mugsie> what is currently targetted
17:28:15 <kiall> e.g. as an end user of someone's Designate install, can they do everything they can do in V1 today, in V2?
17:28:27 <kiall> If not - that gap needs to filled ASAP
17:28:55 <eankutse> k
17:29:38 <kiall> So .. Over the next day or two, can we start getting a list together here?
17:29:40 <kiall> #link https://etherpad.openstack.org/p/designate-v2-gaps
17:29:55 <kiall> then, we'll get tickets fixed etc and start filling them
17:30:15 <mugsie> #action All: Fill gaps in API V2 in https://etherpad.openstack.org/p/designate-v2-gaps
17:30:54 <mugsie> cool. Anything else people have for the i3 release?
17:31:16 <kiall> Not from me
17:31:45 <rjrjr_> no
17:32:01 <mugsie> #topic Server Pools Master BP
17:32:04 <eankutse> I feel like we are in a crunch :-)
17:32:05 <vinod> currently v2 api is disabled by default
17:32:15 <vinod> when will we be enabling it?
17:32:15 <mugsie> vinod: yup
17:32:19 <vinod> for i3?
17:32:30 <mugsie> in i3 (if it 100%) ?
17:32:37 <vinod> ok
17:32:45 <kiall> vinod: When we think it's stable enough - which is hopefullty i3
17:32:47 <kiall> hopefully*
17:32:53 <betsy> does that include the paging?
17:32:58 <mugsie> betsy: yes
17:33:15 <eankutse> and miniDNS
17:33:17 <kiall> ekarlso has been working on the paging, it looks to be 95% there..
17:33:22 <mugsie> eankutse: no
17:33:23 <kiall> eankutse: lol
17:33:28 <eankutse> whew!
17:34:01 <mugsie> #link https://blueprints.launchpad.net/designate/+spec/server-pools
17:34:06 <betsy> What about updated docs?
17:34:17 <mugsie> We can do those as part of the rcs
17:34:18 <vinod> #link https://blueprints.launchpad.net/designate/+spec/v2-api-documentation
17:34:21 <mugsie> RC's
17:34:37 <betsy> mugsie: okay
17:34:43 <kiall> betsy: in true openstack tradition, they can come in about 2 years (kidding..) I'd say those should be worked out after i3, before "icehouse proper"
17:34:58 <mugsie> +1
17:35:34 <betsy> okay
17:35:47 <mugsie> so, as we discussed in austin, I have broken down Pools into smaller chunks
17:36:23 <mugsie> We also discussed having these running as small groups, who wouold then report the progress to here, in a msaller form
17:36:36 <kiall> Random rant.. Ideally, while the launchapd BP's might be split, I'm not sure I like splitting the wiki blueprint up. Makes it much harder to follow
17:36:36 <mugsie> if anyone is interested in doing that, let me know
17:36:58 <mugsie> kiall: really? I find it easier
17:37:24 <kiall> Yep - really, having to cross reference piles of wiki pages to see the whole change is awkward!
17:37:34 <kiall> e.g. storage changes are here.. https://wiki.openstack.org/wiki/Designate/Blueprints/Server_Pools/Storage
17:37:41 <kiall> api changes are here https://wiki.openstack.org/wiki/Designate/Blueprints/Server_Pools/API
17:37:52 <kiall> how it integrates with MiniDNS is here.. https://wiki.openstack.org/wiki/Designate/Blueprints/Server_Pools/MiniDNS
17:37:55 <mugsie> and....
17:37:56 <kiall> Theres about 15 of them ;)
17:38:00 <mugsie> 8
17:38:07 <mugsie> but i still dont see the problem
17:38:24 <mugsie> they are designed to be worked on in isolation
17:38:37 <vinod> I would agree with kiall - with the wiki - having one makes it easier to understand the bigger picture
17:38:58 <mugsie> it would make it one massive page
17:39:09 <kiall> Right - But getting an idea of the whole thing is important. With that split, it's MUCH harder to do that without a photographic memory of all the other pages besides the one you currently have open.
17:39:09 <eankutse> +1. Keep design in one place.
17:39:43 <mugsie> ok - i will look at it later
17:39:48 <mugsie> but back on topic ;)
17:39:49 <kiall> as the author, it might be easier for you, since you know the content inside out.. for the rest of us.. not so much ;)
17:39:55 <tsimmons> You could have both, put it all in one place and then have smaller pages too if you just want to look at one thing.
17:40:17 <betsy> As long as they all link off of one page -- Server Pools.
17:40:17 <mugsie> anyone who is interested in get involved, I will send an email to the -dev list later on today
17:40:22 <mugsie> betsy: they are
17:40:59 <mugsie> the reason i did it is it would be impossible to link off the serverpools-api spec, and have it show what that signle bp is doing
17:41:12 <mugsie> if it is all on one page
17:41:37 <betsy> mugsie: Ah good point
17:41:41 <kiall> The launchapd BP description can include text describing which pieces of the main spec are "included"
17:41:55 <kiall> or, you can link to the section headers on the page
17:41:59 <mugsie> that is supposed to be an overall view
17:42:17 <mugsie> so you suggest just copy pasting the sub pages on to one page?
17:42:42 <kiall> Yea - Having a single design document makes it easy to review and grasp
17:42:50 <mugsie> anyway - is everyone on the openstack-dev mailing list?
17:43:15 <rjrjr_> i will be if i am not
17:43:35 <kiall> mugsie: why?
17:43:42 <eankutse> should we all take a look at what mugsie has
17:43:42 <kiall> (I am...)
17:43:50 <eankutse> before we request more changes?
17:43:56 <eankutse> I have not looked at it tho
17:44:10 <mugsie> i would suggest people look at the page before deciding
17:44:11 <eankutse> maybe it's not that bad to navigate
17:44:32 <mugsie> kiall: [17:40] <      mugsie> | anyone who is interested in get involved, I will send an email to the -dev list later on today
17:44:39 <mugsie> getting*
17:44:41 <kiall> mugsie: ah :)
17:45:44 <mugsie> leaving aside the split / no split disscussion - (we can have this in open disscussion) are people happy with me sending the mail to -dev list asking for interest?
17:45:58 <betsy> mugsie: yes
17:45:59 <richm> sounds good
17:46:22 <vinod> #agreed
17:46:31 <rjrjr_> yes
17:46:32 <kiall> Yep - Go for it :) But - Many of the wiki pages are still placeholders though  (I think!), I'd be worth filling them out for people to read :)
17:46:33 <mugsie> #action mugsie: mail openstack-dev with call for interest in server-pools spec
17:46:55 <mugsie> kiall: yup
17:47:02 <mugsie> #topic Open Discussion
17:47:16 <mugsie> any other topics?
17:47:40 <rjrjr_> afraid to bring any more up with the list we have going on!
17:48:00 <rjrjr_> i have an ebay use case i'd like to put out in front of the team.
17:48:11 <rjrjr_> where is the best place to do that?
17:48:11 <mugsie> rjrjr_: cool - shoot
17:48:34 <mugsie> well, if you want to put it on the wiki, or discuss it here? or in an etherpad
17:48:47 <mugsie> anyone else have a suggestion where?
17:49:20 <betsy> We have about 10 more minutes now
17:49:22 <kiall> Nope - These meetings are perfect for it.. Unless it's too complicated an idea, in which case a wiki page detailing would be better!
17:50:05 <rjrjr_> okay.  let's get into it then?
17:50:13 <mugsie> yup
17:50:15 <kiall> yep :)
17:51:12 <rjrjr_> okay.  we have a VPC which is domain dev.ebayc3.com.
17:51:32 <eankutse> what is VPC?
17:51:36 <rjrjr_> tenant A will have a subdomain called tenantA.dev.ebayc3.com.
17:51:50 <rjrjr_> VPC - virtual private cloud.  think of it as a collection of tenants.
17:52:43 <rjrjr_> a new VM will be added to DNS, A record - vm1.tenantA.dev.ebayc3.com - PTR record - 10.0.0.2.
17:53:11 <rjrjr_> the dev.ebayc3.com and 10.0.0/8 will pre-exist as domains in Designate.
17:53:58 <rjrjr_> as tenants are created/destroyed, we want to subdomain the dev.ebayc3.com, but not have a different zone (so all the backend plumbing is in place.)
17:54:49 <kiall> So, rather than tenantA.dev.ebayc3.com being created as an actual zone, tenantA people would have access to the tenantA.dev.ebayc3.com part of dev.ebayc3.com ?
17:55:47 <rjrjr_> correct.
17:56:40 <kiall> Humm - What's the reason for avoiding creating the new sub-zone? Since the parent zone is hosted on Designate, there shouldn't be much in the way of external plumbing to configure?
17:57:15 <rjrjr_> we have about 5000 tenants now.  we'd like to not have 5000 zones.
17:57:31 <rjrjr_> (5000 and growing.)
17:58:57 <rjrjr_> so, i see us sharing domains (10.in-addr.arpa), having subdomains in same zone as parent domain.
17:59:16 <kiall> rjrjr_: Humm, I'm not sure I can think of an easy way to make ^ happen. Sharing a resource among many tenants and then restricting access based on name would be a very different model to what we do today...
17:59:45 <rjrjr_> okay.  i can take this to -dev list.  we have 1 minute.
17:59:58 <mugsie> i do see it being difficult altight
17:59:58 <kiall> It's possible it could be done as an API extension, where that API extension evevates to an admin, so it can get access to the zone, and rejects stuff for the wrong names
18:00:06 <kiall> elevates*
18:00:20 <kiall> ^ would be similar to what we do for FloatingIP calls to neutron
18:00:49 <rjrjr_> i'd like to hear/read more about this.
18:00:55 <kiall> Okay ... That's time. mugsie #endmeeting please ;)
18:01:02 <rjrjr_> main chat?
18:01:07 <kiall> rjrjr_: yep
18:01:12 <mugsie> yeah, lets move to #openstack-dns
18:01:16 <mugsie> #endmeeting