Ok, got it. My picture won't be as pretty but I will put some wording there.
-----Original Message----- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: woensdag 8 mei 2013 19:14 To: dev@cloudstack.apache.org Subject: Re: network guru refactor proposal See for example the extensive documentation for 4.2 https://cwiki.apache.org/confluence/x/dzXVAQ The PVLAN one is a good one https://cwiki.apache.org/confluence/x/c17VAQ On 5/7/13 1:25 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >On 2013/5/7 19:18 , Chiradeep Vittal wrote: >> For a major change, I'd expect a functional specification. It is >>still not clear to me what is "nicira hosted private gateways". I can >>guess, but without a concrete document, it is hard to see where you >>are going with this. >There is a jira ticket for it. Is this what you mean? Or do you want a >word-up with pre- and post conditions? The functional change is not >really big in comparison with the code change so a document seems >overkill to me but I am biased, so open to suggestions. > >in short: the user question is to be able to hook the newly to be >created vpc private gateway to an existing external network, in this >case a logical switch in nicira. > >regards, >> >> On 5/7/13 6:30 AM, "Daan Hoogland" <dhoogl...@schubergphilis.com> wrote: >> >>> The main objective is to have a nicira based private network guru to >>>use for vpsgateways. I want to abstract common code with the >>>'generic' vlan based private network but also abstract out >>>commonalities that might be shared with the guest networks. >>>canHandle could be generalized and called by all classes, though it >>>has another footprint now in the guest networks then it has in >>>PrivateNetworkGuru. >>> >>> Alternatively I will copy code from NiciraNvpGuestNetworkGuru and >>>PrivateNetworkGuru to a new class and later refactor it, which is not >>>my favorite way to go. >>> >>> I must admit that including network gurus that do not support any >>>extensions in the hierarchy is an esthetic touch if no code is shared. >>>I >>> will refrain if maintainability issues can be expected. >>> >>> Regards, >>> >>> -----Original Message----- >>> From: Murali Reddy [mailto:murali.re...@citrix.com] >>> Sent: dinsdag 7 mei 2013 15:17 >>> To: dev@cloudstack.apache.org >>> Subject: Re: network guru refactor proposal >>> >>> On 07/05/13 5:23 PM, "Daan Hoogland" <dhoogl...@schubergphilis.com> >>>wrote: >>> >>>> LS, >>>> >>>> I want to refactor the network guru hierarchy to put som >>>> functionality in abstract base classes. This will come down to >>>> extending the hierarchy for guest networks to include all gurus. >>>> Are there any thoughts or gotchas to share? >>> GuestNetworkGuru in some sense already acting as abstract base >>>class, except for the fact that it is tied to 'Vlan' isolation. We >>>can generalise the 'GuestNetworkGuru' and let the isolation type >>>specific network design aspects to concrete classes. Other gurus >>>(direct, pod >>> based) for guest networks does not have any extensions at this point >>>and does not overlap much with GuestNetworkGuru, so they may remain >>>as is. >>> Are there any specify observations that you think refactor will >>>address? >>> >>>> This would be the second part of a three stage strategy I have to >>>> support creating a nicira hosted private gateway for vpcs. >>>> The first one is making sure vlans are specified as uri throughout >>>> the system. I will be submitting a patch for review for this part soon. >>>> The last part will be creating a guru based on Hugo's >>>> NiciraNvpGuestNetworkGuru. >>>> >>>> Any comment is appreciated, >>>> Daan Hoogland >>>> >>>
