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" <[email protected]> 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" <[email protected]> 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:[email protected]] >>> Sent: dinsdag 7 mei 2013 15:17 >>> To: [email protected] >>> Subject: Re: network guru refactor proposal >>> >>> On 07/05/13 5:23 PM, "Daan Hoogland" <[email protected]> >>>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 >>>> >>>
