Filed https://issues.apache.org/jira/browse/CLOUDSTACK-4679 for the API issue.
> -----Original Message----- > From: Alena Prokharchyk > Sent: Friday, September 13, 2013 9:58 PM > To: Sowmya Krishnan; dev@cloudstack.apache.org > Cc: Venkata SwamyBabu Budumuru > Subject: Re: createVPCOffering (Was:RE: Marvin tests for VPC - why create VPC > offering?) > > On 9/12/13 11:39 PM, "Sowmya Krishnan" <sowmya.krish...@citrix.com> > wrote: > > >But we don't have an option to choose service providers with > >createVPCOffering. It's always VPC VR for all services. If let's say, I > >want to create a VPC Offering with LB as Netscaler and say, the > >following services only: DNS, DHCP and SourceNat - it isn¹t possible from the > API.. > >However this mapping *is* being done internally as can be seen from > >vpc_offering_service_map table. > >So providing flexibility to create a VPC with chosen set to services > >but without the ability to choose providers is confusing and perhaps > >limiting in a way? > > Sounds like an api bug to me. We should allow having NS and internal LB as a > provider. Please file it. > > > > >On the other hand, I am wondering what is the use case for exposing > >createVPCOffering at all? Can we not stick to the default offerings of > >VPC already provided? > > The original intent for introducing VPC offering was - push all the > services/providers from network offerings of the tiers to the VPC offering, > and > make it serve the services for VPC just like network offering does for > network. > Due to lack of time, it was easier back then to proxy services for VPC tiers > via > network offering of the tier using existing implementation of > NetworkAsAService. In the future all services/providers should be defined on > the > VPC level instead of network level. By then, createVPCOffering functionality > shouldn't be exposed in the UI. > > > > > >> -----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 > >> > > >> > > >> > > > > >
