Open Stack

Thiago,

Throwing IPv6 in the mix does blur the distinction between internal
and external.  In the blueprints, internal and external have more to
do with whether we're dealing with the name/IP mapping internally to
Neutron or externally to Neutron by integrating with an external DNS
service.  In other words, are DNS entries being consumed by other VMs
on the same network from the dnsmasq server or are they being consumed
external to the network from DNSaaS.

This is the type of question that I was looking forward to to help
flesh out the blueprints to make them IPv6 friendly.  Thanks for
asking.

I don't think that we need a separate blueprint as I think that IPv6
will be worked in to the current Neutron architecture.  Sean Collins
made one comment on my blueprint that IPv6 addresses are being
inserted in to the dnsmasq host file.

Thoughts?

Carl

On Wed, Apr 30, 2014 at 4:10 PM, Martinx - ジェームズ
<thiagocmartinsc at gmail.com> wrote:
> Carl,
>
> Let me ask you something...
>
> If my cloud is IPv6-Only based (that's my intention), which blueprint will
> fit on it (internal-dns-resolution or external-dns-resolution) ?
>
> Since IPv6 is all public, don't you think that we (might) need a new
> blueprint for IPv6-Only, like just "dns-resolution"?
>
> BTW, maybe this "dns-resolution" for IPv6-Only networks (if desired) might
> also handle the IPv4 Floating IPs (in a NAT46 fashion)... My plan is to have
> IPv4 only at the border (i.e. only at the qg-* interface within the
> Namespace router (NAT46 will happen here)), so, the old internet
> infrastructure will be able to reach a IPv6-Only project subnet using a well
> know FQDN DNS IPv4 entry...
>
> Best!
> Thiago
>
>
> On 29 April 2014 17:09, Carl Baldwin <carl at ecbaldwin.net> wrote:
>>
>> The design summit discussion topic I submitted [1] for my DNS
>> blueprints [2][3][4] and this one [5] just missed the cut for the
>> design session schedule.  It stung a little to be turned down but I
>> totally understand the time and resource constraints that drove the
>> decision.
>>
>> I feel this is an important subject to discuss because the end result
>> will be a better cloud user experience overall.  The design summit
>> could be a great time to bring together interested parties from
>> Neutron, Nova, and Designate to discuss the integration that I propose
>> in these blueprints.
>>
>> DNS for IPv6 in Neutron is also something I would like to discuss.
>> Mostly, I'd like to get a good sense for where this is at currently
>> with the current Neutron dns implementation (dnsmasq) and how it will
>> fit in.
>>
>> I've created an etherpad to help us coordinate [6].  If you are
>> interested, please go there and help me flesh it out.
>>
>> Carl Baldwin
>> Neutron L3 Subteam
>>
>> [1] http://summit.openstack.org/cfp/details/403
>> [2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution
>> [3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution
>> [4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution
>> [5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem
>> [6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate
>>
>> _______________________________________________
>> 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
>