You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Daan Hoogland <DH...@schubergphilis.com> on 2013/05/07 13:53:55 UTC
network guru refactor proposal
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?
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
RE: network guru refactor proposal
Posted by Daan Hoogland <DH...@schubergphilis.com>.
Hello Hiroaki,
I assume so as well, though UI must admit this is because I do not see a clear difference between 'isolation method' and 'broadcast domain type'. It is the latter I am targeting. The idea is to specify a uri for the desired net, the private gateway interface should be on and let the scheme decide what kind of broadcast domain( == isolation method???) we are planning to be in.
Regards,
-----Original Message-----
From: Hiroaki KAWAI [mailto:kawai@stratosphere.co.jp]
Sent: zaterdag 11 mei 2013 10:28
To: dev@cloudstack.apache.org
Subject: Re: network guru refactor proposal
+1 for the basic idea. Non-guest networks are not easy to
virtualize now. I assume you're talking about the isolation method in non-guest networks.
(2013/05/07 20:53), Daan Hoogland 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?
>
> 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
>
Re: network guru refactor proposal
Posted by Hiroaki KAWAI <ka...@stratosphere.co.jp>.
+1 for the basic idea. Non-guest networks are not easy to
virtualize now. I assume you're talking about the
isolation method in non-guest networks.
(2013/05/07 20:53), Daan Hoogland 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?
>
> 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
>
RE: network guru refactor proposal
Posted by Daan Hoogland <DH...@schubergphilis.com>.
Ok, got it. My picture won't be as pretty but I will put some wording there.
-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@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" <da...@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" <DH...@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" <DH...@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
>>>>
>>>
Re: network guru refactor proposal
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <da...@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" <DH...@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" <DH...@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
>>>>
>>>
Re: network guru refactor proposal
Posted by Daan Hoogland <da...@gmail.com>.
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" <DH...@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" <DH...@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
>>>
>>
Re: network guru refactor proposal
Posted by Daan Hoogland <da...@gmail.com>.
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.
>
> On 5/7/13 6:30 AM, "Daan Hoogland" <DH...@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" <DH...@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
>>>
>>
--
<http://daan.sbpad6.nl/>
Re: network guru refactor proposal
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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.
On 5/7/13 6:30 AM, "Daan Hoogland" <DH...@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" <DH...@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
>>
>
>
RE: network guru refactor proposal
Posted by Daan Hoogland <DH...@schubergphilis.com>.
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" <DH...@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
>
Re: network guru refactor proposal
Posted by Murali Reddy <Mu...@citrix.com>.
On 07/05/13 5:23 PM, "Daan Hoogland" <DH...@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
>