paul.d.walton at gmail
Aug 13, 2012, 7:16 PM
Post #13 of 18
(878 views)
Permalink
|
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.
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?
Thanks
On Mon, Aug 13, 2012 at 8:36 PM, Jeremy Stanley <fungi [at] yuggoth> wrote:
> On 2012-08-13 19:44:18 -0500 (-0500), Narayan Desai wrote:
> [...]
> > This is probably an early example of a situation that will occur
> > repeatedly, where people are constrained one way or another,
> > either due to policy or software limitations, etc, and I think
> > that these issues really need to be considered carefully.
> [...]
>
> Agreed. My last employer (an IaaS provider grown out of a colocation
> and datacenter management company) is in a similar situation...
> customers want to blend their colocated servers and virtual machines
> from the public "cloud" platform together on the same subnets and
> VLANs. The commercial IaaS management platform the provider
> purchased made similar assumptions about the network topology--only
> one subnet to a VLAN, available IP addresses were in a contiguous
> range, et cetera.
>
> Turns out when you start bridging virtual machine networks into
> existing production server networks which weren't designed around
> those assumptions, having the additional flexibility to relieve your
> customer from needing to redesign their networks is often desirable
> even sometimes at the expense of operational scalability. And so the
> provider disabled the network management components within the
> platform for those customers and allowed them to manually manage
> their virtual machine addressing within each guest OS instead.
>
> The end result was that low-revenue colocation customers were more
> likely to convert their physical servers to hosted virtual machines
> because they could do it almost seamlessly, one at a time, keeping
> the same addressing within that network. Replacing customer-owned
> servers with IaaS virtual machines meant both more profit for the
> provider and a cost savings for the customers.
> --
> { IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
> WHOIS(STANL3-ARIN); SMTP(fungi [at] yuggoth); FINGER(fungi [at] yuggoth);
> MUD(kinrui [at] katarsis:6669); IRC(fungi [at] irc#ccl); }
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators [at] lists
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
--
Paul Walton
University of Arkansas
College of Engineering
CSCE Technical Support Team
J.B. Hunt Building, Room 440
|
