cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: Marvin tests for VPC - why create VPC offering?
Date Thu, 12 Sep 2013 17:24:08 GMT

On 9/12/13 10:12 AM, "Rajesh Battala" <rajesh.battala@citrix.com> wrote:

>My observations are
>1. VPC offering is to tell what are all the services can be available if
>you create tiers in the vpc.

Correct

>2. There should be some default providers for each service.(but currently
>its only VpcVR). Or set of providers for each service it can provider.
>When vpc_network_offering is created, when this network is getting
>implemented inside this vpc and those services/service providers are
>validated against what are the services/providers can be provided.


Only VPC VR/NS/Internal LB vm are supported as VPC providers


>
>I feel while creating "VPC_Offering" flexibility should be provided  at
>VPC level  such that what are the services provided and possible service
>providers.
>But currently there only only 3 possible providers one is VPcVR and
>Netscaler(only for External LB) and internalLB Provider.
>
>As there are fixed set of providers and the possible combination of VPC
>services offerings are created by default we should be using them to
>create a VPC.
>
>If user wants to create a new VPC offering it will become a copy of the
>existing VPC offering because possible VPC offerings are created by
>VPCManager.

Only Admin can create a VPC offering. And this offering doesn't become a
copy.
>
>Thanks
>Rajesh Battala
>
>-----Original Message-----
>From: Sowmya Krishnan
>Sent: Thursday, September 12, 2013 8:13 PM
>To: dev@cloudstack.apache.org
>Cc: Rajesh Battala; Venkata SwamyBabu Budumuru
>Subject: RE: Marvin tests for VPC - why create VPC offering?
>
>
>> -----Original Message-----
>> From: Prasanna Santhanam [mailto:tsp@apache.org]
>> Sent: Thursday, September 12, 2013 11:55 AM
>> To: dev@cloudstack.apache.org
>> Cc: Rajesh Battala; Venkata SwamyBabu Budumuru
>> Subject: Re: Marvin tests for VPC - why create VPC offering?
>> 
>> See inline, there seems to be a bug in the design.
>> 
>> On Thu, Sep 12, 2013 at 05:53:45AM +0000, Sowmya Krishnan wrote:
>> > > -----Original Message-----
>> > > From: Prasanna Santhanam [mailto:tsp@apache.org]
>> > > Sent: Thursday, September 12, 2013 11:07 AM
>> > > To: dev@cloudstack.apache.org
>> > > Subject: Re: Marvin tests for VPC - why create VPC offering?
>> > >
>> > > On Thu, Sep 12, 2013 at 05:15:16AM +0000, Sowmya Krishnan wrote:
>> > > > I find for most of the VPC tests we create a new VPC Offering
>> > > > which provides almost the same set of services as the "Default
>> > > > VPC
>> Offering"
>> > > > already available by default. We also have a separate function
>> > > > to create this offering, enabling it and then create a VPC using
>> > > > this offering. I wonder why do we have to create vpc offerings
>> > > > for each test suite. Also, we don't expose create VPC offering in
>>the UI.
>> > > > We do have an API for that, but I think we should just stick to
>> > > > the default ones available and then create network offerings as
>> > > > required for the test.
>> > > >
>> > >
>> > > Personally, I don't see the harm in that since any offering is
>> > > lightweight. I prefer every test create it's own set of resources
>> > > from scratch if possible. Today we don't track the trail of
>> > > resources that are
>> created by a test but we will do that.
>> > > That should help with cleanup and audit.
>> > >
>> > > Do you see a problem though?
>> >
>> > I feel It's just redundant. API is anyway tested as part of the
>> > other test - test_vpc_offerings.
>> 
>> Yeah DRY is a good reason to make the test simpler. I don't have an
>> opinion either way.
>> 
>> > Problem I encounter is, when we try to create a VPC offering, we
>> > don't have the option of choosing the service provider. So by
>> > default, all services will be provided by VPCVR.
>> 
>> The vpcOffering API only provides a service list which means it
>> shouldn't map to a provider list. If it did, then there's some magic
>>happening in the background.
>> 
>> > Now, when I try to create a VPC offering with NS as external LB
>> > provider, that's not possible through the API. I have to use the
>> > default offering only.
>> 
>> This is a bug in the design. Rajesh would be best to comment on this
>> since he included support of NS as LB provider in a VPC.
>> 
>> > So in effect, it's not going to be consistent across tests - you
>> > create an offering for one test, while use the default one for the
>> > other.
>> >
>> Agreed.
>> 
>> > Also, I am not sure - but I wonder if there was a reason why
>> > creation of VPC offering, unlike network offering isn't exposed in
>>the UI.
>> >
>> No idea. I don't actually see the distinction between vpcofferings and
>> networkofferings too. They're both defining a set of providers and a
>> set of services mapped to those providers. I questioned this many
>> times before internally and IMO, they should just be merged to make it
>>less confusing.
>
>I'll raise a separate thread to figure out why it's designed the way it
>is.
>
>> 
>> >
>> > I generally don't like sticking to anything 'Default'
>> > > and exposed only in our UI. Exercise all APIs, leave no stone
>>unturned.
>> > >
>> > > > Except for one test suite - test_vpc_offerings.py, where we are
>> > > > actually testing vpc offerings, I don't think we should be
>> > > > creating vpc offerings elsewhere. Comments?
>> > >
>> > > --
>> > > Prasanna.,
>> > >
>> > > ------------------------
>> > > Powered by BigRock.com
>> 
>> --
>> Prasanna.,
>> 
>> ------------------------
>> Powered by BigRock.com
>
>



Mime
View raw message