18:00:39 #startmeeting DNSaaS 18:00:41 Meeting started Wed Nov 28 18:00:39 2012 UTC. The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:44 The meeting name has been set to 'dnsaas' 18:01:02 Hiya 18:01:06 Everyone here? 18:01:39 #link http://wiki.openstack.org/Meetings/DNSaaS 18:01:50 * CaptTofu is prsent 18:02:00 #topic Current Status 18:02:26 Okay - Lets get going.. I think we're a few people short, but we'll go on without them :) 18:03:14 So - We skipped the last official meeting, and instead had a impromptu meeting in #openstack-dns instead.. 18:03:37 What came from that (since there are no logs, and not everyone was there) was: 18:04:08 1) Hold off any plans for incubation until the TC and Board come to a decision over the recent incubation discussions 18:04:51 2) There was some discussion of switching out Flask for X.. The decision was to hold off, and only consider a switch to something if it lands in openstack-common / oslo 18:05:31 3) The agent service should be made optional to provide a better fit for DNS servers like PowerDNS+MySQL, where an agent is not required on the server itself 18:06:09 That was about the bones of it, if my memory serves my right 18:06:15 yes 18:06:29 #3 - what does that mean exactly? 18:06:41 #3 being of interest to me since getting mysqlbind agent working 18:06:54 So - We have various Backend implementations - bind9, powerdns, bind9mysql etc 18:06:57 it seems like we have that currently, really? 18:07:14 Those classes should be loadable into either the moniker-agent service, OR the moniker-central service 18:07:42 and a new "RPC" backend would be written that is loaded into moniker-central for those using the moniker-agent service 18:07:49 what does that mean for moniker-central? That moniker-central does some of the work for a given backen? 18:07:58 There should be no code changes needed in the agents to make it work.. 18:08:07 right. 18:08:13 So - Say your using PowerDNS+MySQL 18:08:44 moniker-agent, as written today, does nothing more than talk to MySQL.. And only a single copy is needed for the entire pool of DNS servers (since they all read the MySQL DB) 18:09:19 The end result is added complexity of an extra RPC stage and extra service 18:09:23 ah, via replication 18:09:58 We can instead load that backend straight into moniker-central 18:10:29 and since the, for example, PowerDNS DB calls are relatively quick anyway, we don't really loose anything 18:10:51 you mean moniker central calls something int he service itself? 18:11:14 so for instance, I have my one single table for mysqlbind - how do those changes to that table get made? 18:11:40 and I suppose powerdns the same thing - though not sure if you go to the db or through an API for powerdns 18:11:45 For bind9+mysql, you would need to continue to use the agent service. 18:11:57 Since it still requires files on disk for the zone's to be loaded 18:12:23 But - The DB interaction could be done from moniker-central just once, and then the moniker-agents could just write the file out 18:12:25 just one 18:12:45 ok 18:12:49 I think I see what you mean 18:12:58 this would be a plugin to moniker-central 18:13:08 Right.. The same plugins as the agent loads.. 18:13:26 ok, that makes complete sense 18:13:54 So .. I plan of getting that done this week, unless someone beats me to it. 18:14:05 yes, in all essense, the single zone file could be done outside of moniker based off of data in that table 18:14:18 (well... before next week, since I'll likely only get time over the weekend) 18:14:28 what do you envision doing, the hooks for that plugin? 18:14:49 the changes to moniker-central to allow for that, I mean? 18:15:00 It's bascially 2 parts.. 18:15:00 1) Writing a backend that proxies messages to the RPC queue 18:15:08 or would it make sense to take something, like I have, and do it? 18:15:22 2) Updating moniker central to, instead of calling RPC directly, load and call into a backend plugin 18:15:50 So - If central loads the RPC plugin, and the agent loads the bind9 plugin, we get something that's identical functionality wise to what we have today 18:16:02 so, two options you mean? 18:16:26 Not quite - Both would be implemented 18:16:29 ah 18:16:35 #1 is the RPC plugin mentioned in #2 18:17:42 Anyone have comments on the proposal? (andrewbogott Ryan_Lane zykes- I know your hiding there quietly ;)) 18:17:49 ok, so central loads RPC plugin (vs. something like a mysqlbind plugin) which means an agent has to be listening vs. something that requires no RPC which means agent doesn' thave to be listening? 18:17:56 :p 18:18:01 not really Kiall 18:18:03 CaptTofu, yea exactly 18:18:14 no comments 18:18:21 in other words, RPC means there is some work outside of central that has to be done 18:18:27 something nitty gritty like writing files? 18:18:36 CaptTofu, yea, like writing a zone file to disk 18:18:38 Kiall: wasn't the idea to make it possible to just load a backend instead of rpc ? 18:18:40 Yeah, it seems fine -- as long as I can ignore the agent when handling pdns I'm happy :) 18:18:45 zykes-, exactly :) 18:18:50 RPC would be just another "backend" 18:18:59 but things like DB, that means we use the database connection we have 18:19:34 how does one talk to powerdns? Directory to MySQL or through an API? 18:19:42 Right .. So for the DB, JC has taken the bug dealing with connections to multiple databases 18:19:44 #link https://bugs.launchpad.net/moniker/+bug/1074093 18:19:45 s/Directory/directly/ 18:19:46 Launchpad bug 1074093 in moniker "Support multiple database connections in the SQLAlchemy storage implementation" [Medium,New] 18:20:06 I had an email from him about an hour or so ago, and I think he's basically ready to propose a fix 18:20:23 CaptTofu, via MySQL 18:20:30 nice, that is something I'd like to see to learn more about SQLAlchemy 18:20:49 it's been a learning curve, and just because my mind is set in its ways 18:20:58 Okay.. Next up 18:21:05 #topic CLI and Python API 18:21:20 I'm 90% happy with the PythonAPI in review #17045 18:21:32 But am not so happy with my CLI attempt.. 18:22:09 And .. zykes- + andrewbogott have another implementation 18:22:26 Um, no, I think zykes- is working with your implementation 18:22:42 You do have code up there :) 18:22:47 There are bits from all 3 I like... 18:23:17 But for right this minute, I wanting something so simple your grandmother could hack away at the code ;) 18:23:42 I'd love some feedback on both of the current reviews.. 18:23:49 #link https://review.openstack.org/#/c/17045/ 18:23:51 #link https://review.openstack.org/#/c/17041/ 18:23:58 (One is mine.. One is zykes- ..) 18:24:17 Please have a read leave some comments if you have 10 mins to spare 18:24:23 or be able to get it to run ? :) 18:24:46 Do either of those use osc or are they both plain old cliff? 18:25:00 Use the checkout link gerrit gives you, and re-run `python setup.py develop` and both should work 18:26:11 andrewbogott, no, I had been scared away from osc for 2 reasons.. 1) It doesnt seem to actually be used by any of the projects.. and 2) it's seems to have 1 real committer 18:26:58 I'd love if all the projects standardised... But I'm not sure things are actually heading to osc anytime soon, and I don't want to depend on something that may change at a moments notice :) 18:27:40 Either way - both osc and our implementations use cliff, porting from one to another should be fairly trivial 18:28:07 For reference in the logs.. 18:28:09 #link https://github.com/openstack/python-openstackclient/ 18:28:55 Anyone have anything else on the PythonAPI or CLI? 18:29:27 Is there an index of minutes from previous meetings someplace? 18:29:40 Yea - http://eavesdrop.openstack.org/meetings/dnsaas/2012/ 18:30:03 Okay.. last topic from the agenda so.. 18:30:12 #topic Call for testing and bug reports! 18:30:31 I'm *dying* to stop adding features and cut a "stable" release :) 18:31:11 I think we're really close, but I would love some feedback on what issues people are seeing (or not seeing!) 18:32:18 I'm usually around #openstack-dns during UTC working hours, and often on/off at some point during the UTC eventing.. Feel free to nab me if you have any Q's on getting everything up and running 18:33:11 Okay.. That's all I had planned to discuss today.. Does anyone else have anything to bring up? 18:33:12 #topic Open discussion 18:33:21 thanks! 18:33:52 Nobody? 18:34:07 not much 18:34:12 watching aws reinwent ;p 18:34:22 Kiall, can I make a request about process? 18:34:28 andrewbogott, of course 18:35:29 I am frustrated… because I've followed plans that were made during these meetings 18:35:46 but informal discussion and decisions-internal-to-Kiall were made in the meantime causing lots of my work to be discarded. 18:36:00 Would it be possible to actually talk about these things during meetings before such directional/delegation changes are made? 18:36:13 I don't especially disagree with any of the conclusions, I just wish I hadn't duplicated all the effort in the meantime. 18:37:30 First off.. I apologize, you're absolutely correct. There has been some (lots) of duplication of effort over the CLI etc, that shouldn't have happened 18:37:41 Partly, I feel like DNS in Openstack has this traditional problem -- everyone writes code before discussion... 18:37:54 We were trying to centralize into one project but we're still writing concurrent implementations :) 18:38:21 andrewbogott: the worst thing has been the cli 18:38:28 don't know of others though 18:38:40 Heh, yea.. we are. Though, this is one of the main reasons I've been wanting to cut a "stable" release 18:38:54 Lemme see if I can phrase this constructively :) 18:39:41 Once we have something that's actually usable - then we (I) can't make sweeping changes etc.. I think from that point on, the use of blueprints for anything major should be required 18:39:45 I think it's awesome that Kiall is devoting so much time and leadership to this! I think a part of that leadership role, though, means catching up on email and code reviews before writing new code like mad. Does that make sense? 18:40:42 (And, agreed, as the project matures there will be more obvious processes for new tasks.) 18:41:03 It absolutely does - And I'll do my best :) 18:41:26 cool, thanks. Again, I really do appreciate your work and love how quickly this is all coming together. 18:42:46 Okay.. So thanks all! (And sorry andrewbogott ;) ). Please email/IRC me with anything for next week.. 18:43:17 yep! thanks all 18:43:26 #endmeeting