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? -Soheil ________________________________________ From: Murali Reddy [murali.re...@citrix.com] Sent: Wednesday, August 07, 2013 7:43 AM To: dev@cloudstack.apache.org Subject: Re: IP Address Allocation On 07/08/13 1:40 AM, "Alex Huang" <alex.hu...@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:seiz...@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.hu...@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" <seiz...@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.re...@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" <seiz...@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 [seiz...@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 >> > >> >> > > >> > > > >
