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.gord...@gmail.com> wrote:
>>
>>
>>
>> On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham <graham.ha...@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@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
