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">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>