cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: network guru refactor proposal
Date Wed, 08 May 2013 17:13:43 GMT
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.hoogland@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" <DHoogland@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.Reddy@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" <DHoogland@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
>>>>
>>>


Mime
View raw message