But we don't have an option to choose these service providers with createVPCOffering. It's always VPC VR. If let's say, I want to create a VPC Offering with LB as NS and say, the following services only: DNS, DHCP and SourceNat - it isn't possible.. However this mapping *is* being done internally as can be seen from vpc_offering_service_map table. So providing flexibility to create a VPC but without the ability to choose providers is confusing and perhaps limiting in a way?
> -----Original Message----- > From: Alena Prokharchyk > Sent: Thursday, September 12, 2013 10:54 PM > To: dev@cloudstack.apache.org; Sowmya Krishnan > Cc: Venkata SwamyBabu Budumuru > Subject: Re: Marvin tests for VPC - why create VPC offering? > > > 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 > > > > >
