Open Stack

I would agree this doesn't make sense in Neutron.

I do wonder if it makes sense in the Network program. I'm getting
suspicious of the programs for projects model if every new project
incubating in seems to need a new program. Which isn't really a
reflection on designate, but possibly on our program structure.

	-Sean

On 05/28/2014 02:21 PM, Carl Baldwin wrote:
> Does this make sense in Neutron?  In my opinion it doesn't.
> 
> DNSaaS is external to Neutron and is independent.  It serves DNS
> requests that can come from the internet just as well as they can come
> from VMs in the cloud (but through the network external to the cloud).
>  It can serve IPs for cloud resources just as well as it can serve IPs
> for resources outside the cloud. The services are separated by the
> external network (from Neutron's perspective).
> 
> Neutron only provides very limited DNS functionality which forwards
> DNS queries to an external resolver to facilitate the ability for VMs
> to lookup DNS.   It injects names and IPs for VMs on the same network
> but currently this needs some work with Neutron.  I don't think it
> makes sense for Neutron to provide an external facing DNS service.
> Neutron is about moving network traffic within a cloud and between the
> cloud and external networks.
> 
> My $0.02.
> 
> Carl
> 
> On Tue, May 27, 2014 at 6:42 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>>
>>
>>
>> On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham <graham.hayes at hp.com> wrote:
>>>
>>>
>>> Hi all,
>>>
>>> Designate would like to apply for incubation status in OpenStack.
>>>
>>>
>>> Our application is here:
>>> https://wiki.openstack.org/wiki/Designate/Incubation_Application
>>
>>
>> Based on
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst
>> I have a few questions:
>>
>> * You mention nova's dns capabilities as not being adequate one of the
>> incubation requirements is:
>>
>>
>>   Project should not inadvertently duplicate functionality present in other
>>   OpenStack projects. If they do, they should have a clear plan and
>> timeframe
>>   to prevent long-term scope duplication
>>
>>
>>     So what is the plan for this?
>>
>> * Can you expand on why this doesn't make sense in neutron when things like
>> LBaaS do.
>>
>> * Your application doesn't cover all the items raised in the incubation
>> requirements list. For example the QA requirement of
>>
>>
>>  Project must have a basic devstack-gate job set up
>>
>>
>>
>>   which as far as I can tell isn't really there, although there appears to
>> be a devstack based job run as third party which in at least once case
>> didn't run on a merged patch (https://review.openstack.org/#/c/91115/)
>>
>>
>>>
>>>
>>> As part of our application we would like to apply for a new program. Our
>>> application for the program is here:
>>>
>>> https://wiki.openstack.org/wiki/Designate/Program_Application
>>>
>>> Designate is a DNS as a Service project, providing both end users,
>>> developers, and administrators with an easy to use REST API to manage
>>> their DNS Zones and Records.
>>>
>>> Thanks,
>>>
>>> Graham
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140528/b2875877/attachment.pgp>