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