You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Sowmya Krishnan <so...@citrix.com> on 2013/09/13 08:39:11 UTC
createVPCOffering (Was:RE: Marvin tests for VPC - why create VPC
offering?)
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?
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?
> -----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" <ra...@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:tsp@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:tsp@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
> >
> >
>
RE: createVPCOffering (Was:RE: Marvin tests for VPC - why create
VPC offering?)
Posted by Sowmya Krishnan <so...@citrix.com>.
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" <so...@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" <ra...@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:tsp@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:tsp@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
> >> >
> >> >
> >>
> >
> >
>
Re: createVPCOffering (Was:RE: Marvin tests for VPC - why create
VPC offering?)
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 9/12/13 11:39 PM, "Sowmya Krishnan" <so...@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" <ra...@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:tsp@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:tsp@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
>> >
>> >
>>
>
>