Hi,
Thanks for the replies, makes sense.
> There are large numbers of the code(both mgmt server and backend
> scripts) depends on the assumption that VR should have source nat when
> it's serving as VR for isolate network. I am afraid it would be very
> hard to remove them for now.
Understood; no technical reason for the restriction, just protecting the
user because the assumption is spread across the codebase.
> Nevertheless a good endeavor to start breaking up these dependencies.
Agreed. For example, having the virtual router VM provide services like VPN
while an SDN solution provides gateway services, Source NAT etc seems a
useful possibility to have.
Thanks,
Dave.
On Wed, Mar 13, 2013 at 11:04 AM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:
> Nevertheless a good endeavor to start breaking up these dependencies.
>
> On 3/12/13 6:55 PM, "Sheng Yang" <sh...@yasker.org> wrote:
>
> >Sorry missed it at first place...
> >
> >The reason is our logic in the VR scripts would presume that source
> >nat is enabled, if we want to enable other services. For example, if
> >you don't want to enable source nat, then we assume you only want to
> >run VR as a dhcp server, then we won't bring up eth2(normally for
> >public network) in the VR.
> >
> >The ability of defining different services for the network service
> >offering has been added at 3.0, but our VR behavior in this way since
> >we have VR(I think), so it's hard to decouple source nat with other
> >public network services. And it's also hard to decouple them in mgmt
> >server side. So I've added this change to 3.0 to make sure user didn't
> >break it though API.
> >
> >There are large numbers of the code(both mgmt server and backend
> >scripts) depends on the assumption that VR should have source nat when
> >it's serving as VR for isolate network. I am afraid it would be very
> >hard to remove them for now.
> >
> >--Sheng
> >
> >On Tue, Mar 12, 2013 at 6:46 PM, Dave Cahill <dcah...@midokura.com>
> wrote:
> >> Hi Sheng,
> >>
> >> CCing you in case this slipped through first time around in the flood of
> >> cloudstack-dev mail. :)
> >>
> >> Joe explains more below, but the core of this is if you look at
> >> VirtualRouterElement.verifyServicesCombination():
> >>
> >> if (!services.contains(Service.SourceNat)) {
> >> if (services.contains(Service.StaticNat) ||
> >> services.contains(Service.Firewall) || services.contains(Service.Lb) ||
> >> services.contains(Service.PortForwarding) ||
> >> services.contains(Service.Vpn)) {
> >> <snip>
> >> s_logger.warn("Virtual router can't enable services " +
> >> servicesList + " without source NAT service");
> >> <snip>
> >>
> >> It looks like this restriction came in with a commit of yours
> >> (46a12b378c288d27d86c9c885534f1309fee0f63), and we're not sure why the
> >> restriction exists - could you give us some background?
> >>
> >> Thanks,
> >> Dave.
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Mar 4, 2013 at 12:17 PM, Mills, Joseph <j...@midokura.jp> wrote:
> >>>
> >>> Hi Sheng,
> >>>
> >>> I was looking into possible plugin combinations with the Virtual Router
> >>> network service provider, and I saw the restriction that VPN, LB,
> >>> Firewall,
> >>> PortForwarding, and Static NAT on the VirtualRouter all require that
> >>>the
> >>> VirtualRouter also be the Source NAT service provider. I am hoping to
> >>>be
> >>> able to change this to create a network service offering that could
> >>>(for
> >>> example) use the VirtualRouter for VPN, but Midonet for everything
> >>>else.
> >>>
> >>> What was the initial reason for requiring Source NAT on the
> >>>VirtualRouter
> >>> for service like VPN or LB? Is it possible to remove these
> >>>restrictions?
> >>>
> >>> Thanks,
> >>> Joe
> >>
> >>
>
>
