openstack team mailing list archive

[Kiall Mac Innes <kiall@xxxxxxxxxxxx>]

Hi Andrew,

EC2 has a feature where if an instance has a fixed IP of 10.0.0.1, and a
floating IP of 1.2.3.4. All DNS lookups performed against the DNS name for
1.2.3.4, from within the same region, will return 10.0.0.1.

E Hammond from Alestic probably explains it better :)

> When an EC2 instance queries the external DNS name of an Elastic IP, the
EC2 DNS server returns the internal IP address of the instance to which the
Elastic IP address is currently assigned.

While this has advantages for traffic accounting in EC2, It can
additionally provide a fix for the inability of an OpenStack instance to
reach it's own floating IP address. (Try ping'ing a floating IP from the
instance that floating IP is assigned to.. It will fail).

I hope this explains it a tad better :)

Thanks,
Kiall


On Fri, Jan 6, 2012 at 9:26 PM, Andrew Bogott <abogott@xxxxxxxxxxxxx> wrote:

>  Kiall --
>
> So far I haven't accounted for a special case like that.  Can you explain
> the exact scenario you're worried about?
>
> With the current design, you could get a list of instances associated with
> a public IP, and then do a by-name query using the name and private domain
> to get the private IP.  Does that not get you what you need?
>
> -Andrew
>
>
> On 1/6/12 11:57 AM, Kiall Mac Innes wrote:
>
> Hi Andrew,
>
>  Yes - That makes sense. Thanks!
>
>  So, Another question. On EC2, Querying for the external DNS name of an
> instance will return its internal IP, if the query originates from the
> same availability zone (or maybe region, I can't remember offhand). Is
> this planned?
>
>  This would (in a roundabout way) resolve the issue of being unable to
> access the local instance via its floating IP..
>
>  Thanks,
> Kiall
>
>
> On Fri, Jan 6, 2012 at 7:47 PM, Andrew Bogott <abogott@xxxxxxxxxxxxx>wrote:
>
>>  Kiall --
>>
>> There's a bit of terminology confusion in that blueprint, which I'm
>> trying to resolve.  For starters, 'dns zone' and 'availability zone' were
>> both getting called 'zones' which I've tried to resolve by replacing 'dns
>> zone' with 'dns domain' wherever possible.
>>
>> The other confusion is that the blueprint says 'public/private' where it
>> should probably say 'floating/instance'.  The current design assumes that
>> instance DNS entries (which are automatically created and deleted as
>> instances are added and removed) will always be placed in private DNS
>> domains.  Specifically, all the instances in a given availability zone will
>> be assigned DNS entries in the private domain that is associated with that
>> zone.
>>
>> So, for example, in availability zone1, you would:
>>
>> a) Create a DNS domain called 'somedomain.internal' and assign it to zone1
>> b) Set FLAGS.instance_dns_domain for zone1 to 'somedomain.internal'
>> c) After which, a new instance in zone1 would be automatically assigned a
>> DNS name e.g. 'instance1.somedomain.internal'.
>>
>> It would be possible to eliminate step a) and have step c) implicitly
>> create 'somedomain.internal' if it doesn't already exist.  I'm not yet
>> clear on whether that's better or worse.  Either way it's important that
>> 'somedomain.internal' be specifically assigned to zone1 so that other
>> unrelated activities don't drop entries into that domain.
>>
>> Does that clarify?
>>
>> -Andrew
>>
>>
>> On 1/6/12 12:24 AM, Kiall Mac Innes wrote:
>>
>> Hi Andrew,
>>
>>  One question, can you clarify/expand on the following sentence from the
>> blueprint?
>>
>>   Users can create new domains or delete existing ones. When a private
>>> domain is created it can be assigned to an availability zone.
>>
>>
>>  Specifically, the assignment of a domain to an availability zone.
>>
>> Thanks,
>> Kiall
>>
>>
>> On Fri, Jan 6, 2012 at 8:21 AM, Kiall Mac Innes <kiall@xxxxxxxxxxxx>wrote:
>>
>>>  On Thu, Jan 5, 2012 at 10:05 PM, Andrew Bogott <andrewbogott@xxxxxxxxx>wrote:
>>>
>>>> I doubt that anyone but me is keeping much of an eye on this extension,
>>>> but it nonetheless feels rude for me to unilaterally modify it when it is
>>>> already a part of a release schedule.
>>>
>>>
>>>   I've been keeping an eye on it... and the additions are welcome in my
>>> view..
>>>
>>>  Kiall
>>>
>>
>>
>>
>>
>
>