17:02:07 <Ryan_Lane> #startmeeting DNSaaS
17:02:08 <openstack> Meeting started Wed Oct 31 17:02:07 2012 UTC.  The chair is Ryan_Lane. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:10 <openstack> The meeting name has been set to 'dnsaas'
17:02:12 <jcmartin> will that be in the log ;-)
17:02:27 <Ryan_Lane> heh
17:02:51 <zykes-> aloha
17:02:57 <Kiall> Hiya
17:03:12 <CaptTofu> greeting all (attempt #2)
17:03:46 <Ryan_Lane> let me find the etherpad
17:03:51 <Ryan_Lane> anyone have a link handy?
17:03:54 <Kiall> https://etherpad.openstack.org/openstack-dns
17:03:56 <markmcclain> o/
17:04:14 <Kiall> + http://wiki.openstack.org/DNSaaS
17:04:14 <Kiall> + https://docs.google.com/document/d/1UFoAc7E17XivlV7h2PD4SCMeEhLecvPw0GAaoq_JKCk/edit
17:05:03 <jcmartin> I update http://wiki.openstack.org/DNSaaS with links
17:05:16 <Ryan_Lane> https://etherpad.openstack.org/DNSaaS_initial_meeting
17:05:22 <Ryan_Lane> that was for agenda
17:05:44 <Ryan_Lane> well, let's get started then
17:06:03 <Ryan_Lane> #topic agreement/recap of the initial feature set
17:06:20 <Ryan_Lane> has everyone had a chance to go over the linked information?
17:06:36 <Kiall> I have
17:06:39 <jcmartin> I added this one: Are we still agreeing on supporting only notification based A/PTR creation ?
17:06:55 <jcmartin> for fixed IP and floating IP ?
17:07:00 <zykes-> anyone from GD here ?
17:07:30 <Ryan_Lane> hm. seems not. that's going to be a problem.
17:07:32 <rlz> Yes
17:07:35 <Ryan_Lane> ah. good
17:07:40 <rlz> I'm from GD
17:07:46 <zykes-> rlz: ok :)
17:07:57 <Kiall> jcmartin, that depends on the initial scope, internal DNS/internal+external DNS/external DNS
17:08:16 <Ryan_Lane> even the nova DNS driver has support for managing zones
17:08:16 <nsavin> I'm from GD
17:08:31 <Kiall> FYI: I wasn't at the summit - and could barely hear a thing on WebEx
17:08:53 <Kiall> So - It's possible I'm in the dark around a few decisions
17:09:06 <jcmartin> that's why i propose we recap
17:09:17 <CaptTofu> Hi everyone, please to introduce you to Kiall, the fellow I was IRCing with
17:09:26 <Ryan_Lane> well, let's discuss the initial feature set that we should be targeting
17:10:21 <jcmartin> tenant private zone with A record for UUID and instance name ?
17:11:04 <jcmartin> public zone with floating ip A record (or CNAME) ?
17:11:26 <Ryan_Lane> I think those are definitely needed for initial feature set
17:11:27 <nsavin> PTR records ?
17:11:33 <Ryan_Lane> I think zone creation is also likely needed
17:11:35 <jcmartin> PTR too
17:11:49 <CaptTofu> zone creation, A, CNAME, MX, ...
17:11:53 <Ryan_Lane> PTR records should also be supported, if the backend needs them (some powerdns ldap backends don't)
17:11:54 <jcmartin> Ryan_Lane: managed by tenant ?
17:12:02 <Kiall> I would be looking for public zones with arbitrary records, in additional to generated A/PTR's for fixed and floating Ips
17:12:31 <jcmartin> Kiall: should be second phase in my opinion
17:12:38 <rlz> Is it good idea to generate names for floating IP automatically?
17:13:18 <Kiall> jcmartin, any reasoning for that?
17:13:28 <jcmartin> Should we postpone floating IP for now ?
17:13:44 <Ryan_Lane> Kiall: one reason is then backends need to have some way of saying "I can't add records like that"
17:13:48 <Kiall> Does arbitrary zone and record creation not provide the core of what's needed to handle automated record creation and deletion?
17:14:00 <jcmartin> Kiall: would require REST service. Just phasing
17:14:06 <Ryan_Lane> jcmartin: I think floating IP is very much needed for initial feature set
17:14:19 <Kiall> jcmartin, right, but both nova-dns and Moniker have REST interfaces already
17:14:59 <zykes-> uhm
17:15:01 <jcmartin> I'm fine if there is time to implement everything, but it seems tight ...
17:15:19 <zykes-> for floating IP's is really easy I think, just grab the last bits of the uuid and make a record ?
17:15:39 <rlz> As I remember we were going to merge implementations first?
17:15:45 <Ryan_Lane> yes
17:15:51 <Ryan_Lane> that's another topic, though
17:16:30 <jcmartin> since there is no parity, between implementations, we need to work on feature set first
17:16:35 <Kiall> rlz, you're Dmitry, yes? One of the nova-dns authors?
17:16:45 <rlz> Why only last bits of the uuid?
17:17:18 <rlz> Yes, I'm Dmitry
17:17:31 <zykes-> rlz: cause anymore isn't needed or ?
17:17:54 <jcmartin> Can we recap quickly on what is not controversial: A & PTR record for Fixed IP based on notification ?
17:18:10 <Ryan_Lane> that's not controversial.
17:18:20 <andrewbogott> rlz:  Let's set aside implementation for now, and call that feature "Automatic record creation upon floating_ip assignment."  Presumably the associated name will be something arbitrary and unique.
17:18:20 <Ryan_Lane> I don't think floating IPs are either
17:18:27 <jcmartin> in a tenant private zone, with tenant id as a name ?
17:18:36 <Ryan_Lane> instance_name_template <--
17:18:40 <Ryan_Lane> it should likely use that
17:18:49 <Ryan_Lane> anyway, that's an implementation detail
17:18:57 <Kiall> jcmartin, That's what I was thinking for auto fixed+floading IP records
17:19:06 <Kiall> floating*
17:19:39 <jcmartin> can we record this with the meetbot thingy ? Ryan ?
17:19:42 <Kiall> Ryan_Lane, agreed - lets not dig down into implementation detail just yet
17:19:45 <andrewbogott> https://etherpad.openstack.org/GrizzlyDNSaaS
17:19:56 <CaptTofu> I think meetbot is already running.
17:20:02 <Ryan_Lane> should this be under #action?
17:20:08 <jcmartin> "#agreed"
17:20:19 <Kiall> action is a "todo"
17:20:33 <andrewbogott> (sorry, maybe adding etherpad to the mix is one too many channels)
17:21:02 <Ryan_Lane> #agreed A/PTR for fixed IP networks should be in initial feature set
17:21:26 <Kiall> #agreed
17:21:32 <jcmartin> Zone name = tenant id ?
17:21:53 <Ryan_Lane> actually, I'm a little confused by that
17:22:01 <Ryan_Lane> isn't that something that would go into quantum?
17:22:09 <jcmartin> that's what nova-dns does today i think
17:22:18 <nsavin> exactly
17:22:24 <rlz> Yes nova-dns behave in this way
17:22:35 <Ryan_Lane> so, the dns service itself doesn't need to handle that
17:22:49 <jcmartin> dns service has to create the zone though
17:23:07 <rlz> As I remember quantum do not want to know about DNS anything. Just send notifications about addresses.
17:23:31 <Kiall> rlz, I agree with that - notifications are sent, the DNS service can act on them
17:23:33 <rlz> Zone can be configured only in DNS service
17:23:33 <jcmartin> yes, first feature is autopilot based on notification. No tenant involvement
17:23:47 <Ryan_Lane> ok
17:24:24 <jcmartin> what's the status on zone naming then ?
17:24:30 <Ryan_Lane> zone naming?
17:24:38 <jcmartin> zone name = tenant id
17:24:44 <nsavin> in quantum instance can have several associated IPs. Which one to use in DNS for A record ?
17:25:00 <jcmartin> all of them ?
17:25:04 <markmcclain> I think it depends on the network type
17:25:13 <Kiall> jcmartin, Personally, that makes sense to me. But - I think that's an implementation detail.
17:25:29 <Kiall> (Which can be decided later)
17:25:45 <jcmartin> Kiall: I'm fine postponing. let's move on
17:25:54 <rlz> Kiall, what is implementation detail?
17:25:58 <Ryan_Lane> ok. floating IPs?
17:26:21 <jcmartin> Floating IP yes
17:26:22 <Ryan_Lane> for floating IPs we likely need the ability to create and associate zones with tenants
17:26:47 <andrewbogott> n.b. can we try to say 'domain' rather than 'zone'?  'zone' has a meaning within Nova so is ambiguous.
17:26:50 <Kiall> rlz, the decision to use incrementing integer IDs or UUIDs for database recrods would be an implementation detail (most of the time)
17:26:53 <Ryan_Lane> sorry, yes
17:27:00 <jcmartin> domain too in libvirt
17:27:07 <Ryan_Lane> ugh. domains are in keystone too
17:27:08 <andrewbogott> crap!
17:27:11 <Ryan_Lane> let's use DNS zone
17:27:24 <andrewbogott> yep, ok.
17:27:26 <zykes-> :p
17:27:41 <rlz> Same for fixed IPs - we need ability to create zones and associate them with tenant
17:27:56 <dolphm> (sorry! love, -keystone)
17:28:01 <andrewbogott> So right now we're talking about automatic entry creation for floating IPs right?
17:28:07 <jcmartin> rlz: who does that, tenant ?
17:28:09 <Kiall> andrewbogott, yes
17:28:10 <zykes-> rlz: shouldn't the "Tenant" maybe be allowed to "set" their local zone themselves ?
17:28:14 <zykes-> or their zones
17:28:15 <andrewbogott> So I think the question of dns zones: tenants is the same for both.
17:28:20 <Ryan_Lane> rlz: I mean via the REST api
17:28:21 <Kiall> zykes-, one issue with that is overlaps
17:28:36 <zykes-> Kiall: overlaps how ?
17:28:53 <nsavin> in nova-dns zone created for tenant in nova-dns service lazy way.
17:28:54 <Ryan_Lane> oh. automatic entry creation?
17:29:04 <Ryan_Lane> sorry, I was thinking end-user entry creation
17:29:05 <rlz> Same for me: I want to API to create and set zone to use for fixed and floating API separatly
17:29:16 <andrewbogott> So the simple version is to use a template and create the dns zone the first time it is needed.
17:29:23 <Kiall> zykes-, two tenants choosing the same DNS zone name.
17:29:31 <andrewbogott> The complicated version is to add REST api to explicitly associate specific tenants with specific Zones.
17:29:40 <Ryan_Lane> managing floating IPs creation and fixed IP creation is basically the same thing
17:30:01 <Kiall> andrewbogott, yes - while that would be nice. I think that's probably more complicated than it seems at first glance.
17:30:05 <Ryan_Lane> if we are using notifications for fixed, we could use them for floating, too
17:30:08 <jcmartin> I suppose that the top level DNS zone will be provider owned, right ?
17:30:33 <Kiall> jcmartin, Yes - I would say so
17:30:35 <jcmartin> notification for floating ip, yes. But what is used as the label/name ?
17:30:35 <Ryan_Lane> if we're talking about auto-creation, yes
17:30:40 <andrewbogott> Yes, we will have a 'phase one' feature set that's based entirely on notifications and templates.  Then phase two will include REST that allows customization of a ton of things.
17:30:47 * andrewbogott suggests
17:30:56 <Ryan_Lane> jcmartin: well, many providers use the IP in the name
17:31:15 <Ryan_Lane> I think basing it on a template is best, though
17:31:16 <Kiall> also - nothing stopping you from registering lots of A records..
17:31:18 <Kiall> eg
17:31:19 <Ryan_Lane> but that's implementation
17:31:33 <andrewbogott> jcmartin: Can be a template that has access to one of many instance descriptors from the notification.
17:31:34 <andrewbogott> jcmartin:  e.g. uuid, ip, display name, etc.
17:31:35 <Kiall> UUID.zone, instance_name.zone, secgroup.zone etc
17:32:06 <jcmartin> template is fine.
17:32:32 <Ryan_Lane> so, agreed that auto-creation of floating dns should also be in initial implementation?
17:32:43 <Kiall> #agreed
17:32:44 <jcmartin> however, you might be constrained by what is in the notification
17:33:06 <Kiall> jcmartin, if needs be, we can query the nova/quantum APIs for more info
17:33:12 <Kiall> (Or get the info added to the notification)
17:33:18 <jcmartin> ok
17:33:50 <Ryan_Lane> #agreed auto-creation of floating dns should also be in initial implementation
17:34:03 <markmcclain> If there are items missing from the Quantum notifications we should generate bugs
17:34:10 <Ryan_Lane> indeed
17:34:22 <markmcclain> most notifications include all of the info that Qunatum has on hand
17:34:24 <Ryan_Lane> any other features we should target for initial feature set?
17:34:39 <jcmartin> so to recap, first phase is: based on notification, we will create A & PTR record for fixed and floating ip. Zone will be created based on template driven schema
17:34:41 <andrewbogott> Can we also clarify what an automatic record will look like?  Are we strictly talking about a records, or is this configurable somehow?
17:34:42 <Kiall> Ryan_Lane, I would argue for arbitrary zones and records. for 2 reasons:
17:34:47 <rlz> rest API IMHO should be in the first implementation
17:34:47 <andrewbogott> Oh, ok, there it is :)
17:34:54 <Kiall> 1) Moniker already has this implemented ;)
17:35:20 <Kiall> 2) Its *almost* free after being able to create/delete zones and add remove/records from the notifications
17:35:28 <Ryan_Lane> I agree
17:35:52 <andrewbogott> Implementing the REST is easy, agreeing on the feature set will be the hard part.
17:36:02 <Ryan_Lane> anyone disagree with rest API for managing zones and arbitrary records?
17:36:13 <jcmartin> Ok with me
17:36:23 <nsavin> already in nova-dns
17:36:26 <andrewbogott> …or maybe not!
17:36:46 <Ryan_Lane> #agreed rest API for managing zones and arbitrary records will be in initial feature set
17:36:57 <Ryan_Lane> ok. I think that's more than enough features ;)
17:37:00 <Ryan_Lane> next topic?
17:37:14 <Ryan_Lane> #topic merging of projects
17:37:15 <jcmartin> there is nothing left in term of features anyway ;-)
17:37:18 <Ryan_Lane> heh
17:37:25 <Ryan_Lane> jcmartin: that's not true :)
17:37:28 <zykes-> n39
17:37:35 <Ryan_Lane> RR DNS, geodns, etc
17:37:41 <Kiall> DNSSEC ;)
17:37:44 <Kiall> Loads more to do.
17:37:47 <Ryan_Lane> indeed
17:37:56 <CaptTofu> DNSSEC :)
17:38:05 <jcmartin> I tried to do a comparison : https://docs.google.com/document/d/1UFoAc7E17XivlV7h2PD4SCMeEhLecvPw0GAaoq_JKCk/edit
17:38:11 <CaptTofu> what about things like multicast?
17:38:37 <Kiall> CaptTofu, you mean mDSN?
17:38:39 <Kiall> mDNS*
17:38:56 <Ryan_Lane> CaptTofu: I think we have enough features for initial project
17:39:14 <CaptTofu> Just thinking of it.
17:39:56 <Kiall> jcmartin, for the most part that doc was accurate for Moniker.
17:39:57 <jcmartin> going back to merge : nova-dns seems a superset, but architecture is less aligned with end goal
17:39:57 <Ryan_Lane> so, we have two projects that we could base the project on. both are fairly mature. we need to decide which one we'll use and how we'll merge
17:40:25 <Ryan_Lane> let's start this the easy way
17:40:31 <Kiall> Probably worth mentioning by bias ;)
17:40:35 <Kiall> my bias*
17:40:37 <Ryan_Lane> is one project willing to merge themselves into the other? :)
17:40:49 <CaptTofu> heh
17:41:01 <CaptTofu> what does merge mean in this case?
17:41:07 <andrewbogott> Which of the two stand-alone implementations are the most OpenStack like?  e.g. does either use common classes?  The sqlalchemy, wsgi, etc?
17:41:08 <Kiall> CaptTofu, yea.
17:41:23 <CaptTofu> the latter does yes
17:41:24 <jcmartin> I captured that in the doc
17:41:32 <CaptTofu> moniker does, I mean
17:41:34 <Kiall> For me - Merging means people, rather than code. Both are very different from a code POV
17:41:39 <jcmartin> Moniker is the most openstack compliant
17:41:54 <jcmartin> (and by the way, I like the codename too)
17:41:57 <Kiall> andrewbogott, Moniker is almost exclusively openstack-common code
17:42:02 <Kiall> jcmartin, thanks ;)
17:42:26 <jcmartin> nova-dns is more of an extension of nova
17:42:32 <Ryan_Lane> moniker is based on rackspace api right?
17:42:39 <CaptTofu> if you skeletonized it, it'd make a good study on an openstack project
17:42:46 <CaptTofu> somewhat
17:42:46 <Ryan_Lane> anyone from rackspace here?
17:42:50 <Kiall> Ryan_Lane, It started that way. The API is not compatible anymore.
17:42:52 <Kiall> But
17:42:53 <CaptTofu> damn, I should let Kiall answer
17:43:02 <Kiall> The API is built to be switchable
17:43:13 <jrodom> Ryan_Lane:  im from rackspace, sorry been lurking :)
17:43:14 <Kiall> implementing RS or R53's API would be trivial
17:43:15 <jcmartin> one thing through me out in moniker: what is schema in the api ?
17:43:31 <Ryan_Lane> well, it may not be a problem to be incompatible
17:43:38 <Kiall> jcmartin, JSON Schemas - Used to define for format and rules for the API's JSON
17:43:45 <Ryan_Lane> if rackspace is willing to work with us and base their api on ours for their next version
17:43:48 <Kiall> #link http://json-schema.org/
17:44:07 <jrodom> Ryan_Lane: we're definintely interested in collaborating on this
17:44:10 <Kiall> Ryan_Lane, I open to re-doing the API
17:44:11 <Ryan_Lane> great
17:44:31 <Kiall> I personally prefer my way ;) But am not overly attached.
17:44:34 <jcmartin> proposal : start with moniker and merge in code from nova-dns
17:44:52 <jrodom> this is just getting on my radar and i'd love to get my team more involved.  was just trying to ensure we were trying to solve the same problem, which it seems like we are.
17:45:12 <Ryan_Lane> yeah
17:45:12 <andrewbogott> jcmartin:  I think that's a good approach.  Does moniker already have a well-defined back-end API for different DNS implementations?
17:45:28 <jcmartin> back end need work IMHO
17:45:45 <Kiall> andrewbogott, it's based on RPC agents - different actions trigger an RPC event for the DNS server agents to pick up
17:45:45 <jcmartin> need more plugin based model
17:46:01 <Kiall> as jcmartin says - the current backend implementation is far from stable
17:46:13 <jcmartin> rpc agen can be one implementation of the driver for file based DNS
17:46:21 <Kiall> I actually have a PowerDNS agent implementation - but it's based on my clients code.
17:46:32 <Kiall> So - for legal reasons - I simply can't release it
17:46:57 <jcmartin> back to decision : merge which way ?
17:47:09 <andrewbogott> There's a third candidate besides moniker and nova-dns, right?
17:47:14 <Ryan_Lane> I'd say let's use moniker and merge nova-dns
17:47:29 <Kiall> My bias should be obvious merge into Moniker, but I really want to hear what others this is best!
17:47:30 <Ryan_Lane> is there any objection? should we take a vote?
17:47:32 <zykes-> +1 on Kiall
17:47:51 <jcmartin> let use the bot thinghy
17:47:52 <CaptTofu> +1 on Moniker
17:47:56 <Kiall> psst - Ryan_Lane  #startvote
17:48:01 <Ryan_Lane> #startvote
17:48:14 <Kiall> psst - Ryan_Lane  #startvote <vote subject> I think
17:48:25 <Ryan_Lane> #startvote Use moniker and merge other projects in
17:48:30 <andrewbogott> Um… wait, I don't understand what the alternatives are yet.  I think we need to be clear on whose code we are discarding so that we have buy-in from the owners of that code.
17:48:37 <andrewbogott> So, for example -- nova-dns is mine, you have my buy-in :)
17:48:48 <Kiall> andrewbogott, there are 2 nova-dns projects ;)
17:48:52 <Ryan_Lane> there's basically 3
17:48:53 <Kiall> The one built into nova
17:48:57 <andrewbogott> Oh!  I see.
17:49:03 <Kiall> and github.com/griddynamics/nova-dns
17:49:05 <Ryan_Lane> ours, grid-dynamics and moniker
17:49:07 <andrewbogott> So when we've been saying 'nova-dns' we were talking about griddynamics.
17:49:10 <Ryan_Lane> #vote yes
17:49:16 <andrewbogott> In that case we're good.
17:49:17 <jcmartin> #vote yes
17:49:22 <andrewbogott> #vote yes
17:49:23 <Kiall> #vote yes
17:49:25 <CaptTofu> #vote yes
17:49:33 <markmcclain> #vote yes
17:49:43 <jcmartin> gd guys ?
17:50:01 <Kiall> Yea - I really do want to hear from the GD crowd
17:50:06 <rlz> We can agree but we need all functionally from current nova-dns
17:50:06 <Ryan_Lane> agreed
17:50:22 <Ryan_Lane> rlz: does the initial feature set proposed match it?
17:51:33 <rlz> Not sure
17:51:53 <Ryan_Lane> so, this won't mean that your project needs to immediately go away
17:52:08 <Ryan_Lane> it's just that we're picking a specific project that we'll want to push into incubation
17:52:19 <rlz> Yes. We will stay on our project and wait
17:52:20 <Kiall> rlz, can you produce a list of all current nova-dns features over the next few days? I would love to have that info readily available
17:52:23 <nsavin> by the way, does moniker now listen for notifications and add/remove records in dns for instances ?
17:52:23 <Ryan_Lane> and that over time, when moniker is ready for you, you can kill your other project
17:52:37 <Ryan_Lane> rlz: but it means that you'll need to start putting some of your code into moniker
17:52:42 <jcmartin> nsavin : it does not, that's why your code is required
17:52:42 <Kiall> nsavin, not yet. I actually started work on that a about an hour ago though
17:52:54 <Kiall> But - Its far from working
17:52:55 <Kiall> ;)
17:52:56 <jcmartin> merge means 1+1
17:53:08 <Kiall> I would love to get some code handed to me instead :)
17:53:12 <nsavin> for me nova-dns(our representation) looks like working thing.
17:53:27 <Ryan_Lane> rlz: basically it means you'll be maintaining code in two places for a while
17:53:38 <nsavin> and moniker - as skeleton of something distributed and not fully understandable for me
17:53:43 <jcmartin> nsavin: your code is querying nova db : bad
17:53:57 <nsavin> yeah. but better than do nothing ;)
17:54:13 <jcmartin> through. but if we merge, I would think we can do it right
17:54:39 <Kiall> nsavin, You're right - moniker currently does not listen to notifications, but does provide much of the other groundwork for actually actioning those notifications.
17:54:56 <jcmartin> can we close on the vote ?
17:55:14 <Ryan_Lane> it would be good to get a yes or no from the gd people :)
17:55:18 <Ryan_Lane> or abstain
17:55:51 <Kiall> Ryan_Lane, whenever your ready.. it's #endvote Found the meetbot docs: http://ci.openstack.org/meetbot.html
17:55:53 <nsavin> #vote no - moniker for me now just an "thing which possibly will work later"
17:55:53 <rlz> Also I want to review API to make decision
17:56:22 <Ryan_Lane> ok. ending vote in 30 seconds
17:56:26 <Kiall> rlz, by API do you mean REST API?
17:56:28 <rlz> Is current API described?
17:56:35 <rlz> Yes, REST API
17:56:36 <jcmartin> rlz:nsavin : you can start by reviewing and commenting on https://docs.google.com/document/d/1UFoAc7E17XivlV7h2PD4SCMeEhLecvPw0GAaoq_JKCk/edit#heading=h.r8knc0f9p9tq
17:56:49 <Ryan_Lane> #endvote
17:57:03 <Kiall> It's described by the JSON schemas here: https://github.com/managedit/moniker/blob/master/moniker/api/v1/schemas.py
17:57:13 <Kiall> (and json-schema.org )
17:57:20 <nsavin> jsmartin: can'
17:57:22 <Kiall> But - It's not documented yet.
17:57:40 <nsavin> jcmartin: can't edit this document
17:58:18 <Kiall> jcmartin, can you port that doc to the wiki?
17:58:26 <Ryan_Lane> so, I'm not very sure what decision that vote actually makes.
17:58:59 <Ryan_Lane> are we going forward with moniker as a project that we'll eventually push into incubation?
17:59:11 <Kiall> Ryan_Lane, The vote was "<Ryan_Lane> #startvote Use moniker and merge other projects in"
17:59:11 <jcmartin> i'll mov the doc to the wiki if it's easier
17:59:11 <Ryan_Lane> or do we need another meeting on this topic?
17:59:17 <Kiall> Rough count of 6 or so yes and 1 no
17:59:42 * Ryan_Lane nods
17:59:53 <Ryan_Lane> no buy in from one of the three merging projects, though
18:00:15 <rlz> JSON schemas is not an API description. It is just some JSON document description. It is not clear how to use this JSON documents, and way can be done through API
18:00:33 <Kiall> rlz, agreed. Real documentation is certainly needed
18:00:56 <Ryan_Lane> ok. we're out of time
18:00:58 <nsavin> so can I ask that is now in and working in moniker project ?
18:01:18 <rlz> http://openstack.griddynamics.com/docs/nova-dns/restapi.html
18:01:29 <Ryan_Lane> we'll need to continue this off channel
18:01:31 <CaptTofu> nsavin: you mean who is working on it?
18:01:34 <Ryan_Lane> #endmeeting