cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: VpcProvider doesn't really seems extensible
Date Thu, 26 Sep 2013 19:48:28 GMT
On 9/26/13 11:44 AM, "Darren Shepherd" <> wrote:

>Additionally, there's a bit of discontinuity between VpcProvider,
>NetworkElement, and Network.Service for me.  Could you help me here.
>This is going to be confusing...
>Basically, for each Network.Service there is a corresponding interface
>that extends NetworkElement.  VpcProvider also extends NetworkElement
>and seems as though there should be a corresponding Network.Service
>for Vpc. If you were to add a Network.Service("Vpc") then it would
>seem logical to me that when you are doing
>you would look in vpc_service_map for the provider that provides
>"Vpc."  Now if you were to do that, what value is vpc_service_map?
>Sorry, all the provider to service to capability to
>vpc/network/offering mappings are hard to follow and keep in my head.

I can see why is it confusing. At the moment, vpc_service_map is nothing
more than a superset of services that the current VPC supports (populated
using data from VpcOffering). Any network inside the VPC can implement a
subset of these services. Like for example, Web tier in VPC would have a
Dhcp/DNS/UserData/SourceNat/Lb Service, while App tier would have only
Dhcp/DNS/UserData/SourceNat (no LB).

All the services for the VPC networks (PF/LB/StaticNat, etc) are currently
being proxied through NetworkOfferings, so for instance when you add PF
rule for the VPC network, we check ntwk_service_map to see if the PF
service is being provided by this network.

When it comes to services that can be provided just in a context of VPC -
StaticRoutes/PrivateGateway - it would make sense to introduce a separate
service like you've suggested (instead of hardcoded value). Then this
service would become a part of VPC offering (and vpc_service_map), and we
should check for its provider whenever
ateGateway calls are made.

I've filed a bug for this one:

>Another weird thing is that for applyStaticRoutes you look for a
>provider of StaticNat but then once you find it you call
>VpcProvider.applyStaticRoutes.  Why the check for StaticNat?

Thats a regression introduced with the commit
836ce6c11ad6a11db2c4564620e46bf5e17f8189. StaticRoute has nothing to do
with StaticNat provider.

>On Thu, Sep 26, 2013 at 11:02 AM, Alena Prokharchyk
><> wrote:
>> They should, Darren. "vpcservicemap" was added just in this release, and
>> only shutdown/start use it. We should fix it for
>> applyStaticRoutes/applyVpcPrivateGateway/deleteVpcPrivateGateway. I will
>> file a Jira ticket for myself to fix it.
>> -Alena.
>> From: Darren Shepherd <>
>> Reply-To: "" <>
>> Date: Thursday, September 26, 2013 10:52 AM
>> To: "" <>
>> Subject: VpcProvider doesn't really seems extensible
>> I'm looking to add a new VpcProvider, but it seems the code is
>> essentially hard coded to using the Provider.VPCVirtualRouter in
>> getVpcElements().  I could just add a setVpcElements() and inject my
>> own implementation, but I think it will run into some problems
>> (haven't tried, just reading the code)
>> Both shutdownVpc and startVpc both do the intersection of providers
>> supported by the VPC and getVpcElements(), so in theory only the
>> elements/providers applied to the VPC should get executed if you were
>> to have multiple VpcProviders.
>> applyStaticRoutes(), applyVpcPrivateGateway(), and
>> deleteVpcPrivateGateway() don't do the similar check and instead just
>> call of all getVpcElements().  Am I missing something here, shouldn't
>> those methods all check vpc_service_map?
>> Darren

View raw message