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 CCC.
On Tue, Aug 6, 2013 at 10:10 PM, 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. 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 >> > >> >> > > >> > > >
