cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: IP Address Allocation
Date Wed, 07 Aug 2013 09:18:50 GMT
things are falling into place in slow-motion. Thanks Alex! And Soheil
for bringing this up. Let's have a hack session on this at the next

On Tue, Aug 6, 2013 at 10:10 PM, Alex Huang <> wrote:
> I'll say it's a bad design.  He he.... I designed it.  :(  We had to make some compromises
due to time constraints.
> I always intended to move the ip allocation into NetworkGurus and actually attempted
to several times but, at the end for various reasons, we just couldn't complete that task.
 I generally believe that ip address allocation can actually be done even without CloudStack's
database, for example, if it came from a master dhcp server or some IT central database. 
So an interface like IpAddressReserver to abstract that functionality would be great.
> I have to say the number of implementations for NetworkGuru grew faster than I expected.
 In one sense, it's a good sign that everyone was able to use it but then it exposes the work
that was incomplete to begin with.
> IIRC, there's basically two problems I left on NetworkGuru to be better designed.  One
is this ip address allocation.  The other problem is how to identify which set of NetworkGurus
should manage the network.  I believe that selection process should be much more transparent
to the administrator who setup the CS deployment but because at the time only VLAN isolation
was supported, I did not put that into CS.  As more and more SDN technologies come online,
it's best we design that process.  I think Hugo made some changes there but I haven't had
a chance to study how that all works now in 4.x yet.
> There are some artifacts in the code to show I was thinking about this.  For example,
Network and Nic carries the Isolation URI instead of just VLAN tag because it was intended
to be cast by the NetworkGuru and then transported to the hypervisor.  We expected anyone
who plugs into CloudStack have two places to plug into:  orchestration and actual provisioning.
 So the NetworkGuru forms the URI for isolation and then it has code at the hypervisor side
to resolve the URI to something that the hypervisor can understand.
> --Alex
>> -----Original Message-----
>> From: Soheil Eizadi []
>> Sent: Tuesday, August 6, 2013 11:54 AM
>> To:
>> Subject: RE: IP Address Allocation
>> Agree that the IP Address allocation is different than the DHCP and DNS
>> service offered by the NetworkElements.
>> The third party NetworkGurus just reference the standard NetworkManager
>> IP Address Allocation routines, either directly (e.g.
>> _networkMgr.assignPublicIpAddress()) or by calling out to the
>> GuestNetworkGuru. I would say in the current design the Network Manager
>> manages the IP Addresses not the Network Gurus. I don't think this is a bad
>> design, in that the NetworkGurus are sharing the same  ip address allocation
>> and get new features (e.g. IP reservation or VM migration) without
>> implementing new code to support them.
>> -Soheil
>> ________________________________________
>> From: Alex Huang []
>> Sent: Tuesday, August 06, 2013 11:27 AM
>> To: Chiradeep Vittal;
>> Subject: RE: IP Address Allocation
>> We can either break NetworkManager down further and say NetworkGuru
>> sets the actual parameters of the network and a new IpAddressReserver
>> sets the ip address or we can let NetworkGurus identify the
>> IpAddressReserver to use themselves.  I generally think NetworkManager
>> shouldn't care where the ip address came from because it really shouldn't
>> know anything about the actual network we're laying out for the end user.
>> That's always been left to the NetworkGurus.  If you think about it from that
>> perspective, then it's natural that ip address is allocated by the NetworkGuru.
>> But I can see different NetworkGurus may want to share the same ip address
>> allocation tables/schemes so an interface for them to share that code does
>> make sense.
>> Note there's a difference between allocating ip address and the act of
>> actually issuing the ip address and associating the ip address to a fqdn.  That
>> act is performed by the network elements.  Here we're specifically saying
>> who is responsible for figuring out the ip address that can be allocated to a
>> particular vm and works within a network.
>> --Alex
>> > -----Original Message-----
>> > From: Chiradeep Vittal
>> > Sent: Tuesday, August 6, 2013 11:14 AM
>> > To:
>> > Cc: Alex Huang
>> > Subject: Re: IP Address Allocation
>> >
>> > The way the gurus are consulted for network design and reservation
>> > makes it difficult to put this inside a guru.
>> > However it does seem odd to put this inside an element. Perhaps we
>> > need a 3rd type (IpAddressReserver?)
>> >
>> >
>> > On 8/6/13 10:42 AM, "Soheil Eizadi" <> wrote:
>> >
>> > >The NetworkGuru does a lot more than IP address allocation, e.g.
>> > >handle the Layer2/3 networking unique to the particular vendor. There
>> > >are a lot of NetworkElements providing their own NetworkGuru plugins
>> > >(Nicira, MidoNet, ...) extending the standard CloudStack Gurus.
>> > >
>> > >The feature of providing IP Address Allocation, DHCP and DNS is
>> > >common for all these networks, so rather than provide our own Guru
>> > >the proposed design would allow the above functions to coexist with
>> > >existing
>> > Gurus.
>> > >
>> > >-Soheil
>> > >________________________________________
>> > >From: Murali Reddy []
>> > >Sent: Tuesday, August 06, 2013 3:24 AM
>> > >To:
>> > >Subject: Re: IP Address Allocation
>> > >
>> > >On 06/08/13 8:59 AM, "Soheil Eizadi" <> wrote:
>> > >
>> > >>One way to achieve this behavior is to have a call out in
>> > >>prepareNic() to the NetworkElements before the call to the
>> > >>NetworkGuru allowing the NetworkElement to update the Nic Profile.
>> > >>In this use case the Network Element would suggest an IP Address. In
>> > >>the use case below the IP Address would be updated by the
>> > >>NetworkElement. There is logic in getIp(), the current IP Allocation
>> > >>that handles the case where the Nic Profile already has an IP
>> > >>Address. This needs to be updated to handle this
>> > new use case.
>> > >>The current use case assume that the VM had already been prepared
>> > once
>> > >>and has an IP Address allocated that could be reused.
>> > >>
>> > >>Does anyone see a problem with this approach?
>> > >
>> > >Purpose of Guru (to design the network) and Element (implement the
>> > >network) are different. Right way would be for your plug-in to
>> > >implement both network Guru and element and let the guru do the IP
>> > >address allocation.
>> > >
>> > >>-Soheil
>> > >>________________________________________
>> > >>From: Soheil Eizadi []
>> > >>Sent: Monday, August 05, 2013 2:35 PM
>> > >>To:
>> > >>Subject: IP Address Allocation
>> > >>
>> > >>I am trying to figure out what would be the proper way for a Plugin
>> > >>to interact with the CloudStack VM deployment and provide an
>> > >>authoritative IP Address from its database versus the local
>> > >>CloudStack database. It looks like the NetworkElements are not
>> > >>presented an opportunity to provide an IP Address and you must
>> > >>develop a NetworkGuru to provide this function. There is some
>> > >>customization of the IP Address designed into the Secondary NICs (see
>> allocateGuestIP()).
>> > >>-Soheil
>> > >>
>> > >
>> > >

View raw message