[PROPOSAL] Breaking apart networkmanagerimpl...

[Alex Huang <Al...@citrix.com>]

As some of you might have noticed, I've been breaking apart code in the server package.  Code that is crucial to orchestration such as life cycle management of virtual entities and orchestrating plugins to implement the virtual entities on the physical hardware are being moved into the engine package.  Code that are related to self-service are left in the server package.

A couple of days ago, I arrived at NetworkManager.  For those of you who's seen NetworkManager, you know what a monster this is.  After some analysis, I decided I will break this into three parts.

- NetworkOrchestrator.java: This resides in engine and manages the life cycle of Network and Nic and participates in the VM life cycle orchestration.
- NetworkManagerImpl.java: This resides in server for now because majority of the code left in this file is to provide ways to find different service providers.  Eventually, that functionality will be absorbed into rulesmanagerimpl.
- IpAddressManagerImpl.java: This for now will reside in server for now.  This will contain all of the code that deals with ip address allocation.  Eventually, this functionality may be absorbed into a new interface that can be shared by the NetworkGurus.  The design of this is yet to be done but has been discussed in another thread.

I will work on this and probably complete it by early next week.  Please let me know if you have any comments.  For now, I will mostly breakup the code and do minimal change to make it all work.  The code will be in master.

--Alex

Re: [PROPOSAL] Breaking apart networkmanagerimpl...

[Daan Hoogland <da...@gmail.com>]

apart from the conflicts I will encounter, a big +1

On Fri, Aug 16, 2013 at 8:22 AM, Hugo Trippaers <hu...@trippaers.nl> wrote:
> Hey Alex,
>
> +1  This looks very good!
>
> There are some things for network manager that i wanted to do, but didn't get around to yet. Maybe some of them can be part of this change.
>
> First of all the way gurus are queries. At the moment each guru is asked to design a network and has to make its won decision whether or not it can. From an orchestration perspective it might be better that the manager queries the network provider for capabilities and the the manager decides who to give the task. I've also been thinking of a way to "link" network orchestration with host provisioning, for example sometimes properties or other config needs to be set on a host (or host nic) for a specific network provider.
>
> As for the IpAddressManager, this should be an abstract construct i think that could provide more than one type of logical addressing in the network. Think about IPv4 and IPv6 and who knows what in the future. Multiple instances of logical addressing should be able to be provisioned on a single network (dual stack IPv6,IPv4 or multiple IPv4 networks on a single broadcast domain)
>
> If i can help out in any way with this let me know. Looking forward to seeing these changes come into master.
>
> Cheers,
>
> Hugo
>
>
> On Aug 16, 2013, at 1:11 AM, Alex Huang <Al...@citrix.com> wrote:
>
>> As some of you might have noticed, I've been breaking apart code in the server package.  Code that is crucial to orchestration such as life cycle management of virtual entities and orchestrating plugins to implement the virtual entities on the physical hardware are being moved into the engine package.  Code that are related to self-service are left in the server package.
>>
>> A couple of days ago, I arrived at NetworkManager.  For those of you who's seen NetworkManager, you know what a monster this is.  After some analysis, I decided I will break this into three parts.
>>
>> - NetworkOrchestrator.java: This resides in engine and manages the life cycle of Network and Nic and participates in the VM life cycle orchestration.
>> - NetworkManagerImpl.java: This resides in server for now because majority of the code left in this file is to provide ways to find different service providers.  Eventually, that functionality will be absorbed into rulesmanagerimpl.
>> - IpAddressManagerImpl.java: This for now will reside in server for now.  This will contain all of the code that deals with ip address allocation.  Eventually, this functionality may be absorbed into a new interface that can be shared by the NetworkGurus.  The design of this is yet to be done but has been discussed in another thread.
>>
>> I will work on this and probably complete it by early next week.  Please let me know if you have any comments.  For now, I will mostly breakup the code and do minimal change to make it all work.  The code will be in master.
>>
>> --Alex
>

Re: [PROPOSAL] Breaking apart networkmanagerimpl...

[Hugo Trippaers <hu...@trippaers.nl>]

Hey Alex,

+1  This looks very good!

There are some things for network manager that i wanted to do, but didn't get around to yet. Maybe some of them can be part of this change.

First of all the way gurus are queries. At the moment each guru is asked to design a network and has to make its won decision whether or not it can. From an orchestration perspective it might be better that the manager queries the network provider for capabilities and the the manager decides who to give the task. I've also been thinking of a way to "link" network orchestration with host provisioning, for example sometimes properties or other config needs to be set on a host (or host nic) for a specific network provider.

As for the IpAddressManager, this should be an abstract construct i think that could provide more than one type of logical addressing in the network. Think about IPv4 and IPv6 and who knows what in the future. Multiple instances of logical addressing should be able to be provisioned on a single network (dual stack IPv6,IPv4 or multiple IPv4 networks on a single broadcast domain) 

If i can help out in any way with this let me know. Looking forward to seeing these changes come into master.

Cheers,

Hugo


On Aug 16, 2013, at 1:11 AM, Alex Huang <Al...@citrix.com> wrote:

> As some of you might have noticed, I've been breaking apart code in the server package.  Code that is crucial to orchestration such as life cycle management of virtual entities and orchestrating plugins to implement the virtual entities on the physical hardware are being moved into the engine package.  Code that are related to self-service are left in the server package.
> 
> A couple of days ago, I arrived at NetworkManager.  For those of you who's seen NetworkManager, you know what a monster this is.  After some analysis, I decided I will break this into three parts.
> 
> - NetworkOrchestrator.java: This resides in engine and manages the life cycle of Network and Nic and participates in the VM life cycle orchestration.
> - NetworkManagerImpl.java: This resides in server for now because majority of the code left in this file is to provide ways to find different service providers.  Eventually, that functionality will be absorbed into rulesmanagerimpl.
> - IpAddressManagerImpl.java: This for now will reside in server for now.  This will contain all of the code that deals with ip address allocation.  Eventually, this functionality may be absorbed into a new interface that can be shared by the NetworkGurus.  The design of this is yet to be done but has been discussed in another thread.
> 
> I will work on this and probably complete it by early next week.  Please let me know if you have any comments.  For now, I will mostly breakup the code and do minimal change to make it all work.  The code will be in master.
> 
> --Alex