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