cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murali Reddy <Murali.Re...@citrix.com>
Subject Re: IP Address Allocation
Date Wed, 07 Aug 2013 14:43:28 GMT
On 07/08/13 1:40 AM, "Alex Huang" <Alex.Huang@citrix.com> 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.
>
>--Alex
>
>> -----Original Message-----
>> From: Soheil Eizadi [mailto:seizadi@infoblox.com]
>> Sent: Tuesday, August 6, 2013 11:54 AM
>> To: dev@cloudstack.apache.org
>> 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 [Alex.Huang@citrix.com]
>> Sent: Tuesday, August 06, 2013 11:27 AM
>> To: Chiradeep Vittal; dev@cloudstack.apache.org
>> 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: dev@cloudstack.apache.org
>> > 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" <seizadi@infoblox.com> 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 [Murali.Reddy@citrix.com]
>> > >Sent: Tuesday, August 06, 2013 3:24 AM
>> > >To: dev@cloudstack.apache.org
>> > >Subject: Re: IP Address Allocation
>> > >
>> > >On 06/08/13 8:59 AM, "Soheil Eizadi" <seizadi@infoblox.com> 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 [seizadi@infoblox.com]
>> > >>Sent: Monday, August 05, 2013 2:35 PM
>> > >>To: dev@cloudstack.apache.org
>> > >>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
>> > >>
>> > >
>> > >
>
>



Mime
View raw message