18:03:08 <Kiall> #startmeeting DNSaaS 18:03:08 <openstack> Meeting started Wed Nov 7 18:03:08 2012 UTC. The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:10 <openstack> The meeting name has been set to 'dnsaas' 18:03:15 <Kiall> Hi all! 18:03:34 <Kiall> Everyone had a chance to glance at the agenda? http://wiki.openstack.org/Meetings/DNSaaS 18:03:57 <CaptTofu> yes :) 18:04:35 <Kiall> So - First things first - Stackforge 18:04:56 <Kiall> Moniker's code has been moved to Stackforge, meaning we now use the OpenStack Jenkins and Gerrit install. 18:05:31 <Kiall> Any contributions etc must come via Gerrit! 18:05:59 <Kiall> And a launchpad project has been setup for bug tracking - https://launchpad.net/moniker 18:06:08 <Kiall> File anything you find please! 18:06:31 <CaptTofu> Kiall: I wonder if it'd be a good question to ask who has tried out the code? 18:06:36 <Kiall> Does everyone know how to handle code submissions via Gerrit? 18:06:42 <jcmartin> What model do you want to use : one branch per bug/blueprint or one branch per feature/milestone ? 18:06:43 <Kiall> CaptTofu, yes.. that would be :) 18:07:05 <Kiall> jcmartin, gerrit somewhat pre-defines the meaning of branches 18:07:23 <Kiall> Basically - a branch is a series of related patch sets 18:07:29 <jcmartin> I am not an expert, but recently other project have "feature" branches 18:07:33 <Kiall> each patch in the set must be valid, and pass all tests etc 18:07:51 <Kiall> jcmartin, oh - I havent seen any of the OS projects using those 18:08:03 <Kiall> #link http://wiki.openstack.org/GerritWorkflow 18:08:15 <jcmartin> It depends i guess if you want one level before to get to main, or two 18:08:38 <Kiall> jcmartin, I'll look into how they use them. But traditionally, Gerrit has had a standard flow that prevents long lived topic branches 18:08:45 <jcmartin> they call it topic branches 18:09:38 <zykes-> correct 18:09:51 <zykes-> though isn't that mostly for "big" things like big features? 18:10:03 <jcmartin> through 18:10:04 <Kiall> Sure - I've no idea how the others are using them - So I can't really comment on them (yet)! 18:10:05 <jcmartin> true 18:10:30 <Kiall> So - CaptTofu had a good question re who has actually deployed and tested the code? 18:10:36 <Kiall> Can I get a show of hands? 18:10:52 <jcmartin> not deployed, but tested 18:10:56 <Kiall> <- I obviously have 18:11:08 <Kiall> well -i meant started the whole thing up rather than in production :) 18:11:13 <simonmcc1> the normal gerrit workflow is to create a local branch off the gerrit master head & work there, it's possible to still submit to the for-review master branch 18:11:28 <zykes-> i'll do when the notification stuff is decided and I can put it to use Kiall :) 18:11:32 * CaptTofu does 18:11:57 <simonmcc1> I haven't started anything up yet :) 18:12:34 <Kiall> Okay - So a few - I love to hear feedback from others (maybe after the meeting?) to find out if anything is preventing them from doing so 18:12:37 <Kiall> I would* 18:13:16 <Kiall> So - Moving on - I expect this next one to take a while ;) 18:13:18 <Kiall> #topic Notification Handling 18:13:43 <Kiall> Since the last meeting, I've implemented support for handling notifications from other OS services - eg nova/quantum 18:14:09 <Kiall> What's left to do there is decide on the appropriate actions to take upon receiving a notification 18:14:20 <jcmartin> it was pretty fast, kudos 18:14:47 <Kiall> We agreed last week to auto create records for both floating and fixed IPs as they are assigned to instances. 18:15:04 <Kiall> What we did not decide, was what those records would look like, or what domain they would be created it 18:15:07 <Kiall> created in* 18:15:29 <andrewbogott> Kiall: Can I ask which notification method you're listening for? 18:15:33 <Kiall> I'd like to hear what people expect/want 18:15:56 <andrewbogott> (Maybe there's only one notifier that's appropriate, I haven't looked at the options lately) 18:16:14 <Kiall> andrewbogott, It makes use of the openstack common RPC code 18:16:39 <Kiall> although in a somewhat "unusual" way - I've borrowed the unusual code from Ceiliometer 18:16:41 <CaptTofu> Kiall: I haven't looked at that work, but is documentation there for how these notifications are put to use? 18:16:51 <jcmartin> With regard to the name of the record, we should make it configurable 18:17:13 <Kiall> and am hoping to get a proper well defined notification listener into OS Common - SandyWalsh recently wrote out a BP for just that 18:17:32 <andrewbogott> Kiall: OK, sorry, I'm behind… this is using the rabbit_notifier driver, or...? 18:17:38 <Kiall> jcmartin, configurable is an option, but we are limited by the content of the notifications 18:17:58 <Kiall> andrewbogott, ah yes. On the nova/quantum side - I've tested rabbit_notifier 18:18:11 <andrewbogott> ok. 18:18:12 <Kiall> and on the moniker side - i use the Kombu RPC client 18:18:14 <jcmartin> true, only few options will be possible 18:18:39 <Kiall> CaptTofu, Right now we're trying to figure out what to use them for :) 18:18:39 <CaptTofu> Kiall: also I'll put a plug for the fact for those interested, the REST API for Moniker is documented 18:18:39 <andrewbogott> Kiall: So, I think we'd discussed having some sort of template system that modifies the tenant name and produces the DNS domain... 18:18:56 <andrewbogott> And a similar system that modifies the instance name to produce DNS name 18:19:56 <jcmartin> CaptTofu: can you post a link ? 18:20:09 <Kiall> andrewbogott, can you go into some detail on the sort of modification that might be done? 18:20:20 <Kiall> And - would it be a global per-moniker option, or per tenant? 18:20:31 <andrewbogott> It could be done via regexp or we could have a plugabble system that calls a function. 18:20:39 <andrewbogott> I guess having it be pluggable is good, then the default can be regexp. 18:20:41 <Kiall> jcmartin, I'm uploading the latest now 18:20:49 <Kiall> #link http://packages.python.org/moniker/ 18:21:10 <Kiall> andrewbogott, right - the implementation is pluggable via entry points - it should be trivial to add custom handlers 18:21:58 <andrewbogott> Kiall: cool! So you can just implement a reference plugin that does no transformation (tenant name -> dns domain) 18:22:02 <andrewbogott> and leave the rest to users :) 18:22:25 <Kiall> Thats certainly an option. I have a "toy" implementation here already: https://github.com/stackforge/moniker/blob/master/moniker/notification_handler/nova.py 18:22:49 <Kiall> it creates an A record for $instance_id.$tenant_id.$preconfigured_domain 18:23:10 <Kiall> But - I would prefer to have a more useful default handler included! 18:23:17 <CaptTofu> jcmartin: just check out moniker and build the sphinx docs 18:23:47 <Kiall> jcmartin, do you have any particular format for auto-generated records in mind? 18:23:57 <jcmartin> CapTofu: will play with sphinx 18:23:58 <andrewbogott> Kiall: That sounds pretty useful to me already. 18:24:11 <Kiall> jcmartin, also docs are uploaded to http://packages.python.org/moniker/ 18:24:31 <andrewbogott> Kiall: The next implementation might take a multistropt to map tenants to domains. 18:24:35 <jcmartin> Kiall: no specific format, and I can guarantee that anything we come up with will not work for some users 18:24:47 <araveendrann> is hostname part of the message payload 18:25:01 <CaptTofu> jcmartin: for your convenience, you are welcome to browse my server: http://15.185.172.152/~ubuntu/ 18:25:04 <Kiall> araveendrann, sadly - no! 18:25:19 <jcmartin> instance name should be in some notification, no ? 18:25:27 <Kiall> For reference a sample instance create end notification: https://github.com/stackforge/moniker/blob/master/moniker/tests/sample_notifications/nova/compute.instance.create.end.json 18:25:41 <andrewbogott> Kiall: Wait, I think it is… isn't there a display_name field? 18:25:44 <zykes-> CaptTofu: why that when there's moniker.rthfd.com ? 18:25:48 <zykes-> CaptTofu: why that when there's moniker.rthfd.org sorry ? 18:25:50 <Kiall> yes - display_name is present 18:26:01 <Kiall> zykes-, because the RTFD hasnt updated ;) 18:26:16 <andrewbogott> display_name seems sufficient, unless I misunderstand what it's for. 18:26:53 <Kiall> Maybe we can go display_name.$tenant_id.$preconfigured_domain 18:27:14 <Kiall> But - reusing the same name twice might produce unexpected (or expected) behaviour .. ie a RR DNS record 18:27:18 <araveendrann> but is that field editable by the user, in which case we need to adjust for the new display name 18:27:23 <jcmartin> you might want to add indexes if you have multiple ip, something maybe based on nic priority 18:27:32 <CaptTofu> zykes-: thanks for pointing that out. I volunteer to make that happen whatever the case 18:27:53 <andrewbogott> Kiall: Behold! https://review.openstack.org/#/c/14833/ 18:28:18 <Kiall> araveendrann, actually - your right. the display_name can be changed 18:28:27 <Kiall> So using that might produce some unexpected results 18:29:11 <jcmartin> what about just using some combination of the IP like comcast does and allow users to create cnames ? 18:29:30 <andrewbogott> That certainly solves the uniqueness problem. 18:29:47 <Kiall> jcmartin, thats actually not a bad option. using UUIDs makes the names "almost" useless 18:29:55 <andrewbogott> It would also not be hard to add hostname to the notification. There's a lot in there aleady, I wouldn't think anyone would object to another field. 18:30:08 <jcmartin> based on our experience, you DON'T want to be in the business of defining hostnames for people 18:31:02 <Kiall> andrewbogott, yea - I doubt anyone would 18:31:04 <jcmartin> What we ended up doing is creating a default hostname/record with some internally useful name, and let users add/change it later 18:31:21 <andrewbogott> Kiall: I'm happy to go do that right away, if we conclude that it's useful to us. 18:31:34 <Kiall> jcmartin that seems sane. Does anyone object to using the IP and a pre-defined provider domain as the stock handler? 18:31:45 <zykes-> maybe we can make the dnsrecord templatable ? 18:31:48 <jcmartin> that works for me 18:31:49 <Kiall> andrewbogott, it would certainly be useful for me :) 18:31:51 <zykes-> instead 18:32:29 <andrewbogott> zykes-: I think we've already agreed that there will be (is) a plugin system for customizing the dnsrecord, we're just picking a good default. 18:32:34 <andrewbogott> Kiall: OK, noted. 18:32:48 <andrewbogott> And, +1 for jc's suggestion about using IPs for the first pass. 18:33:16 <araveendrann> this is how ec2 does it ec2-72-44-45-204.compute-1.amazonaws.com 18:33:29 <zykes-> rip of ec2 then :) 18:33:31 <Kiall> Okay - So before we vote on the options (UUID's, IPs, display_name) does anyone have any other suggestions? 18:34:00 <andrewbogott> Kiall: We barely need to vote, each of those is trivial to implement and you can just make it switchable :) 18:34:25 <zykes-> #vote 18:34:27 <zykes-> :p 18:34:33 <Kiall> #startvote Default record format for auto-generated records: UUID, IPs, DisplayName 18:34:36 <Kiall> andrewbogott, too late 18:34:47 <Kiall> #startvote Default record format for auto-generated records? UUID, IPs, DisplayName 18:34:48 <openstack> Begin voting on: Default record format for auto-generated records? Valid vote options are UUID, IPs, DisplayName. 18:34:49 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 18:34:55 <Kiall> #vote IPs 18:35:02 <zykes-> #vote IPs 18:35:02 <jcmartin> #vote IPs 18:35:03 <andrewbogott> #vote IPs 18:35:03 <Kiall> ^ follow that "syntax" to vote :) 18:35:03 <araveendrann> #vote IPs 18:35:03 <uvirtbot`> Kiall: Error: "follow" is not a valid command. 18:35:07 <CaptTofu> #vote IPs 18:35:16 <Kiall> Hah - that was an easy decision so. 18:35:30 <Kiall> Any stragglers? 18:35:42 <Kiall> I guess not. 18:35:43 <Kiall> #endvote 18:35:44 <openstack> Voted on "Default record format for auto-generated records?" Results are 18:35:45 <openstack> IPs (6): CaptTofu, araveendrann, jcmartin, zykes-, andrewbogott, Kiall 18:35:46 <CaptTofu> Kiall: I'll submit the patch for that. I need to put my DBA hat on and add any indexes missing 18:35:56 <Kiall> CaptTofu, great! 18:36:14 <Kiall> #action CaptTofu to provide a patch for the switch to IP based auto generated records 18:36:31 <Kiall> Anything more on notification handling before I move on? 18:37:04 <Kiall> #topic Python Client API and CLI 18:37:52 <Kiall> Okay - So we currently have no usable python client API, or CLI. I have some horrible code that I could clean up, but that would basically be a rewrite anyway 18:38:10 <Kiall> I was hoping to find a volunteer :) 18:38:14 <andrewbogott> It should use openstack-client... 18:38:23 <andrewbogott> I'll volunteer if it can use openstack-client :) 18:38:33 <Kiall> anderstj, when did that come out? Link? -_- 18:38:33 <andrewbogott> Um… for CLI that is. 18:38:55 <Kiall> #link https://github.com/openstack/python-openstackclient 18:39:20 <jcmartin> #link http://blog.doughellmann.com/2012/10/cliff-command-line-interface.html 18:39:30 <jcmartin> this is not openstack vetted yet 18:39:35 <Kiall> jcmartin, the current skeleton CLI is using cliff 18:39:43 <Kiall> (It used for database init and sync right now) 18:39:44 <jcmartin> cool 18:40:04 <Kiall> And it looks like python-openstackclient uses it to 18:40:05 <Kiall> too 18:40:17 <jcmartin> then it's vetted 18:40:23 <Kiall> andrewbogott, willing to volunteer? :) 18:40:43 <Kiall> The REST API is small, so the Python API and CLI should be fairly minimal 18:40:50 <andrewbogott> Kiall: We're talking about the layer that implements a CLI and converts it to REST calls? I'm happy to do that. 18:41:05 <CaptTofu> I'll help certainly 18:41:26 <Kiall> andrewbogott, yes - So a python lib that makes the API requests, and a CLI that wraps it 18:42:19 <andrewbogott> Yep, sounds good. 18:42:34 <zykes-> converts it how ? 18:42:56 <CaptTofu> adrewbogott: sounds pretty easy to use eh? 18:42:57 <andrewbogott> Um… maybe my use of 'convert' was ill-conceived. 'relays'. 18:43:01 <Kiall> Interestingly, it looks like python-openstackclient only does the CLI part, and doesnt provide the a python API for the services 18:43:21 <Kiall> andrewbogott, it's certainly worth looking at anyway! 18:43:33 <Kiall> #action andrewbogott Look into python API and CLI 18:43:43 <Kiall> #action CaptTofu Look into python API and CLI w/andrewbogott 18:44:02 <CaptTofu> #action CaptTofu add indexes 18:44:08 <Kiall> We all expect results in the next 30 mins or so ;) 18:44:11 <Kiall> Get to it 18:44:12 <Kiall> ! 18:44:13 <CaptTofu> hehe 18:44:15 <CaptTofu> that's funny 18:44:25 <Kiall> Next up is DevStack 18:44:29 <Kiall> #topic DevStack 18:44:53 <Kiall> It seems we can't just add support for Moniker straight to devstack unless we're officially an incubated project 18:45:07 <Kiall> So - Even if we start that today, it will be a while before it's official. 18:45:36 <Kiall> I'm going to fork devstack and add moniker support there - I'll hopefully get it done before the next meeting 18:45:46 <Kiall> that should make things easier for all involved 18:45:56 <Kiall> #action kiall Add moniker support to a DevStack fork 18:46:41 <Kiall> And - rushing over that last one - we move on to the last topic: 18:46:41 <jcmartin> What backend should this include ? 18:46:52 <Kiall> Hah - Almost ;) 18:47:13 <Kiall> jcmartin, I would like to see PowerDNS as its easier to get going than bind 18:47:16 <jcmartin> maybe you should implement the plugin model before 18:47:31 <andrewbogott> I'll want to implement the pdns/ldap backend somewhat quickly. But I'm not sure that helps anyone but me. 18:47:42 <jcmartin> I mean for devstack, fake backend or dnsmasq ? 18:48:00 <Kiall> jcmartin, agreed, I've got the agent conversion to proper plugins half done 18:48:18 <andrewbogott> A fake backend that basically just logs commands will be useful for development. And quick to write. 18:48:43 <jcmartin> can we configure dnsmasq to return host file like entries ? 18:49:09 <jcmartin> fake backend would be good for now anyway 18:49:15 <Kiall> andrewbogott, good idea. I'll add it to my todo list. I've almost got the agent converted to a proper plugin system.. I'll add that once I'm done (or maybe someone can beat me to it? ;)) 18:49:26 <CaptTofu> jcmartin: fake backend, what would that mean exactly? 18:49:29 <Kiall> #action Kiall to complete agent conversion -> plugin system 18:49:36 <CaptTofu> just logs commands, stubbed out 18:49:37 <CaptTofu> ? 18:49:41 <jcmartin> yep 18:49:51 <Kiall> #action Kiall (or someone!) to write a logging/fake agent 18:50:04 <zykes-> so what, make 1 agent to rule them all via plugins ? 18:50:14 <Kiall> jcmartin, We can hace dnsmasq serve a hosts file 18:50:16 <Kiall> have* 18:50:46 <jcmartin> plugin should not be in the agent in my opinion 18:51:20 <Kiall> jcmartin, any reason why not? (That is the route I've taken so far) 18:51:48 <jcmartin> it means that you have to have the agent. Some DNS server already expose a rest api, why use an agent ? 18:52:54 <jcmartin> or in the case of powerdns, the agent would just configure ldap/mysql 18:53:03 <CaptTofu> zykes-: what do you mean 1 agent to rule them all via plugins? 18:53:13 <Kiall> The main reason I chose to always have an agent (even for simpler agents) was to keep the clear separation, and avoid confusion over where the code that talks to the backend is executing 18:53:13 <jcmartin> agent is useful if you have to update local files 18:53:15 <zykes-> CaptTofu: as in 1 agent daemon that loads plugins 18:53:19 <CaptTofu> ah 18:53:43 <CaptTofu> zykes-, Kiall, jcmartin: the agent code I think lends itself well to that 18:53:54 <jcmartin> I agree to use RPC as an API, but it's not an agent, it's the server 18:54:06 <Kiall> There is nothing preventing the agent from running alongside moniker-central 18:54:23 <Kiall> jcmartin, I'm not sure I understand? 18:54:25 <jcmartin> True, it's more of a deployment decision 18:55:01 <jcmartin> My point is that the deployment will be driven by the type of plugin, which may be ok 18:55:06 <Kiall> Is the confusion is over the word "agent"? that the word agent lends itself to being co-located with the backend itself? 18:55:17 <Kiall> And with - say powerdns+ldap - that may not be the case 18:55:45 <Kiall> (I'm speaking of my confusion BTW - Not yours :)) 18:56:11 <jcmartin> Kiall: i think it's fine for now, but we may want to look at some DNS deployment model and see how this works 18:56:18 <zykes-> I guess this is a 2 part question then 18:56:21 <Kiall> jcmartin, agreed. 18:56:34 <jcmartin> I an volunteering to provide some blurb on that 18:56:38 <jcmartin> and we can review 18:56:40 <Kiall> So since we're almost out of time, and I believe this room is booked for 18:56:46 <Kiall> 19:00 (aka 2 mins) 18:56:49 <zykes-> 1 plugin side on the central 18:57:00 <zykes-> 1 plugin on the agent side 18:57:03 <Kiall> lets move onto the very last topic 18:57:06 <Kiall> #topic Incubation 18:57:09 <CaptTofu> do we vote on something? 18:57:17 <Kiall> CaptTofu, no need I think 18:57:20 <CaptTofu> ok 18:57:42 <Kiall> #action jcmartin to look into incubation, the process, and the options. 18:57:48 <jcmartin> agreed 18:57:57 <CaptTofu> that was easy 18:58:00 <Kiall> JC agreed earlier today to look into the incubation options for next weeks meeting 18:58:10 <CaptTofu> thanks JC! 18:58:20 <jcmartin> I'll take also the deployment option doc 18:58:34 <Kiall> jcmartin, great :) 18:58:44 <Kiall> #action jcmartin to look into various deployment options 18:59:09 <jcmartin> just on time 18:59:25 <Kiall> Okay - thanks all. Times up! 18:59:27 <Kiall> #endmeeting