Re: IP Address Allocation
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
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
RE: IP Address Allocation
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
Re: IP Address Allocation
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
Can this be done on system VMs as well? I see that its targeted for the guests, if there is a way to abstract and apply ip address on any component - it would certainly make ACS much more flexible than it is now. -Original Message- From: Soheil Eizadi [mailto:seiz...@infoblox.com] Sent: Tuesday, August 06, 2013 2:29 PM To: dev@cloudstack.apache.org Subject: RE: IP Address Allocation We can define a third type of element for IP Address Allocation, let me look at the code and see is there is standard base class that it can extend or we have to come up with a new base class like we have for NetworkElements. -Soheil From: Chiradeep Vittal [chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 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
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
RE: IP Address Allocation
It is more a function of the networks that are managed, so any VM including SystemVMs would be managed. It would apply to both Public and Guest Networks. -Soheil From: Musayev, Ilya [imusa...@webmd.net] Sent: Tuesday, August 06, 2013 11:49 AM To: dev@cloudstack.apache.org Subject: RE: IP Address Allocation Can this be done on system VMs as well? I see that its targeted for the guests, if there is a way to abstract and apply ip address on any component - it would certainly make ACS much more flexible than it is now. -Original Message- From: Soheil Eizadi [mailto:seiz...@infoblox.com] Sent: Tuesday, August 06, 2013 2:29 PM To: dev@cloudstack.apache.org Subject: RE: IP Address Allocation We can define a third type of element for IP Address Allocation, let me look at the code and see is there is standard base class that it can extend or we have to come up with a new base class like we have for NetworkElements. -Soheil From: Chiradeep Vittal [chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 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
RE: IP Address Allocation
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
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
RE: IP Address Allocation
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
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
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
RE: IP Address Allocation
We can define a third type of element for IP Address Allocation, let me look at the code and see is there is standard base class that it can extend or we have to come up with a new base class like we have for NetworkElements. -Soheil From: Chiradeep Vittal [chiradeep.vit...@citrix.com] Sent: Tuesday, August 06, 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
RE: IP Address Allocation
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? -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
