Hi Andrew,<div><br></div><div>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.</div>
<div><br></div><div>E Hammond from Alestic probably explains it better :)</div><div><div><br></div><div>> 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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>I hope this explains it a tad better :)</div><div><br>Thanks,<br>Kiall<br>
<br><br><div class="gmail_quote">On Fri, Jan 6, 2012 at 9:26 PM, Andrew Bogott <span dir="ltr"><<a href="mailto:abogott@wikimedia.org">abogott@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Kiall --<br>
<br>
So far I haven't accounted for a special case like that. Can you
explain the exact scenario you're worried about?<br>
<br>
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?<br>
<br>
-Andrew<br>
<br>
<br>
On 1/6/12 11:57 AM, Kiall Mac Innes wrote:
<blockquote type="cite">Hi Andrew,
<div><br>
</div>
<div>Yes - That makes sense. Thanks!</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>This would (in a roundabout way) resolve the issue of being
unable to access the local instance via its floating IP..</div>
<div><br>
</div>
<div>Thanks,<br>
Kiall<br>
<br>
<br>
<div class="gmail_quote">On Fri, Jan 6, 2012 at 7:47 PM, Andrew
Bogott <span dir="ltr"><<a href="mailto:abogott@wikimedia.org" target="_blank">abogott@wikimedia.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Kiall --<br>
<br>
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.<br>
<br>
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.<br>
<br>
So, for example, in availability zone1, you would:<br>
<br>
a) Create a DNS domain called 'somedomain.internal' and
assign it to zone1<br>
b) Set FLAGS.instance_dns_domain for zone1 to
'somedomain.internal'<br>
c) After which, a new instance in zone1 would be
automatically assigned a DNS name e.g.
'instance1.somedomain.internal'.<br>
<br>
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.<br>
<br>
Does that clarify?<br>
<br>
-Andrew<br>
<br>
<br>
On 1/6/12 12:24 AM, Kiall Mac Innes wrote:
<blockquote type="cite">Hi Andrew,
<div><br>
</div>
<div>One question, can you clarify/expand on the
following sentence from the blueprint?</div>
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Users
can create new domains or delete existing ones. When
a private domain is created it can be assigned to an
availability zone.</blockquote>
<div><br>
</div>
<div>Specifically, the assignment of a domain to an
availability zone. </div>
<br>
Thanks,<br>
Kiall<br>
<br>
<br>
<div class="gmail_quote">On Fri, Jan 6, 2012 at 8:21
AM, Kiall Mac Innes <span dir="ltr"><<a href="mailto:kiall@managedit.ie" target="_blank">kiall@managedit.ie</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>On Thu, Jan 5, 2012 at 10:05 PM, Andrew
Bogott <span dir="ltr"><<a href="mailto:andrewbogott@gmail.com" target="_blank">andrewbogott@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.</blockquote>
<div><br>
</div>
</div>
<div> I've been keeping an eye on it... and the
additions are welcome in my view..</div>
<span><font color="#888888">
<div><br>
</div>
<div>Kiall</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div>