I can certainly see the advantage to the current approach when you own the network, but there are so many cases where you simply can't modify the existing infrastructure.  In my case, there is simply no reason for me to manage the network.  Up until now, all I have needed was for my VM to make a DHCP request, and get a public IP.  However, I really like the idea of OpenStack, and my boss is convinced that we need to be using it.  So, unless OpenStack has the ability to do this, then I'm left with having my boss petition the network admins to give us a subnet to use.  Which may take a fair amount of time.<br>
<br>I don't like the idea of hacking a solution together, so I guess the real question is, can OpenStack currently do this or not?<br><br>Thanks<br><br><div class="gmail_quote">On Mon, Aug 13, 2012 at 8:36 PM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2012-08-13 19:44:18 -0500 (-0500), Narayan Desai wrote:<br>
[...]<br>
<div class="im">> This is probably an early example of a situation that will occur<br>
> repeatedly, where people are constrained one way or another,<br>
> either due to policy or software limitations, etc, and I think<br>
> that these issues really need to be considered carefully.<br>
</div>[...]<br>
<br>
Agreed. My last employer (an IaaS provider grown out of a colocation<br>
and datacenter management company) is in a similar situation...<br>
customers want to blend their colocated servers and virtual machines<br>
from the public "cloud" platform together on the same subnets and<br>
VLANs. The commercial IaaS management platform the provider<br>
purchased made similar assumptions about the network topology--only<br>
one subnet to a VLAN, available IP addresses were in a contiguous<br>
range, et cetera.<br>
<br>
Turns out when you start bridging virtual machine networks into<br>
existing production server networks which weren't designed around<br>
those assumptions, having the additional flexibility to relieve your<br>
customer from needing to redesign their networks is often desirable<br>
even sometimes at the expense of operational scalability. And so the<br>
provider disabled the network management components within the<br>
platform for those customers and allowed them to manually manage<br>
their virtual machine addressing within each guest OS instead.<br>
<br>
The end result was that low-revenue colocation customers were more<br>
likely to convert their physical servers to hosted virtual machines<br>
because they could do it almost seamlessly, one at a time, keeping<br>
the same addressing within that network. Replacing customer-owned<br>
servers with IaaS virtual machines meant both more profit for the<br>
provider and a cost savings for the customers.<br>
<span class="HOEnZb"><font color="#888888">--<br>
{ IRL(Jeremy_Stanley); WWW(<a href="http://fungi.yuggoth.org/" target="_blank">http://fungi.yuggoth.org/</a>); PGP(43495829);<br>
WHOIS(STANL3-ARIN); SMTP(<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>); FINGER(<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>);<br>
MUD(<a href="http://kinrui@katarsis.mudpy.org:6669" target="_blank">kinrui@katarsis.mudpy.org:6669</a>); IRC(<a href="http://fungi@irc.yuggoth.org#ccl" target="_blank">fungi@irc.yuggoth.org#ccl</a>); }<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><br>Paul Walton<br><br>University of Arkansas<br>College of Engineering<br>CSCE Technical Support Team<br>J.B. Hunt Building, Room 440<br>