17:00:03 <mugsie> #startmeeting Designate
17:00:04 <openstack> Meeting started Wed Sep 17 17:00:03 2014 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:07 <openstack> The meeting name has been set to 'designate'
17:00:25 <mugsie> Kiall is on another call today, so he wont be joining
17:00:39 <mugsie> who's here?
17:00:49 <mugsie> and i think everyone just netsplit
17:00:50 <rjrjr_> o/
17:01:24 <mugsie> just going to give people a chance to reconnect
17:01:45 <rjrjr_> sure
17:02:07 <betsy> o/
17:02:08 <vinod1> o/
17:02:16 <mugsie> everyone back?
17:02:36 <mugsie> #topic Action Items from last week
17:02:46 <mugsie> kiall to attempt an o/r change for dnspython
17:02:51 <mugsie> I will push that on
17:02:56 <mugsie> #action kiall to attempt an o/r change for dnspython
17:03:03 <mugsie> rjrjr_: Write up on handling error status in server pools
17:03:10 <rjrjr_> it is in the specs
17:03:27 <mugsie> ok cool, I havent had time today to  re read them yet
17:03:29 <rjrjr_> specifically the pool manager spec
17:03:46 <mugsie> ok, do we want to take 4-5mins to read them?
17:04:07 <rjrjr_> i'm okay with that.  vinod, betsy?
17:04:13 <betsy> sure
17:04:49 <vinod1> sure - looks like the build failed - so we need to read the "raw" spec
17:05:39 <rjrjr_> yes, please read the raw.  i'll fix the build failure.  took almost 2  hours to tell me that. 8^)
17:05:50 <betsy> I went over this one quickly before the meeting and had a couple of questions
17:05:57 <mugsie> rjrjr_: yeah - sphinx can be a pain for that ;)
17:08:29 <mugsie> for betsy's second question - could we not use the status field? we may need to add an additional status of DELETE_PENDING, but it saves having extra coloumns
17:08:48 <rjrjr_> where are the questions?
17:08:54 <betsy> I put them in the doc
17:09:08 <mugsie> comments on the review
17:10:27 <mugsie> everyone finished?
17:10:35 <rjrjr_> okay.  for the first comment, we only need to know if the create is ERROR or SUCCESS in pool manager.
17:10:37 <betsy> yes
17:10:46 <rjrjr_> PENDING is a status in the domains table.
17:10:54 <vinod1> yes
17:11:04 <betsy> So, the status is known when that record is written?
17:11:26 <mugsie> yes rjrjr_ I would agree with that
17:11:32 <mugsie> betsy: yes
17:11:37 <betsy> ok
17:11:43 <rjrjr_> it is PENDING in the domain table to start.
17:12:05 <rjrjr_> it will be SUCCESS or ERROR in the status table after each backend is called.
17:12:22 <rjrjr_> then it will be SUCCESS or ERROR in the domain table.
17:12:31 <betsy> ok. makes sense
17:12:42 <mugsie> :)
17:12:55 <rjrjr_> i added a 'deactivate' field to the record table.
17:13:01 <rjrjr_> pertaining to the second question.
17:13:19 <rjrjr_> records table.
17:13:42 <betsy> Right. I was just wondering why the existing status field couldn’t be used
17:13:52 <betsy> instead of the new field
17:13:55 <rjrjr_> but, i can use DELETE_PENDING.  that will work.  the intent is the same.
17:14:05 <rjrjr_> i'll change it.
17:14:10 <mugsie> rjrjr_: I prefer that (not sure why, but I do)
17:14:12 <mugsie> thnaks
17:14:21 <mugsie> overall I think it is good
17:14:31 <betsy> +1
17:14:53 <mugsie> can we move on?
17:15:02 <mugsie> or is there anything else people have on this?
17:15:08 <betsy> I’m good
17:15:17 <mugsie> #topic Release Status (kiall - recurring)
17:15:28 <mugsie> #link https://launchpad.net/designate/+milestone/juno-rc1
17:15:44 <mugsie> anything people are seeing that should be there, or should not be there?
17:16:20 <mugsie> I believe that 1368863 is underway
17:16:22 <betsy> What about https://review.openstack.org/#/c/119890/
17:16:47 <mugsie> yup, adding that now
17:17:25 <mugsie> anything else?
17:17:57 <jordanP> i've just filled : https://bugs.launchpad.net/designate/+bug/1370621
17:17:58 <uvirtbot> Launchpad bug 1370621 in designate "Bing9 PTR Zone error : multiple RRs of singleton type" [Undecided,New]
17:18:18 <jordanP> this is problematic to me, I hope to be able to work on this tomorrow
17:18:28 <vinod1> #link https://bugs.launchpad.net/designate/+bug/1367954
17:18:30 <uvirtbot> Launchpad bug 1367954 in designate "API displays deleted recordsets" [Undecided,Fix committed]
17:18:51 <jordanP> but as I am new to designate, I don't know if I will be able to do much, we'll see
17:19:37 <mugsie> jordanP: I wont target it, but if it gets in before the deadline there should be no problem taking the fix
17:19:57 <jordanP> mugsie, okay
17:20:20 <mugsie> jordanP: actually, I will target it to rc1, we can move it on if needs be
17:20:37 <mugsie> means we will keep it in the list
17:20:45 <vinod1> https://bugs.launchpad.net/designate/+bug/1365996
17:20:51 <uvirtbot> Launchpad bug 1365996 in designate "Downgrading to version 38 fails with AttributeError" [High,Fix committed]
17:20:53 <rjrjr_> it is adding a 2nd SOA record?
17:21:25 <jordanP> rjrjr_, it looks like it
17:21:48 <mugsie> jordanP: is this using the floating IP API, or the standard API?
17:21:59 <jordanP> floating IP
17:22:15 <mugsie> ok - can you record that in the bug as well?
17:22:25 <jordanP> doing it right now
17:22:31 <mugsie> thanks :)
17:22:50 <mugsie> ok - not sure ifthis is left over from last week -
17:22:54 <mugsie> #topic Server Pools - some questions clarifications (vinod)
17:23:04 <mugsie> was this dealt with?
17:23:21 <betsy> I can look at that bug if noone else is
17:23:32 <mugsie> betsy: I think jordanP is
17:23:42 <mugsie> jordanP: if you are, I can assign it to you
17:24:04 <betsy> jordanP: ping me if you have questions
17:24:10 <jordanP> I will have a try tomorrow, yes. If am failing to do anything, I will remove myself from the assigne
17:24:16 <mugsie> great!
17:24:45 <mugsie> vinod1: Server Pools - some questions clarifications <- Is this for this week as well?
17:25:07 <vinod1> oaky regarding the questions - we had some discussions last week - but wanted to wait for more people to show up - specifically mugsie :-)
17:25:30 * mugsie hides
17:25:33 <mugsie> :)
17:25:37 <vinod1> copying the 1st question from the agenda
17:25:38 <vinod1> currently we have status values of pending, active, deleted - should we have a value for error? How long can a change be in pending? Do we need to track pending_since?
17:26:02 <vinod1> rjrjr_: It appears that we now have an error status - correct?
17:26:07 <rjrjr_> correct.
17:26:26 <rjrjr_> by the way, i also need a DELETE_PENDING_ERROR if we add DELETE_PENDING.
17:26:47 <vinod1> So the remaining question that I have is how long would a change be in PENDING?
17:26:50 <mugsie> ok, in order - yes we should have errors (see ^), hum... thats a good question, and pending since can be tracked via the last_modified date + status
17:27:09 <mugsie> rjrjr_: DELETE_PENDING_ERROR makes sense
17:27:17 <mugsie> how long - I dont know
17:27:23 <vinod1> but if we have multiple changes to the zone - would that give us an accurate picture of pending_since?
17:27:33 <betsy> Probably needs to be configurable
17:27:42 <rjrjr_> i think we won't need this.
17:27:42 <mugsie> yes, as we really only care about the last change
17:28:03 <mugsie> rjrjr_: yeah - I think that might be an operator thing to keep track of
17:28:15 <rjrjr_> scope creep...
17:28:24 <mugsie> eg nova / neutron etc dont do anything with this stuff
17:28:28 <rjrjr_> can we address that kind of thing later.
17:28:28 <mugsie> rjrjr_: got it in one
17:28:51 <mugsie> I thik we leave them in the DB as is
17:29:17 <mugsie> we can revisit when we have an idea of what the issues are, and what would need to happen to domains in pending states
17:29:25 <mugsie> does that seem ok?
17:29:30 <vinod1> okay - can the user deleting pending recordsets/zones?
17:29:40 <vinod1> s/deleting/delete
17:29:55 <mugsie> deleted ?
17:29:56 <mugsie> no
17:30:02 <rjrjr_> domains won't remain in PENDING.  they will go to ACTIVE or ERROR pretty quickly depending on how many servers.
17:30:57 <rjrjr_> question is, can a user delete an ERROR record or zone?
17:31:04 <mugsie> I would say yes
17:31:23 <betsy> mugsie:+1
17:31:23 <mugsie> in theory that domain could be costing them money
17:31:45 <mugsie> so we allow deletion
17:32:14 <mugsie> any other clarifications needed?
17:32:50 <vinod1> no - everything is good and wonderful and rosy :-)
17:32:54 <mugsie> :)
17:33:24 <mugsie> #topic Server Pools Implementation Order (vinod)
17:33:39 <mugsie> was this part of last week, or did this require me as well?
17:33:41 <vinod1> #link https://wiki.openstack.org/wiki/Designate/SubTeams/Pools#Server_Pools_Implementation_Order
17:33:52 <rjrjr_> i thought the order was determined by the specs?
17:34:03 <rjrjr_> minidns support
17:34:09 <rjrjr_> server pool storage
17:34:15 <rjrjr_> followed by server pool manager
17:34:50 <vinod1> The primary motivation here was to see if we could work in parallel on the various tasks
17:34:54 <rjrjr_> and server pool REST API
17:35:52 <rjrjr_> each spec has sub categories (central, storage, etc.)
17:35:56 <mugsie> I think the order of the spec is ptretty much it
17:35:59 <mugsie> specs*
17:36:22 <mugsie> but, the manager & storage can happen in parallel
17:36:23 <rjrjr_> those can be done in parallel for the most part.
17:36:31 <mugsie> the majority of it canbe
17:36:35 <mugsie> can be*
17:36:48 <betsy> rjrjr_: Do you have the bandwidth to do both?
17:36:55 <rjrjr_> yes
17:37:04 <rjrjr_> but obviously not in paralle.
17:37:11 <mugsie> there  will be some hooking up work, but eg getting a swervice up and runnign, and talking to backends can happen independantly of storage
17:37:11 <rjrjr_> parallel.
17:37:49 <mugsie> rjrjr_: you can't type on 2 keyboards at the same time?
17:37:54 <mugsie> :D
17:38:00 <betsy> rjrjr_: I’ve got cycles at the moment. I could help with storage or the basic service
17:38:12 <rjrjr_> okay.
17:38:30 <rjrjr_> i know vinod and tim were also interested in helping, but i haven't heard from them.
17:38:36 <betsy> Do you want to ping me after the meeting and talk about it?
17:38:38 <rjrjr_> on what they were interested in.
17:38:43 <rjrjr_> yes.
17:38:48 <mugsie> ok - cool
17:38:59 <mugsie> #topic Open Discussion
17:39:01 <rjrjr_> so specs mostly done and we can move onto coding now?
17:39:07 <mugsie> i think so
17:39:22 <rjrjr_> do i commit to master?
17:39:26 <mugsie> but, we are in a RC phase, so any work people can do on open bugs would be great
17:39:27 <betsy> The API spec (mine) came late to the table and doesn’t have any comments yet
17:39:35 <rjrjr_> or do we have a branch for server pools?
17:39:37 <betsy> But that’s later down the road anyway
17:39:49 <mugsie> #action all - re-read all pools specs, and confirm
17:39:57 <mugsie> rjrjr_: no, we are on master
17:40:07 <rjrjr_> cool. 8^)
17:40:55 <mugsie> we do have 39 open bugs - so getting those down before we release juno would be good
17:41:13 <mugsie> I know we have been finding a few recently
17:41:18 <rjrjr_> okay.  do you want me to start server pool coding or work on bugs?
17:41:28 <vinod1> ok - i will starting looking at the other open bugs
17:41:41 <mugsie> as part of the openstack release cycle this time is supposed to be bugs
17:41:47 <rjrjr_> i have bandwidth and will do what the team needs.
17:41:58 <betsy> me, too
17:42:01 <mugsie> so I would personally like to get the bogs down as much as we can
17:42:05 <mugsie> bugs*
17:42:05 <rjrjr_> okay, bugs.  server pools in the background. 8^)
17:42:23 <mugsie> yeah - your fun side project ;)
17:42:32 <betsy> :D
17:42:36 <mugsie> anyone have any other itmes?
17:43:27 <betsy> I’m good
17:43:34 <rjrjr_> same here.
17:43:38 <mugsie> cool - thanks everyone!
17:43:42 <mugsie> #endmeeting