18:00:47 <Kiall> #startmeeting DNSaaS
18:00:47 <openstack> Meeting started Wed Nov 14 18:00:47 2012 UTC.  The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:49 <openstack> The meeting name has been set to 'dnsaas'
18:00:57 <Kiall> #link http://wiki.openstack.org/Meetings/DNSaaS
18:01:00 <Kiall> Agenda ^
18:01:06 <Kiall> Everyone here?
18:01:48 <Kiall> I'll take that as a yes!
18:01:59 <Kiall> #topic Current Status
18:02:38 <Kiall> First off - I have to apologize for getting (virtually) nothing done since our last meeting. I've been up to my eyes with other work.
18:03:01 <CaptTofu> you have helped a lot actually
18:03:08 <CaptTofu> plus have assisted me quite a bit
18:03:10 <Kiall> The main piece that landed was the bind backend moving to a driver based system
18:03:28 <CaptTofu> it's a very clean change
18:03:32 <jcmartin> We don't need to be too aggressive either, and we should do the right things
18:03:37 <Kiall> #link https://review.openstack.org/#/c/15671/
18:03:41 <Kiall> jcmartin, agreed
18:03:49 <CaptTofu> agreed here too
18:03:50 <jcmartin> posted my blurb
18:03:54 <jcmartin> #link http://wiki.openstack.org/Moniker/Deployment
18:04:16 <Kiall> jcmartin, Great
18:04:28 <CaptTofu> I myself have made progress with mysqlbind
18:04:42 <CaptTofu> and modified mysqlbind in the process to have one singe table vs. one per zone
18:04:42 <Kiall> jcmartin, want to bring us through it?
18:05:27 <jcmartin> I think that based on the deployment doc, and before to implement too much, we need to talk about the backend/plugin model
18:05:54 <Kiall> jcmartin, sure..
18:06:31 <jcmartin> do you want to do that through mailing list ?
18:07:22 <Kiall> jcmartin, sure, will you get that thread going with your thoughts? You're probably in the best position to get that ball rolling
18:07:34 <jcmartin> I will.
18:08:08 <Kiall> #action jcmartin to start ML thread on deployment models and implications for backend implementations
18:08:42 <jcmartin> I have an update on incubation too
18:08:48 <Kiall> #topic incubation
18:08:50 <Kiall> Great :)
18:08:58 <jcmartin> the TC is revisiting the model
18:09:24 <jcmartin> The plan is to separate the definition of core for trademarks purpose, managed by foundation board
18:09:31 <Kiall> Yea - I've been following that ML thread .. But I've not seen any clear "winning" opinion yet
18:09:38 <jcmartin> from the definition of openstack services, managed by TC
18:10:15 <jcmartin> the TC would like to move the gate to be up before too much investment is made to accept a project as incubated
18:10:34 <jcmartin> I don't know what is the timeline for this decision (next TC/Board)
18:10:44 <Kiall> Do the TC or PPB have a timeline for a meeting on the topic?
18:10:48 <Kiall> heh - beat me to it
18:11:15 <jcmartin> It seems that anyway for moniker, the 'best' route is incubation
18:11:21 <jcmartin> what do you think ?
18:11:34 <jcmartin> the alternative was piggy backing on Quantum
18:11:48 <jcmartin> but I don't see the affinity too much
18:11:49 <Kiall> Right - I've personally never seen how the piggyback on Quantum would work
18:12:21 <jcmartin> it was going to be more of an administrative issue than technical anyway
18:12:29 <Kiall> Okay - So are we in a position to request incubation, or should we wait for the TC and PPB's decisions first?
18:12:56 <Kiall> (My feeling is we should wait)
18:13:23 <jcmartin> Let me find out from someone at the TC what their recommendation is, but I guess that before to go to the incubation review, we neet a bit more 'aging'
18:13:28 <Kiall> I don't think there is any reason to rush the application, anytime before H opens should be good?
18:13:43 <jcmartin> I agree, no rush
18:14:14 <Kiall> Great :) So we can push all that aside for the moment and get on with other things :)
18:14:21 <jcmartin> we should do a bit more formalization. One of them is blueprint type of spec
18:14:55 <jcmartin> But code should not wait
18:15:40 <Kiall> Yea - I think moniker is getting to the point of being stable enough that BPs make sense for big changes (It's still buggy - but architecturally should be pretty complete)
18:16:07 <jcmartin> minus the plugin model ;-)
18:16:17 <CaptTofu> we did a demo with it yesterday
18:16:20 <Kiall> I said "pretty complete" didn't I? :)
18:16:38 <CaptTofu> plugin model - regards to openstack as a whole?
18:16:49 <Kiall> Any more thoughts on incubation and stability before we move on?
18:17:00 <jcmartin> done on my side
18:17:13 <jcmartin> will keep an eye on progress
18:17:17 <Kiall> CaptTofu, the way backends work now is a little up for discussion. jcmartin is going to start a thread on the ML
18:17:25 <Kiall> to discuss the specifcs
18:17:29 <Kiall> specifics*
18:17:31 <CaptTofu> right, I saw that
18:17:32 <Kiall> #topic Grizzly-1 Milestone Targets
18:17:43 <CaptTofu> but I thought by "plugins" that it was another issue
18:18:10 <Kiall> So - I would like to try and get some features "complete" before G1
18:18:31 <Kiall> 1) Final versions of notification handlers (zykes- had a go at these yesterday I believe)
18:18:44 <Kiall> 2) Wire up the keystone and policy code I've got in place
18:18:55 <Kiall> 3) a working Python API and CLI
18:19:14 <CaptTofu> and I have an action item on 3
18:19:23 <andrewbogott> When is G1?
18:19:31 <Kiall> Does anything think we need to try and get more (or less) than that done?
18:19:52 <jcmartin> we should focus on finishing up the notification part
18:19:53 <Kiall> andrewbogott, soon! just over a week
18:20:39 <Kiall> I think it's doable. The notifications are an hour or so, the python API and CLI should be a few hours, and the keystone+policy stuff a few hours
18:21:04 <jcmartin> do you need keystone+policy for notifications ?
18:21:17 <Kiall> (I'm not suggesting perfect, bug free by then. Simply "works in best case scenario" level)
18:21:40 <Kiall> No, Not for the stock handlers we agreed on last week anyway.
18:22:12 <jcmartin> seems a good plan
18:22:22 <Kiall> andrewbogott, I know I'm holding you up on the Python API+CLI. I'll unblock you tonight.
18:22:38 <CaptTofu> I'd like to help on that.
18:23:05 <andrewbogott> Kiall, did my question about 'with warlock' vs 'like warlock' make sense?  Will all that be obvious once you write your demo code?
18:23:21 <Kiall> andrewbogott, what's your bandwidth like over the next week? Am I asking too much?
18:23:40 <Kiall> Oh - Sorry - I forgot to respond to that Q earlier :)
18:23:44 <andrewbogott> I should be free to work on this, barring emergencies.
18:23:45 <Kiall> Probably with
18:24:02 <andrewbogott> ok, that's what I was thinking as well.
18:24:04 <CaptTofu> same here
18:24:12 <CaptTofu> I could use it hence I would be glad to help on it
18:24:27 <Kiall> Probably with warlock - it works.. and allows us to reuse the server side schemas to handle the basic object model+validation needed in the pythonAPI + client
18:25:00 <CaptTofu> Kiall: is there another client API that uses for gleaning at?
18:25:08 <CaptTofu> client-cli, ...
18:25:16 <Kiall> So - Does anyone think that, bar those 3 features, we stop adding features and concentrate on stability+tests?
18:25:24 <CaptTofu> yes.
18:25:39 <jcmartin> kiall for G or for G1 ?
18:25:51 <Kiall> CaptTofu, yes - although I can't remember which project that was! I'll look for it later
18:25:55 <CaptTofu> I do have my HP mysqlbind tasks, but my time is full time on this.
18:26:13 <Kiall> jcmartin, well for G1, and if we get to a well-tested+doc'd point, add more for G
18:26:22 <jcmartin> ok
18:26:41 <zykes-> here
18:26:51 <zykes-> sorry for being out but I needed to go get something urgently
18:27:01 <Kiall> I'd really like to get something stable that people can actually use, I think that will help find the current weaknesses :)
18:27:39 <Kiall> zykes-, no hassle. Did you make any progress on notification handlers yesterday? (Even after all the confusion I added! Sorry about that ;))
18:27:57 <zykes-> a bit
18:28:11 <zykes-> though i still have post marriage traumatic stress
18:28:16 <zykes-> :p
18:28:19 <Kiall> Anything holding you up that need fixing?
18:28:22 <Kiall> That can be fixed ;)
18:29:28 <Kiall> Okay - Guess not :) Last specific topic so!
18:29:43 <Kiall> (Also - Tell me to slow down if I'm moving too fast for anyone)
18:29:52 <Kiall> #topic API - Flask vs OpenStack Common's implementation
18:30:00 <Kiall> jcmartin suggested this topic for last week's agenda, but we just didn't have time!
18:30:19 <CaptTofu> is this a vote situation?
18:30:30 <Kiall> Discussion to start with!
18:30:32 <zykes-> isn't dhellmann working on Pecan as well ?
18:30:37 <zykes-> just as a suggestion
18:30:38 <zykes-> :p
18:30:49 <jcmartin> Is there a precedent of using flask in openstack ? all the projects seem to be using wsgi directly
18:31:10 <Kiall> jcmartin, yes/no - ceilometer does
18:31:16 <Kiall> but it's still in incubation
18:31:26 <jcmartin> I am in favor to align with what other projects are doing, but it doesn't seem that there is a huge unity anyway
18:31:35 <zykes-> Kiall: aren't they re-tooling Kiall ?
18:31:41 <zykes-> ehm, retooling to pecan
18:31:43 <CaptTofu> I have yet to see a clear means of how to do a skeletal project and have REST/wsgi set up easily
18:32:04 <Kiall> jcmartin, right. That was one of my reasons for using Flask. There was no (clean) os-common way
18:32:25 <Kiall> I understand the os-common/oslo folks are working on that though
18:32:42 <jcmartin> the main functional requirement is the support of xtensions in the 'openstack way'
18:33:20 <CaptTofu> is it all icing on the cake?
18:33:32 <CaptTofu> or are there major differences?
18:33:38 <Kiall> I'm going to be honest, I've barely ever looked at the 'openstack way' to handle extensions :)
18:33:47 <zykes-> :o
18:33:54 <CaptTofu> I tried to
18:33:56 <Kiall> I've got some Flask based API's where extensions are supported
18:34:02 <jcmartin> kiall: it's not the most intuitive way, but it works
18:34:12 <CaptTofu> but couldn't figure out how you'd go about writing something from skeletal up
18:34:34 <jcmartin> I did a skeleton based on quantum+common
18:34:41 <CaptTofu> that'd be good to see
18:34:51 <CaptTofu> my main problem is being new to this
18:34:57 <Kiall> jcmartin, I guess we need to figure out if we can implement something for flask quicker, and cleaner, than switching to the OS-Common implementation.
18:35:10 <jcmartin> I don't have a lot of bandwidth, but I can try a prototype on Moniker the "quantum way"
18:35:20 <jcmartin> this would be a best effort for now
18:35:25 <Kiall> Also - I would be concerned that the OS-Common WSGI stuff is not stable yet, and is still changing
18:35:40 <jcmartin> kiall: true
18:35:52 <Kiall> jcmartin, I'd actually like to see that - and would give us a great comparison to really understand the differences
18:36:25 <Kiall> Our API is tiny - so I would imaging most of the work would be getting the boilerplate going?
18:36:27 <jcmartin> Ok, i'll try but again, best effort ;-)
18:36:40 <Kiall> sure - won't hold you to it :)
18:36:48 <jcmartin> yes, that's the problem :reverse engineering the other stuff
18:37:18 <jcmartin> although it seems like pecan is nice too ...
18:37:27 <Kiall> jcmartin, exactly :) That scared me right off initially.. I had the initial API written and working in 20 mins when I started Moniker ;)
18:37:40 <zykes-> jcmartin: i think it got voted to be the "DEFAULT" in the session at the summit that was
18:37:42 <Kiall> #link http://pecanpy.org/
18:38:14 <Kiall> zykes-, interesting. Was there a etherpad at that topic?
18:38:19 <jcmartin> zykes-: for ceilo or in common ?
18:39:03 <zykes-> Kiall: let me see...
18:40:15 <zykes-> https://etherpad.openstack.org/grizzly-common-wsgi-frameworks
18:40:21 <Kiall> #link https://etherpad.openstack.org/grizzly-common-wsgi-frameworks
18:40:38 <zykes-> out of those I think they picked Pecan
18:40:46 <zykes-> to be the best candidate
18:40:52 <Kiall> 250 lines is probably too long to read during a meeting
18:41:14 <Kiall> jcmartin, I'm going to do some digging - and will get in touch with the oslo guys for next week.
18:41:25 <zykes-> check with dhellmann also Kiall
18:41:29 <Kiall> I'd like to see what they have planned
18:42:09 <Kiall> zykes-, will do.
18:42:27 <zykes-> http://pastebin.com/Rje9V6Xg < is what I have for handlers atm
18:42:36 <CaptTofu> what are the implications for pecan, stock os common, and flask?
18:42:53 <Kiall> So - jcmartin - Will we keep the API stuff on the agenda for next week, or is that too soon for you to have a stab at the os-common example?
18:43:42 <jcmartin> let's wait to see what zykes- say. I think we need to decide at the next meeting if we go pecan or swgi/quantum
18:44:09 <zykes-> i think we should check with oslo / ceilometer dudes
18:44:13 <Kiall> CaptTofu, Well. os-common/oslo WSGI is staying around for a good while. So there's no harm in looking into it.. And if Pecan is the "new default", then it looks similar enough to flask that I would have no issue switching (Don't hold me to that)
18:44:18 <zykes-> since ceilometer folks are stuck in the same situation
18:44:18 <jcmartin> but it will be too soon for the example, since it impacts also the plugin model
18:44:30 <Kiall> zykes-, right. I'll ping markmc tomorrow re olso's WSGI
18:44:45 <CaptTofu> Kiall: that sounds good
18:44:59 <jcmartin> and next week is almost off in the US
18:45:05 <CaptTofu> oh, yeah
18:45:08 <CaptTofu> forgot about that
18:45:09 <CaptTofu> yay
18:45:14 <Kiall> jcmartin, okay - no problem. Just let me know when you want to pick it back up
18:45:27 <jcmartin> let's sync up next week
18:45:27 <Kiall> and I'll stick it on the agenda for the next meet after that
18:45:43 <jcmartin> we can have zykes- report next week
18:45:57 <Kiall> #action kiall to contact olso folks re upcoming wsgi changes in oslo
18:46:09 <jcmartin> or kiall then ;-)
18:46:20 <Kiall> Oh - I didn't notice zykes- offering :)
18:46:31 <zykes-> jcmartin: what should I report ? :p
18:46:46 <Kiall> I think jcmartin mixed us up ;)
18:47:05 <zykes-> :o
18:47:05 <jcmartin> i though you voluntered but you said "we shoudl check" sorry ;-)
18:47:09 <zykes-> ;P
18:47:40 <Kiall> So - Any more thoughts on the API/WSGI implementation? We'll regroup on it next week after I've figured out oslo's plans and spoken to dhellmann
18:47:57 <Kiall> #action kiall to contact dhellmann re https://etherpad.openstack.org/grizzly-common-wsgi-frameworks and Pecan
18:48:20 <Kiall> #topic Open Discussion
18:48:52 <Kiall> Last thing on the agenda - Does anyone have anything else to add?
18:49:03 <Kiall> Anything we haven't discussed?
18:49:07 <jcmartin> what backends do you guys are using ? bind ?
18:49:13 <CaptTofu> mysqlbind here
18:49:30 <jcmartin> how do you handle zone creation ?
18:49:33 <CaptTofu> I need to fork that project oo
18:49:34 <Kiall> I have a PowerDNS backend, but it's not my code to release.
18:49:37 <jcmartin> do you have caching layer ?
18:50:03 <CaptTofu> jcmartin: you meanmemcached?
18:50:20 <jcmartin> no, non authoritative dns servers
18:50:26 <CaptTofu> ah
18:50:26 <Kiall> I think he means how are slaves handled
18:50:34 <CaptTofu> I was going to work on the slave agent
18:50:41 <CaptTofu> that's pretty easy
18:50:46 <jcmartin> at ebay we have tons of caches, and zone creation is tricky
18:50:54 <CaptTofu> dunno if that's in the realm of this issue
18:51:24 <CaptTofu> what was the tricky thing about it? How to update only those that you need to?
18:51:27 <Kiall> jcmartin, what do you guys use? bind? powerdns? something else?
18:51:41 <jcmartin> one of the issue I wanted to discuss in the ML is how much Moniker should care about DNS deployment issues
18:52:01 <jcmartin> We have bind + nominum + F5 GLB
18:52:12 <CaptTofu> that would be in the agent, correct?
18:52:29 <jcmartin> if you need to change the config on the cache, yes
18:52:37 <jcmartin> but it's a different agent
18:52:45 <Kiall> jcmartin, nominum is managed via a REST API, correct?
18:52:52 <jcmartin> you would have to have one for powerDNS/mysql
18:52:59 <jcmartin> and one for the caching server
18:53:08 <jcmartin> YEs, REST
18:53:19 <CaptTofu> I wouldn't mind looking at powerdns
18:53:33 <CaptTofu> it'd have to be a whole new implementation than you have, right Kiall?
18:53:33 <zykes-> powerdns is pretty powerful
18:53:34 <zykes-> :)
18:53:39 <Kiall> CaptTofu, from a easy of use point of view, nothing beats powerdns
18:53:41 <jcmartin> my concern is the plurality of agent/agent types
18:54:03 <CaptTofu> if I push PowerDNS for my solution, I want to know more about it
18:54:03 <Kiall> jcmartin, Ah, I see where you going with this..
18:54:23 <CaptTofu> jcmartin: do you mean how dns is set up systemically?
18:54:27 <jcmartin> PowerDNS will configure the master using mysql/ldap/ ...
18:54:28 <Kiall> bind for masters and F5 load balancing to a pool of nominum slaves?
18:54:51 <jcmartin> but the caches are configured through files, and for each new zone, you have to update the config I think
18:55:23 <jcmartin> F5 has this smart DNS layer giving you geo based resolution
18:55:31 <Kiall> (FYI - We're running out of time BTW)
18:55:39 <jcmartin> it behaves like an auth server
18:55:59 <jcmartin> I'll move the discussion on ML. see you there then
18:56:07 <Kiall> jcmartin, great.
18:56:18 <Kiall> Any other issues/comments etc before I close the meeting?
18:56:38 <Kiall> 5.... 4...
18:56:45 <Kiall> #endmeeting