Yes, I think so On 8/7/13 10:59 AM, "Soheil Eizadi" <seiz...@infoblox.com> 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? >-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 >>> > >> >>> > > >>> > > >> >> > >
