Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Thu, 24 Oct 2013 10:21:02 +0000 (UTC)
From: "Abhinandan Prateek (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12674964.1382421330555.958.1382610062827@arcas>
In-Reply-To: <JIRA.12674964.1382421330555@arcas>
References: <JIRA.12674964.1382421330555@arcas>
Subject: [jira] [Updated] (CLOUDSTACK-4918) VR can not be LB service
 provider without requiring to be source nat service provider as well.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CLOUDSTACK-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abhinandan Prateek updated CLOUDSTACK-4918:
-------------------------------------------

    Assignee: Murali Reddy

> VR can not be LB service provider without requiring to be source nat service provider as well.
> ----------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-4918
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4918
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Network Controller
>    Affects Versions: 4.2.0, 4.3.0
>            Reporter: Murali Reddy
>            Assignee: Murali Reddy
>             Fix For: Future
>
>
> VR currently can not be LB service provider without requiring to be source nat service provider as well. It fails with error "Provider VirtualRouter doesn't support services combination: [Dns, Dhcp, Lb] ". This is a restriction made sense prior to network-as-a-service (earlier releases to 3.0). VR at that time was sole provider of all the services. Now with ability to choose different service providers for different services, its valid service and provider combination to have source nat service provided by different provider than VR, and LB service is provided by VR.  Currently this combination is prevented while creating network offering.
> This bug is to relax this restriction.
> Its possible that, this may be non-trivial bug to fix. VR implicitly acquires a public IP for source nat and created public NIC on the VR by default. In the above mentioned case, only on acquiring IP for LB, Ip is associated with the VR so requiring that public interface is created on the VR.


--
This message was sent by Atlassian JIRA
(v6.1#6144)