17:02:36 <Kiall> #startmeeting Designate
17:02:37 <openstack> Meeting started Wed Aug 20 17:02:36 2014 UTC and is due to finish in 60 minutes.  The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:39 <Sukhdev> slogan: ah OK
17:02:41 <openstack> The meeting name has been set to 'designate'
17:02:45 <Kiall> Hey all who's here?
17:02:51 <mugsie> o/
17:02:52 <rjrjr_> o?
17:02:54 <betsy> o/
17:02:54 <timsim> o/
17:02:58 <vinod1> o/
17:03:02 <msisk> o/
17:03:04 <paul_glass> o/
17:03:06 <Kiall> #topic Action Items from last week
17:03:06 <eankutse> o/
17:03:14 <Kiall> 1) kiall to talk to infra re SP branch...
17:03:20 <Kiall> Apologies, I've not had a chance yet.
17:03:27 <Kiall> 2) all to review the SP blueprints while the mid-cycle is still fresh.
17:03:39 <Kiall> Based on the email stream, most people have.
17:03:56 <Kiall> When we get to ^ topic, I'll give everyone time to re-read the latest comments.
17:04:02 <Kiall> 3) mugsie to write up SP terminology section in the main SP blueprint.
17:04:10 <Kiall> mugsie: I didn't notice this, did you get a chance?
17:04:24 <mugsie> done - there is discussion happening on it right now though
17:04:40 <mugsie> so, I currently have it open, and am entering the suggestios from vinod1
17:04:54 <Kiall> Ah.. I missed it. Okay, again it'll fall under the SP BP topic.
17:05:03 <mugsie> it is in #link https://review.openstack.org/#/c/101298/5
17:05:16 <Kiall> 4) all to review https://wiki.openstack.org/wiki/Designate/MdnsScalability
17:05:35 <Kiall> I refreshd on it, did others? :)
17:05:46 <timsim> I did :P
17:05:57 <betsy> I looked over it
17:06:01 <mugsie> yup
17:06:02 <eankutse> i did
17:06:08 <Kiall> Okay.. Great
17:06:10 <mugsie> i assumed you did timsim ;)
17:06:14 <Kiall> Last, 5) kiall to put MdnsScalability back on agenda for next week.
17:06:20 <Kiall> Technically, I just left it on the page ;)
17:06:35 <Kiall> #action kiall to talk to infra re SP branch...
17:06:44 <Kiall> I'll update on that one next week.
17:07:05 <Kiall> #topic Release Status (kiall)
17:07:37 <Kiall> 2 weeks until j3 - any concerns? Any reviews needing more attention?
17:08:05 <Kiall> #link https://launchpad.net/designate/+milestone/juno-3
17:08:17 <vinod1> https://review.openstack.org/#/c/107678/
17:08:29 <vinod1> https://review.openstack.org/#/c/107951/
17:08:51 <vinod1> Not related to j3 - but wanted to ensure that you looked at it Kiall
17:09:18 <Kiall> vinod1: ahh, yes. They + the update needs to land. I can't approve them myself though.
17:09:43 <vinod1> I −1' it but the CR field shows a check mark
17:09:45 <Kiall> And, the 3rd patch should be cherry-picked as a separate patch, so they can actually land now ish.. and we'll get the 3rd one backported ASAP
17:10:24 <mugsie> vinod1: I have a +2 on it
17:10:50 <Kiall> #action kiall to do 3rd backport for stable/i for Session reuse bug.
17:10:58 <Kiall> Will do ^ right after the meeting.
17:11:01 <mugsie> actually - Kiall I ahve no +2/+A on stable/* anymore
17:11:06 <Kiall> should only take a few seconds
17:11:14 <mugsie> vinod do yhou have +2 on that branch?
17:11:18 <Kiall> Ahh.. neither do I
17:11:45 <Kiall> Our ACL for stable/ must be messed up.
17:11:45 <mugsie> if you want I will go update the infra/config perms after this
17:12:12 <vinod1> I do not have +2 permissions either
17:12:29 <mugsie> vinod1: yeha, looks like designate-core are missing perms
17:12:36 <mugsie> if we were integrated this would be normal
17:12:45 <mugsie> but not during incubation
17:12:50 <Kiall> thanks mugsie - I see what's wrong, fungi suggested the refs/heads/* perms would be inherited into refs/heads/stable/*, I guess they don't :(
17:12:55 <Kiall> ( https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/gerrit/acls/openstack/designate.config )
17:12:59 <mugsie> kk
17:13:03 <mugsie> action me ;0
17:13:12 <Kiall> #action mugsie to fix Designate stable branch ACLs
17:13:54 <vinod1> Kiall - is the TSIG bp still targetted for j3?
17:13:58 <Kiall> Okay - I've got 2 mDNS TSIG blueprints assigned to me, but I've let them slip.. I'm likely not going to have time until the weekend to complete them, but they will make it into j3 :)
17:14:21 <Kiall> vinod1: snap ;)
17:14:50 <Kiall> mugsie: zone-migration-between-tenants <-- That was pretty much ready to land, but needs a rebase after the sqla core change.
17:15:14 <fungi> Kiall: they should be inherited if there are no exclusive group permissions set
17:15:16 <eankutse> yes
17:15:25 <mugsie> Kiall: yeah, and eankutse found a few issues as well
17:15:33 <Kiall> Once that + eankutse's comments are addressed, vinod1 / betsy / myself - can we priotize reviewing and +2'ing if we're happy it's ready?
17:15:41 <mugsie> i just have to move models stuff -> tables etc
17:15:45 <mugsie> yup
17:15:48 <betsy> Sure
17:16:02 <vinod1> yes
17:16:23 <fungi> Kiall: so that acl looks like it should allow designate-core to +2 and approve things in refs/heads/stable/* but maybe it doesn't work the way we thought
17:16:26 <vinod1> Once Betsy is done with the SOA change, I will update the AXFR change too
17:16:26 <Kiall> fungi: it seems exclusive get's inherited from All-Projects, oh well, mugsie will submit a review later to fix - could you review when he does? :)
17:16:46 <fungi> Kiall: quite possible that exclusive in all-projects does trump it, yes. oh well
17:17:01 <Kiall> fungi: no harm, learned something new and all that :)
17:17:08 * fungi nods
17:17:49 <Kiall> vinod1: ++ that set of changes would then effectively complete juno features. I'd be very happy to see that :)
17:18:43 <Kiall> Okay, Any other release related things to discuss?
17:18:48 <Kiall> Ooo - I do have 1 actually.
17:19:10 <Kiall> I've told ttx that we're not going to apply for graduation from incubation this cycle, being so soon.
17:19:14 <Kiall> Any objections?
17:19:18 <mugsie> nope
17:19:27 <eankutse> no
17:19:55 <timsim> Sounds good.
17:20:07 <vinod1> Agreed
17:20:09 <Kiall> Okay.. Moving on so as nobody is giving out :)
17:20:14 <Kiall> #topic Server Pools Specifications (rjrjr - followup)
17:20:39 <Kiall> First up, can we all take 5-10 mins to re-read the latest batch of comments? they all flew in over the last 30 mins :)
17:20:50 <Kiall> #link https://review.openstack.org/101298
17:20:55 <Kiall> #link https://review.openstack.org/112688
17:20:59 <Kiall> #link https://review.openstack.org/113462
17:21:03 <Kiall> #link https://review.openstack.org/113447
17:21:21 <Kiall> Please let the room know when your finished :)
17:24:21 <timsim> I'm good.
17:24:33 <mugsie> done
17:25:01 <eankutse> ready
17:25:12 <rjrjr_> done
17:25:37 * Kiall feels slow -_-
17:25:54 <mugsie> feels....
17:25:58 <mugsie> :D
17:27:10 <betsy> ready
17:27:15 <Kiall> Done
17:28:08 <Kiall> 1 general comment from me, the main BP needs to have the info that's dup'd in the sub-bp's removed, e.g. storage/schema changes etc..
17:28:54 <mugsie> well, they don't all agree yet - untill they do, they should stay
17:29:10 <timsim> mugsie: +1
17:29:21 <betsy> But we should have all the discussions in one place, not two
17:29:24 <betsy> Too confusing
17:29:36 <rjrjr_> betsy: +1
17:29:36 <mugsie> yup - but they are currently a point of reference
17:29:47 <mugsie> so, the discussion should happen on the sub specs,
17:29:56 <betsy> mugsie: cool
17:30:07 <Kiall> Yep, I ignored sections of the main spec that were dup'd by sub-specs..
17:30:07 <mugsie> but they reference in the main spec should stay until there is agreement in the sub spec
17:30:28 <betsy> mugsie: +1
17:30:31 <rjrjr_> generally, i agree with all the comments on storage/pool manager
17:30:51 <rjrjr_> timsim pointed out the missing status table.  i'll add that.
17:31:15 <rjrjr_> do need direction on threshold impact on zone creation/deletion.
17:31:27 <Kiall> Yes, tim also pointed out the missing periodic sync stuff, I'm not 100% sure which BP that belongs in. mugsie?
17:31:52 <Kiall> (periodic sync was for fixing the list of zones managed by a server, for cases where a server was down during create/deletes etc)
17:31:59 <timsim> I thought it'd be part of the Pool Manager one, since it'd be part of the base PM plugin (imo)
17:32:10 <mugsie> i thinkit is manager
17:32:18 <rjrjr_> okay, i'll take care of it.
17:32:19 <mugsie> as it should be a responsiblity of the maager
17:32:52 <rjrjr_> my intent was to push as much of the table creation, unit testing for objects, etc. into storage as possible.
17:32:52 <Kiall> #action rjrjr_ to incorporate periodic sync into SP manager spec
17:33:15 <vinod1> Also the last line states
17:33:15 <vinod1> "**This specification is work in progress.**"
17:33:15 <vinod1> Does that mean that there are more additions intended for the spec?
17:33:52 <rjrjr_> no, it meant as i saw it, the spec wasn't done. 8^)
17:33:52 <Kiall> Hah, I missed that :) I guess it does
17:34:36 <Kiall> Okay, anyone have any particular issues with the specs they think needs discussion? I have one, but it can wait till the end :)
17:35:08 <eankutse> I have one
17:35:11 <vinod1> I had some comments on the terminology section
17:35:17 <rjrjr_> do we take threshold into account for server creation or require 100%?
17:35:33 <rjrjr_> server = zone
17:35:55 <Kiall> rjrjr_: that was my one :) Let's take vinod1's first though...
17:36:15 <Kiall> vinod1 / mugsie - have you come up with better terms? Want to discuss them here first?
17:36:34 <mugsie> no, I understand the comments vinod1 left
17:36:47 <mugsie> unless anyone has any other issues before I edit the,
17:36:49 <mugsie> them*
17:37:10 <Kiall> They look find with vinod1's comments to me, anyone else?
17:38:00 <eankutse> mugsie:
17:38:09 <eankutse> regarding zone-migration-between-tenants (https://review.openstack.org/#/c/107822/),
17:38:21 <eankutse> specifically on endpoint /transfer-requests parameter 'target_project_id' which specifies to the tenant to which the zone is being transferred.
17:38:38 <eankutse> Right now, the default is 'all'. So if  the caller/user forgets to provide a specific value (tenant) for that parameter when they actually intended to provide one, that would result  in an unintended transfer to all that would then require admin involvement to delete that pending transfer request.
17:38:51 <rjrjr_> different subject?
17:39:11 <eankutse> still on spec
17:39:22 <eankutse> sorry:-)
17:39:31 <eankutse> I'll wait
17:39:48 <mugsie> :)
17:39:55 <mugsie> anyhting elese on SP's
17:39:56 <Kiall> Kinda ;) Anyway, transfer requests to all can be deleted, and the receiver must know the transfer code (can't remember exactly what it's called) to be able to accept it
17:39:56 <mugsie> ?
17:40:21 <eankutse> Just to avoid potential problems, I think we should make the 'target_project_id' also required and with no default value. Then have a special value that the 'target_project_id has to be set to to assume the semantics of "all projects".
17:40:21 <Kiall> More of the SP Stuff: I left a comment suggesting we discuss the % thresholds and if they apply to create/update zone in SP manger - http://docs-draft.openstack.org/62/113462/3/check/gate-designate-specs-docs/d7ea6b4/doc/build/html/specs/juno/server-pools-service.html#design-considerations
17:41:24 <mugsie> I would say it is 100% or nothing for zone create...
17:41:28 <mugsie> but i may be wrong
17:41:34 <rjrjr_> +1
17:41:47 <Kiall> mugsie: when you have 100 servers around the world, one of them is pretty much always bound to be down
17:42:06 <betsy> kiall: that would be my concern
17:42:09 <vinod1> Isn't that going to be configurable?
17:42:27 <Kiall> I'd argue a threshold applies, maybe not the same threshold, but not forced to 100%
17:42:27 <eankutse> we talked about that, yes.
17:42:45 <betsy> kiall: +1
17:42:51 <Kiall> vinod1: we discussed it in relation to zone updates being pushed out, rather than create/delete zone actions
17:42:52 <timsim> I thought it'd apply to all operations.
17:43:17 <vinod1> timsim: That was my understanding too
17:43:40 <rjrjr_> maybe have 2 threshold values, one for zone updates and another for zone create/delete?
17:43:48 <Kiall> it sounds like most everyone thinks a threshold should be applied to those operations too, with the periodic sync cleaning up once servers are brought back online.
17:43:51 <timsim> If the PM was going to be the one that updated the status of changes, it makes sense for it to update everything.
17:43:58 <timsim> Kiall: Yup.
17:44:16 <betsy> rjrjr_: Why would you need 2 different threshold values?
17:44:20 <Kiall> What about reusing the same %, should we have 3 threshold values? 1 for Create, 1 for waiting on updates, 1 for deletes? or just update / create+delete 2?
17:44:29 <Kiall> or just 1?
17:44:48 <mugsie> i think just 1
17:44:55 <vinod1> Why/When would you want to have different thresholds?
17:45:11 <timsim> I'm kind of a fan of just one. Keep it simple. But it'd be easy to change.
17:45:22 <Kiall> timsim: ++ on the easy to change
17:45:29 <vinod1> Asking another way - When it would be okay to have a create/delete happen but not an update or vice versa?
17:46:01 <rjrjr_> the period sync will handle problems, so 1 makes sense to me.
17:46:02 <Kiall> My thinking on multiple is, for create anyway, you may want it higher.. e.g. if an update doesn't 100% go out, you're just serving slightly stale data (welcome to DNS!) If the create doesn't go out to enough servers, you're sending NXDOMAINS
17:46:03 <vinod1> timsim: ++
17:46:41 <Kiall> But I'm happy either way really, it's not hard to change after the fact if we need to..
17:47:28 <timsim> Let's go with one for now, and keep that in mind, should that issue present itself?
17:47:37 <mugsie> I think we run with one right now, and if we need to change it later we do... that sound good?
17:47:43 <Kiall> timsim: agreed. Let's go with A) Yes it applies, and B) Use the 1 threshold value for the moment.
17:47:50 <rjrjr_> +1
17:48:02 <mugsie> ++
17:48:25 <rjrjr_> one more question, can i assume the new records tables will be in place before this work starts?
17:48:54 <betsy> rjrjr_: I don’t think so. No one’s working on them
17:48:56 <timsim> rjrjr_: I don't think so.
17:48:56 <Kiall> Anything else on this round of SP discussion? We'll come back to it next week again for a (shorter) talk... Next week will be nearing release day so we should focus there :)
17:49:20 <rjrjr_> probably no direct impact, but the name_servers will come from those tables for the pool (or the servers table.)
17:49:24 <Kiall> Yea, I would love to see that in Kilo, but it's a big chunk of work
17:49:48 <rjrjr_> i'll need to add columns to the servers table to support this.
17:50:15 <Kiall> Yea, I figured "severs" would be adapted/renamed to suit :)
17:50:16 <betsy> And does the server api need to be ported to v2?
17:50:26 <Kiall> betsy: no, pool API replaces it
17:50:36 <betsy> That’s what I thought
17:50:48 <betsy> but the change to the server table confused me
17:50:52 <Kiall> FYI - 10 mins on the clock..
17:51:14 <rjrjr_> server tables needs pointer to pool table.
17:51:22 <Kiall> betsy: I think "servers" get's renamed to "pool_nameservers" (or whatever term we decide on)
17:51:45 <Kiall> and pool_id added as rjrjr_ suggests..
17:51:47 <betsy> Do we need a separate table to say compatable with v1?
17:51:56 <betsy> stay^
17:52:00 <Kiall> the V1 servers api then uses default_pool_id and does CRUD on only a single pool
17:52:13 <rjrjr_> i'll handle it in the spec.  it will be clear.
17:52:19 <betsy> ok
17:52:19 <Kiall> rjrjr_: excellent :)
17:52:22 <mugsie> cool
17:52:26 <vinod1> How do we get from the pools to the servers in the pools?
17:52:49 <vinod1> Would the pool table have pointers to the servers in the pools?
17:52:57 <mugsie> select from servers where pool_id = pool.id ?
17:53:00 <Kiall> Other way around I would expect
17:53:05 <Kiall> ^ what mugsie said
17:53:20 <vinod1> ok
17:53:25 <Kiall> SELECT * FROM `designate`.`servers` WHERE pool_id = <UUID>
17:53:38 <Kiall> Okay, Moving on, tight on time :)
17:53:49 <Kiall> #topic Follow-up discussion on Database/MiniDNS scalability (timsim)
17:54:00 <Kiall> #link https://wiki.openstack.org/wiki/Designate/MdnsScalability
17:54:02 <timsim> Anyone have any new thoughts on this?
17:54:58 <Kiall> timsim: Nothing I haven't already said :) I think the ideas have merit, we should do scale tests to decide where to concentrate on first, and that all the suggestions don't impact the core, so we can implement them easily over time as needed..
17:55:12 <timsim> We're working on a strategy to do some testing.
17:55:12 <Kiall> What about everyone else? New thoughts?
17:55:39 <Kiall> timsim: I'd love to see that strategy in the form of a rally plugin :P https://github.com/stackforge/rally
17:55:55 <timsim> I think the good bit of what we've suggested here is that none of it breaks the current contracts.
17:56:01 <timsim> Kiall: We'll look into that.
17:56:24 <rjrjr_> just one thought, the idea of each minidns being responsible for every zone in an organization seems crazy.  DNS is a distributed model and so should Designate.
17:57:10 <timsim> rjrjr_: I don't think it's crazy that someone might need every zone in places all over the world.
17:57:37 <Kiall> rjrjr_: DNS is distributed, BUT, every zone has a single "master" (if you follow the specs to the letter), mDNS actually makes that piece more distributed IMO :)
17:57:41 <rjrjr_> how do you handle this in DNS?
17:58:31 <timsim> What's "this"?
17:58:32 <Kiall> Also, mDNS's responsiblties towards a zone is very different to say, BINDs, responsiblties towards a zone it's a master of..
17:58:54 <timsim> ^very true.
17:59:03 <Kiall> And - We're out of time.. rjrjr_ shall we pick this up at the start of next week? I think it's worth discussing.
17:59:19 <Kiall> (discussing properly, with enough time :))
17:59:26 <timsim> Cool!
17:59:41 <Kiall> #action kiall to put "all mDNS responsible for all zones" onto agenda for next week
17:59:56 <Kiall> Okay - Thanks all, Trove needs the room :)
17:59:58 <eankutse> cool
18:00:05 <Kiall> #endmeeting