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