17:01:49 <mugsie> #startmeeting designate
17:01:49 <openstack> Meeting started Wed Oct 23 17:01:49 2013 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:52 <openstack> The meeting name has been set to 'designate'
17:02:01 <kiall> Heya
17:02:17 <tsimmons> hi
17:02:22 <mugsie> hey
17:02:25 <vinod1> hi
17:02:29 <kiall> I've not had a chance to fully catchup on last week meeting, so I've asked mugsie to run this again
17:02:31 <betsy> here
17:02:38 <mugsie> we missing anyone?
17:02:59 <vinod1> artom?
17:03:10 <mugsie> #topic Review action items from last week
17:03:22 <kiall> (We've been travelling since last friday btw)
17:03:27 <msisk> here, too.
17:04:00 <mugsie> Search out any logging guidelines from other OpenStack projects (vinodmr)
17:04:06 <betsy> Yeah? Any place exciting?
17:04:15 <mugsie> northern ireland
17:04:29 <vinod1> I haven't been able to get to it.  Will get it to it after about 2 weeks
17:04:37 <mugsie> some of our team live up there, so we decided to visit
17:04:41 <mugsie> vinod1: cool
17:04:54 <eankutse> eankutse
17:05:01 <mugsie> #action Search out any logging guidelines from other OpenStack projects (vinodmr) - 2 weeks
17:05:02 * CaptTofu is here
17:05:17 <mugsie> Review HP's DEBUG level logs, increase anything generally useful to INFO or above (kiall)
17:05:50 <kiall> Not had a chance with travelling+visitors :(
17:06:00 <mugsie> #action Review HP's DEBUG level logs, increase anything generally useful to INFO or above (kiall)
17:06:08 <mugsie> Update APIv2 Spec with proposed RRset/Record changes (kiall)
17:06:10 <kiall> I've given a quick look over during our last log review, but nothing stood out
17:06:13 <CaptTofu> all my fault :)
17:06:16 <kiall> Same as above I'm afraid :(
17:06:22 <mugsie> #action Update APIv2 Spec with proposed RRset/Record changes (kiall)
17:06:30 <mugsie> MySQL BIND9 Docs (CaptTofu)
17:06:47 <CaptTofu> need to update those been busy with travel.
17:06:54 <mugsie> #action MySQL BIND9 Docs (CaptTofu)
17:07:15 <mugsie> ok, so most (all?) of those have been pushed to future meetings
17:07:33 <mugsie> and finally
17:07:34 <mugsie> Update domain-import-export blueprint with pro's and con's of content types (artom)
17:08:15 <kiall> Apologies - The whole HP DNS team has been travelling + meeting up for face to face time, so we've had little "real work" done over the last week!
17:08:20 <mugsie> did people  have a chance to look that over?
17:08:40 <mugsie> or shall I push that on?
17:09:11 <eankutse> Did not see updates to blueprint
17:09:16 <tsimmons> I haven't looked.
17:09:19 <mugsie> #link https://blueprints.launchpad.net/designate/+spec/domain-import-export
17:09:23 <kiall> Yea, I'm personally in favor of using accept/content-type headers with /zones and /zones/{id}
17:09:36 <kiall> rather than /zonefile/import and /zonefile/export..
17:10:12 <mugsie> eankutse: there was some editing in the whiteboard area, but not a major list
17:10:28 <eankutse> k. I see it
17:10:45 <mugsie> if people havent had a chance, i think we should push it on
17:11:13 <vinod1> #agreed
17:11:20 <mugsie> #action Update domain-import-export blueprint with pro's and con's of content types (artom)
17:11:23 <betsy> #agreed
17:11:32 <mugsie> #topic Open Disscussion
17:11:59 <mugsie> artom: have any update on your change?
17:12:08 <eankutse> I added a couple of questions to https://wiki.openstack.org/wiki/Designate/Server_Pools
17:12:30 <mugsie> most people have not had a chance to read the blueprint, so currently it is set to come up next week
17:12:44 <mugsie> eankutse: cool, I havent seen them yet, so will look this week
17:12:52 <eankutse> ok
17:13:00 <mugsie> #action Review Server Pools questions (mugsie)
17:13:44 <eankutse> I just added them about an hour ago
17:14:01 <mugsie> ah, thats why I missed them then :)
17:14:22 <eankutse> :-)
17:14:38 <mugsie> anything else?
17:14:51 <eankutse> maybe we can take just one of the questions
17:14:58 <eankutse> I'ii post it here
17:14:59 <mugsie> yeah
17:15:08 <eankutse> In Phase2 & 3, Async Response (202 Accepted), the current planned implementation has a "Status" field added to the Domains and Records tables in Central that is updated based on the response from the backend. How do we go about returning details of Errors if operation failed for some reason?
17:15:27 <mugsie> #link https://wiki.openstack.org/wiki/Designate/Server_Pools#Questions
17:15:56 <mugsie> eankutse: the plan is to work like nova
17:16:15 <mugsie> a GET /zone/record ... will show status = ERROR
17:16:53 <mugsie> or ERROR-Schedualign / deleting etc
17:16:58 <eankutse> how about details of the error?
17:17:02 <betsy> Are details in the body?
17:17:22 <kiall> eankutse: generally, if we accept the request, it should suceed
17:17:42 <kiall> any errors are likely to be things that only the operator can fix
17:18:01 <eankutse> but they need a hint on what caused the failure
17:18:04 <eankutse> so
17:18:04 <betsy> Right, so they would need to know details so they could know how to fix them
17:18:14 <kiall> So, we could provide the user with lots of detail .. but it's beyond their control to fix..
17:18:36 <eankutse> ok.
17:18:47 <artom> Surely the more information, the better?
17:19:01 <artom> Without necessarily giving them stacktraces and such.
17:19:04 <eankutse> So you mean that user errors (including validation errors) will have been caught before now?
17:19:10 <mugsie> eankutse: yes
17:19:12 <kiall> Ideally, all user-caused and user-fixable errors should be caught before accepting the request at all
17:19:31 <betsy> I didn't think that was true with saync calls
17:19:40 <kiall> For example - Would you want nova to say "error scheduling vm - no capacity available" to end users? I'm guessing no :)
17:19:40 <betsy> *async
17:19:44 <kiall> It's also something an end user can't fix
17:20:03 <mugsie> betsy: it is, we do all the checks to ensure it can be created before we put it in the queue to be created
17:20:13 <mugsie> / updated / deleted /etc
17:20:36 <mugsie> this just fits where the backend currently sits, after all the checks have been done
17:21:19 <vinod1> What action can the user take after an error?  The normal behavior on an error - especially one that you do not understand is to retry
17:21:51 <betsy> Not if it's something like invalid domain name
17:22:03 <vinod1> So at least the error message should indicate what action the user can take - report the error to admins and wait for problem to be resolved?
17:22:07 <mugsie> betsy: which would have returned a 400 error to the user
17:22:13 <kiall> vinod1: correct, the user should retry. If a zone/record/etc makes it into an "ERROR" state, something has gone wrong that is outside of the users control.
17:22:43 <betsy> But a 400 with detail -- invalid domain name
17:22:43 <mugsie> vinod1: if you look at how nova reprts issues with cvreating instances, it only give a very basic indication of what happened
17:22:48 <mugsie> betsy: yes
17:23:10 <kiall> betsy: yea, the 400 with details happens before the request is accepted and placed into the async queue
17:23:25 <vinod1> In those kind of errors when you get into an error state - would a retry help?
17:23:32 <mugsie> it could
17:23:50 <mugsie> say if the backend had a failuer, and the quiry expired
17:23:57 <mugsie> and then had to be retried
17:24:10 <kiall> vinod1: that depends on the issue, say the async action is finally being run, and the database server is down.. It's going to fail and the zone will end up in an ERROR state.
17:24:35 <kiall> Retrying, as an end user, makes sense here.. there waiting for your failover and/or staff to fix the DB (or whatever else is broken)
17:25:06 <kiall> If the user provides bad input, that request will be rejected with a 400 containing some details, and will never make it into the queue at all
17:26:20 <mugsie> eankutse: does that answer the question?
17:27:13 <eankutse> hmmm…yes
17:27:30 <mugsie> anything else, just chuck it into that question section
17:27:41 <eankutse> Next one...
17:27:42 <eankutse> In Phase2 & 3, Async Response (202 Accepted), we should consider returning Location Header that points to the URL of the resource (that is being created). The user can check the status of the operation using this
17:28:24 <mugsie> eankutse: yeap, it should
17:28:36 <mugsie> i thought I documented it to say it did
17:28:41 <mugsie> but it seems i didnt
17:28:56 <eankutse> maybe I missed it.
17:29:06 <mugsie> no, just checked, I never actually wrote it
17:29:10 <mugsie> (sorry)
17:29:17 <eankutse> I know we mentioned that the use will hvae to call GET /domain.id
17:29:32 <mugsie> yeah
17:30:17 <eankutse> k. One more that is just remotely related...
17:30:24 <eankutse> Not directly related to achieving Async but should we consider following recommendations from http://docs.openstack.org/api/openstack-compute/2/content/LinksReferences.html and add "self" and "bookmark" links in the final response body after the resource is available?
17:30:42 <mugsie> i think we have that in the API v2 spec
17:30:52 <eankutse> k. Cool :-)
17:31:01 <mugsie> thaty all responces will have a links section with rel=self etc
17:31:06 <mugsie> cool
17:31:10 <mugsie> anything else from anyone?
17:31:59 <mugsie> going once
17:31:59 <eankutse> not for me
17:32:03 <vinod1> none from me
17:32:07 <betsy> I'm good
17:32:08 <tsimmons> I'm good.
17:32:36 <kiall> Not from me :)
17:32:39 <mugsie> cool, thanks everyone
17:32:50 <eankutse> bye
17:32:58 <artom> Wait, was that the call for open discussion?
17:32:58 <mugsie> if you think of anything during the week just dump it on the agenda!
17:33:05 <mugsie> yup :)
17:33:07 <artom> Doh.
17:33:11 <mugsie> have something?
17:33:22 <artom> Two semi-related things.
17:33:33 <mugsie> cool, go for it
17:33:42 <artom> Does https://blueprints.launchpad.net/designate/+spec/multi-backend depend on pools? Or can it be started in parallel?
17:34:08 <mugsie> yup
17:34:50 <kiall> multi-backend was more about writing changes to 2 backends at once
17:35:02 <artom> You answered 'yup' to an 'or' question - while logically that's sound, I need to know what half of the 'or' you're agreeing with ;)
17:35:22 <kiall> At HP, we write certain changes (create/delete zone) to multiple places..
17:35:55 <mugsie> artom: as it turns out i was wrong - yes, it can be started with out pools
17:35:57 <kiall> The idea was for to take the code we have there, and make it generic enough to write changes to any 2 backends at once
17:36:37 <eankutse> using one scheduler?
17:36:54 <mugsie> this is independant of schedualers
17:37:03 <mugsie> this is the same records being writen]
17:37:09 <mugsie> to btoth backends
17:37:14 <mugsie> both*
17:37:19 <eankutse> k
17:37:24 <kiall> eankutse: when a zone is created on HP Cloud, we create it in PowerDNS as usual, but ALSO need to create it at one of our partners
17:37:52 <eankutse> ok
17:38:02 <tsimmons> So essentially sending a duplicate message to two different places?
17:38:15 <mugsie> tsimmons: yes
17:38:39 <artom> I might pick up that bp, pending discussions around here. But good to know it can happen before pools.
17:38:53 <mugsie> artom: cool.
17:39:24 <mugsie> you had a second thing artom?
17:39:34 <artom> Second thing: a NSD-slave backend that depends on 1. multiple backends and 2. a PowerDNS backend
17:40:24 <artom> The idea would be that the NSD-slave backend would only send remote control commands to a NSD server that would then AXFR from the PowerDNS server.
17:40:53 <artom> So it would be a mutant backend that doesn't actually store anything, and depends on another backend.
17:40:58 <artom> Would that be acceptable?
17:41:07 <mugsie> yeah, log a blueprint for it
17:41:40 <artom> Ah, right, so discussion can take place there.
17:42:00 <kiall> Yea - I think that needs some thought :)
17:42:05 <mugsie> well, just so the detaisl can be knocked out beter#
17:42:15 <mugsie> details
17:42:24 <mugsie> can't type today :(
17:42:38 <mugsie> but in general, sounds grand
17:43:09 <artom> Sure, grand :)
17:43:19 <mugsie> we good to finish up everyone?
17:43:52 * artom is good.
17:44:18 <mugsie> thanks everyone!
17:44:21 <eankutse> thx
17:44:21 <mugsie> #endmeeting