cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: IP Address Allocation
Date Wed, 07 Aug 2013 20:54:47 GMT
Yes, I think so

On 8/7/13 10:59 AM, "Soheil Eizadi" <> wrote:

>I think this is a consensus of where we are:
>We would follow the "path of NetworkElement" meaning the infrastructure
>to create a service offering, the provider concept and the use of
>agent/host infrastructure to support external providers. (The external
>NetworkGuru also uses many of the same infrastructure.) This would allow
>developing a plugin, if needed that could provide in addition to
>NetworkElement and NetworkGuru features the new External IP Address
>Allocation capability.
>The points Alex made was to complete the work in the NetworkManager and
>refactor out the IP Address Allocation out  into a unique class that can
>be called by NetworkGurus directly rather than using the NetworkManager.
>This new Class would have logic to call to the external IP Address
>Providers or use internal database to provide allocation.
>I hope I captured the essence of where we are with this?
>From: Murali Reddy []
>Sent: Wednesday, August 07, 2013 7:43 AM
>Subject: Re: IP Address Allocation
>On 07/08/13 1:40 AM, "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.
>Can we follow the path of NetworkElement which was once a single base
>class implementing all service abstractions to set of derived interfaces
>for each service (DhcpServiceProvider, LoadBalancingServiceProvider etc).
>With this approach a network element can just implement the service it
>want to provide. Current guru implementation are tightly coupled with each
>other. For e.g Midonet, Nicira guru implement the network design for their
>isolation and for the rest of the functionality they fall back on Guest
>network guru. Perhaps we can split the abstraction of network guru into
>multiple derived interface specific to each function like isolation,
>network design, ip address management. So if Infoblox guru just want to
>provide IPAM, then it can just focus on it with out the knowledge of other
>functions of network guru.
>> 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.
>>> -----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
>>> design, in that the NetworkGurus are sharing the same  ip address
>>> 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
>>> know anything about the actual network we're laying out for the end
>>> 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
>>> But I can see different NetworkGurus may want to share the same ip
>>> allocation tables/schemes so an interface for them to share that code
>>> 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
>>> 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.
>>> > >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.
>>> > >>the use case below the IP Address would be updated by the
>>> > >>NetworkElement. There is logic in getIp(), the current IP
>>> > >>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
>>> allocateGuestIP()).
>>> > >>-Soheil
>>> > >>
>>> > >
>>> > >

View raw message