On 9/12/13 10:12 AM, "Rajesh Battala" <rajesh.batt...@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:t...@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:t...@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 > >
