> -----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
