You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Nick LIVENS <ni...@nuagenetworks.net> on 2016/04/19 11:16:02 UTC
[DISCUSS] Network offerings for Isolated Networks / VPCs
Hi all,
Currently, there is no reliable way to tell whether an offering was created
for an Isolated Network or for tiers in a VPC. This is determined based on
providers. (ConfigurationManagerImpl.isOfferingForVpc)
In the UI, you have the possibility to check a flag for "VPC" during
creation of a network offering. This flag changes the list of providers per
service. However, this flag does not get sent to the backend, and is not
persisted as a result.
It is possible to create a network offering that was originally meant for
VPCs, but without using any of those providers which results in a network
offering that can't be used by VPCs because of this check. This is very
confusing for an end user, and is actually wrong.
Short term, I suggest we persist this flag "forvpc" in order to determine
whether a network offering is meant for VPCs or Isolated Networks.
Long term, we might want to rethink this implementation to a more generic
solution to make network offerings usable for both Isolated Networks and
VPCs at once, if possible.
What do you guys think?
Kind regards,
Nick Livens
Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Posted by Will Stevens <ws...@cloudops.com>.
haha, i know you well enough daan to know how to read your emails. :P
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_
On Wed, Apr 20, 2016 at 9:21 AM, Daan Hoogland <da...@gmail.com>
wrote:
> that came out wrong, I mean You are right!
>
> On Wed, Apr 20, 2016 at 2:59 PM, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > thanks Will, That is a bummer and a discouragement.
> >
> > On Wed, Apr 20, 2016 at 2:47 PM, Will Stevens <wi...@gmail.com>
> > wrote:
> >
> >> Ws: Inline
> >>
> >> On Apr 20, 2016 8:24 AM, "Daan Hoogland" <da...@gmail.com>
> wrote:
> >> >
> >> > On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens <
> williamstevens@gmail.com
> >> >
> >> > wrote:
> >> >
> >> > > I'm not sure that is a good idea. There are a LOT of implications
> with
> >> this
> >> > > idea.
> >> > >
> >> > > For example, many hardware appliances can not handle overlapping ip
> >> space
> >> > > between networks. Because of this they can't be implemented in a
> vpc,
> >> only
> >> > > isolated guest networks.
> >> > >
> >> > Why is this a problem in VPC specifically, Will? Or more to the point
> >> what
> >> > do you mean by overlap?
> >>
> >> Every vpc can use the same ip space. Think 10.1.1.1/24. When using an
> >> external hardware device with an isolated guest network, the network
> guru
> >> ensures that two networks do not have overlapping ip space, so that
> would
> >> have to get added to vpcs as well.
> >> >
> >> > Even if a vpc would contain any kind of overlap, it would still mean
> >> that
> >> > those pieces of hardware can handle only one tier. the implemetation
> of
> >> > that tier would not matter, would it?
> >> >
> >> It means you would have to have a network appliance per vpc and they
> can't
> >> be shared between multiple networks.
> >>
> >> My only point is that there are a lot of implications in this suggestion
> >> which need to be thought through. It is not going to be as easy as
> people
> >> may think. A bunch of functionality will have to be added to the vpcs
> and
> >> a
> >> lot of plugins will have to be rewritten.
> >> >
> >> > > I know there are a lot more examples like this, so it would be a
> >> dramatic
> >> >
> >> > rewrite of a lot of code to make it work.
> >> > >
> >> > Nice, let's go. (pun intended only for those that want to see it)
> >> >
> >> >
> >> >
> >> > > On Apr 20, 2016 12:49 AM, "Koushik Das" <koushik.das@accelerite.com
> >
> >> > > wrote:
> >> > >
> >> > > Another way to look at it would be to make isolated network a
> special
> >> case
> >> > > of VPC (having a single tier).
> >> > >
> >> > I would love to see that.
> >> >
> >> >
> >> >
> >> > >
> >> > > -Koushik
> >> > >
> >> > > ________________________________________
> >> > > From: Nick LIVENS <ni...@nuagenetworks.net>
> >> > > Sent: Tuesday, April 19, 2016 2:46 PM
> >> > > To: dev@cloudstack.apache.org
> >> > > Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
> >> > >
> >> > > Hi all,
> >> > >
> >> > > Currently, there is no reliable way to tell whether an offering was
> >> created
> >> > > for an Isolated Network or for tiers in a VPC. This is determined
> >> based
> >> on
> >> > > providers. (ConfigurationManagerImpl.isOfferingForVpc)
> >> > >
> >> > > In the UI, you have the possibility to check a flag for "VPC" during
> >> > > creation of a network offering. This flag changes the list of
> >> providers
> >> per
> >> > > service. However, this flag does not get sent to the backend, and is
> >> not
> >> > > persisted as a result.
> >> > >
> >> > > It is possible to create a network offering that was originally
> meant
> >> for
> >> > > VPCs, but without using any of those providers which results in a
> >> network
> >> > > offering that can't be used by VPCs because of this check. This is
> >> very
> >> > > confusing for an end user, and is actually wrong.
> >> > >
> >> > > Short term, I suggest we persist this flag "forvpc" in order to
> >> determine
> >> > > whether a network offering is meant for VPCs or Isolated Networks.
> >> > >
> >> > > Long term, we might want to rethink this implementation to a more
> >> generic
> >> > > solution to make network offerings usable for both Isolated Networks
> >> and
> >> > > VPCs at once, if possible.
> >> > >
> >> > > What do you guys think?
> >> > >
> >> > > Kind regards,
> >> > > Nick Livens
> >> > >
> >> > >
> >> > >
> >> > > DISCLAIMER
> >> > > ==========
> >> > > This e-mail may contain privileged and confidential information
> which
> >> is
> >> > > the property of Accelerite, a Persistent Systems business. It is
> >> intended
> >> > > only for the use of the individual or entity to which it is
> addressed.
> >> If
> >> > > you are not the intended recipient, you are not authorized to read,
> >> retain,
> >> > > copy, print, distribute or use this message. If you have received
> this
> >> > > communication in error, please notify the sender and delete all
> copies
> >> of
> >> > > this message. Accelerite, a Persistent Systems business does not
> >> accept
> >> any
> >> > > liability for virus infected mails.
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Daan
> >>
> >
> >
> >
> > --
> > Daan
> >
>
>
>
> --
> Daan
>
Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Posted by Daan Hoogland <da...@gmail.com>.
that came out wrong, I mean You are right!
On Wed, Apr 20, 2016 at 2:59 PM, Daan Hoogland <da...@gmail.com>
wrote:
> thanks Will, That is a bummer and a discouragement.
>
> On Wed, Apr 20, 2016 at 2:47 PM, Will Stevens <wi...@gmail.com>
> wrote:
>
>> Ws: Inline
>>
>> On Apr 20, 2016 8:24 AM, "Daan Hoogland" <da...@gmail.com> wrote:
>> >
>> > On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens <williamstevens@gmail.com
>> >
>> > wrote:
>> >
>> > > I'm not sure that is a good idea. There are a LOT of implications with
>> this
>> > > idea.
>> > >
>> > > For example, many hardware appliances can not handle overlapping ip
>> space
>> > > between networks. Because of this they can't be implemented in a vpc,
>> only
>> > > isolated guest networks.
>> > >
>> > Why is this a problem in VPC specifically, Will? Or more to the point
>> what
>> > do you mean by overlap?
>>
>> Every vpc can use the same ip space. Think 10.1.1.1/24. When using an
>> external hardware device with an isolated guest network, the network guru
>> ensures that two networks do not have overlapping ip space, so that would
>> have to get added to vpcs as well.
>> >
>> > Even if a vpc would contain any kind of overlap, it would still mean
>> that
>> > those pieces of hardware can handle only one tier. the implemetation of
>> > that tier would not matter, would it?
>> >
>> It means you would have to have a network appliance per vpc and they can't
>> be shared between multiple networks.
>>
>> My only point is that there are a lot of implications in this suggestion
>> which need to be thought through. It is not going to be as easy as people
>> may think. A bunch of functionality will have to be added to the vpcs and
>> a
>> lot of plugins will have to be rewritten.
>> >
>> > > I know there are a lot more examples like this, so it would be a
>> dramatic
>> >
>> > rewrite of a lot of code to make it work.
>> > >
>> > Nice, let's go. (pun intended only for those that want to see it)
>> >
>> >
>> >
>> > > On Apr 20, 2016 12:49 AM, "Koushik Das" <ko...@accelerite.com>
>> > > wrote:
>> > >
>> > > Another way to look at it would be to make isolated network a special
>> case
>> > > of VPC (having a single tier).
>> > >
>> > I would love to see that.
>> >
>> >
>> >
>> > >
>> > > -Koushik
>> > >
>> > > ________________________________________
>> > > From: Nick LIVENS <ni...@nuagenetworks.net>
>> > > Sent: Tuesday, April 19, 2016 2:46 PM
>> > > To: dev@cloudstack.apache.org
>> > > Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
>> > >
>> > > Hi all,
>> > >
>> > > Currently, there is no reliable way to tell whether an offering was
>> created
>> > > for an Isolated Network or for tiers in a VPC. This is determined
>> based
>> on
>> > > providers. (ConfigurationManagerImpl.isOfferingForVpc)
>> > >
>> > > In the UI, you have the possibility to check a flag for "VPC" during
>> > > creation of a network offering. This flag changes the list of
>> providers
>> per
>> > > service. However, this flag does not get sent to the backend, and is
>> not
>> > > persisted as a result.
>> > >
>> > > It is possible to create a network offering that was originally meant
>> for
>> > > VPCs, but without using any of those providers which results in a
>> network
>> > > offering that can't be used by VPCs because of this check. This is
>> very
>> > > confusing for an end user, and is actually wrong.
>> > >
>> > > Short term, I suggest we persist this flag "forvpc" in order to
>> determine
>> > > whether a network offering is meant for VPCs or Isolated Networks.
>> > >
>> > > Long term, we might want to rethink this implementation to a more
>> generic
>> > > solution to make network offerings usable for both Isolated Networks
>> and
>> > > VPCs at once, if possible.
>> > >
>> > > What do you guys think?
>> > >
>> > > Kind regards,
>> > > Nick Livens
>> > >
>> > >
>> > >
>> > > DISCLAIMER
>> > > ==========
>> > > This e-mail may contain privileged and confidential information which
>> is
>> > > the property of Accelerite, a Persistent Systems business. It is
>> intended
>> > > only for the use of the individual or entity to which it is addressed.
>> If
>> > > you are not the intended recipient, you are not authorized to read,
>> retain,
>> > > copy, print, distribute or use this message. If you have received this
>> > > communication in error, please notify the sender and delete all copies
>> of
>> > > this message. Accelerite, a Persistent Systems business does not
>> accept
>> any
>> > > liability for virus infected mails.
>> > >
>> >
>> >
>> >
>> > --
>> > Daan
>>
>
>
>
> --
> Daan
>
--
Daan
Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Posted by Daan Hoogland <da...@gmail.com>.
thanks Will, That is a bummer and a discouragement.
On Wed, Apr 20, 2016 at 2:47 PM, Will Stevens <wi...@gmail.com>
wrote:
> Ws: Inline
>
> On Apr 20, 2016 8:24 AM, "Daan Hoogland" <da...@gmail.com> wrote:
> >
> > On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens <wi...@gmail.com>
> > wrote:
> >
> > > I'm not sure that is a good idea. There are a LOT of implications with
> this
> > > idea.
> > >
> > > For example, many hardware appliances can not handle overlapping ip
> space
> > > between networks. Because of this they can't be implemented in a vpc,
> only
> > > isolated guest networks.
> > >
> > Why is this a problem in VPC specifically, Will? Or more to the point
> what
> > do you mean by overlap?
>
> Every vpc can use the same ip space. Think 10.1.1.1/24. When using an
> external hardware device with an isolated guest network, the network guru
> ensures that two networks do not have overlapping ip space, so that would
> have to get added to vpcs as well.
> >
> > Even if a vpc would contain any kind of overlap, it would still mean that
> > those pieces of hardware can handle only one tier. the implemetation of
> > that tier would not matter, would it?
> >
> It means you would have to have a network appliance per vpc and they can't
> be shared between multiple networks.
>
> My only point is that there are a lot of implications in this suggestion
> which need to be thought through. It is not going to be as easy as people
> may think. A bunch of functionality will have to be added to the vpcs and a
> lot of plugins will have to be rewritten.
> >
> > > I know there are a lot more examples like this, so it would be a
> dramatic
> >
> > rewrite of a lot of code to make it work.
> > >
> > Nice, let's go. (pun intended only for those that want to see it)
> >
> >
> >
> > > On Apr 20, 2016 12:49 AM, "Koushik Das" <ko...@accelerite.com>
> > > wrote:
> > >
> > > Another way to look at it would be to make isolated network a special
> case
> > > of VPC (having a single tier).
> > >
> > I would love to see that.
> >
> >
> >
> > >
> > > -Koushik
> > >
> > > ________________________________________
> > > From: Nick LIVENS <ni...@nuagenetworks.net>
> > > Sent: Tuesday, April 19, 2016 2:46 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
> > >
> > > Hi all,
> > >
> > > Currently, there is no reliable way to tell whether an offering was
> created
> > > for an Isolated Network or for tiers in a VPC. This is determined based
> on
> > > providers. (ConfigurationManagerImpl.isOfferingForVpc)
> > >
> > > In the UI, you have the possibility to check a flag for "VPC" during
> > > creation of a network offering. This flag changes the list of providers
> per
> > > service. However, this flag does not get sent to the backend, and is
> not
> > > persisted as a result.
> > >
> > > It is possible to create a network offering that was originally meant
> for
> > > VPCs, but without using any of those providers which results in a
> network
> > > offering that can't be used by VPCs because of this check. This is very
> > > confusing for an end user, and is actually wrong.
> > >
> > > Short term, I suggest we persist this flag "forvpc" in order to
> determine
> > > whether a network offering is meant for VPCs or Isolated Networks.
> > >
> > > Long term, we might want to rethink this implementation to a more
> generic
> > > solution to make network offerings usable for both Isolated Networks
> and
> > > VPCs at once, if possible.
> > >
> > > What do you guys think?
> > >
> > > Kind regards,
> > > Nick Livens
> > >
> > >
> > >
> > > DISCLAIMER
> > > ==========
> > > This e-mail may contain privileged and confidential information which
> is
> > > the property of Accelerite, a Persistent Systems business. It is
> intended
> > > only for the use of the individual or entity to which it is addressed.
> If
> > > you are not the intended recipient, you are not authorized to read,
> retain,
> > > copy, print, distribute or use this message. If you have received this
> > > communication in error, please notify the sender and delete all copies
> of
> > > this message. Accelerite, a Persistent Systems business does not accept
> any
> > > liability for virus infected mails.
> > >
> >
> >
> >
> > --
> > Daan
>
--
Daan
Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Posted by Will Stevens <wi...@gmail.com>.
Ws: Inline
On Apr 20, 2016 8:24 AM, "Daan Hoogland" <da...@gmail.com> wrote:
>
> On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens <wi...@gmail.com>
> wrote:
>
> > I'm not sure that is a good idea. There are a LOT of implications with
this
> > idea.
> >
> > For example, many hardware appliances can not handle overlapping ip
space
> > between networks. Because of this they can't be implemented in a vpc,
only
> > isolated guest networks.
> >
> Why is this a problem in VPC specifically, Will? Or more to the point
what
> do you mean by overlap?
Every vpc can use the same ip space. Think 10.1.1.1/24. When using an
external hardware device with an isolated guest network, the network guru
ensures that two networks do not have overlapping ip space, so that would
have to get added to vpcs as well.
>
> Even if a vpc would contain any kind of overlap, it would still mean that
> those pieces of hardware can handle only one tier. the implemetation of
> that tier would not matter, would it?
>
It means you would have to have a network appliance per vpc and they can't
be shared between multiple networks.
My only point is that there are a lot of implications in this suggestion
which need to be thought through. It is not going to be as easy as people
may think. A bunch of functionality will have to be added to the vpcs and a
lot of plugins will have to be rewritten.
>
> > I know there are a lot more examples like this, so it would be a
dramatic
>
> rewrite of a lot of code to make it work.
> >
> Nice, let's go. (pun intended only for those that want to see it)
>
>
>
> > On Apr 20, 2016 12:49 AM, "Koushik Das" <ko...@accelerite.com>
> > wrote:
> >
> > Another way to look at it would be to make isolated network a special
case
> > of VPC (having a single tier).
> >
> I would love to see that.
>
>
>
> >
> > -Koushik
> >
> > ________________________________________
> > From: Nick LIVENS <ni...@nuagenetworks.net>
> > Sent: Tuesday, April 19, 2016 2:46 PM
> > To: dev@cloudstack.apache.org
> > Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
> >
> > Hi all,
> >
> > Currently, there is no reliable way to tell whether an offering was
created
> > for an Isolated Network or for tiers in a VPC. This is determined based
on
> > providers. (ConfigurationManagerImpl.isOfferingForVpc)
> >
> > In the UI, you have the possibility to check a flag for "VPC" during
> > creation of a network offering. This flag changes the list of providers
per
> > service. However, this flag does not get sent to the backend, and is not
> > persisted as a result.
> >
> > It is possible to create a network offering that was originally meant
for
> > VPCs, but without using any of those providers which results in a
network
> > offering that can't be used by VPCs because of this check. This is very
> > confusing for an end user, and is actually wrong.
> >
> > Short term, I suggest we persist this flag "forvpc" in order to
determine
> > whether a network offering is meant for VPCs or Isolated Networks.
> >
> > Long term, we might want to rethink this implementation to a more
generic
> > solution to make network offerings usable for both Isolated Networks and
> > VPCs at once, if possible.
> >
> > What do you guys think?
> >
> > Kind regards,
> > Nick Livens
> >
> >
> >
> > DISCLAIMER
> > ==========
> > This e-mail may contain privileged and confidential information which is
> > the property of Accelerite, a Persistent Systems business. It is
intended
> > only for the use of the individual or entity to which it is addressed.
If
> > you are not the intended recipient, you are not authorized to read,
retain,
> > copy, print, distribute or use this message. If you have received this
> > communication in error, please notify the sender and delete all copies
of
> > this message. Accelerite, a Persistent Systems business does not accept
any
> > liability for virus infected mails.
> >
>
>
>
> --
> Daan
Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Posted by Daan Hoogland <da...@gmail.com>.
On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens <wi...@gmail.com>
wrote:
> I'm not sure that is a good idea. There are a LOT of implications with this
> idea.
>
> For example, many hardware appliances can not handle overlapping ip space
> between networks. Because of this they can't be implemented in a vpc, only
> isolated guest networks.
>
Why is this a problem in VPC specifically, Will? Or more to the point what
do you mean by overlap?
Even if a vpc would contain any kind of overlap, it would still mean that
those pieces of hardware can handle only one tier. the implemetation of
that tier would not matter, would it?
> I know there are a lot more examples like this, so it would be a dramatic
rewrite of a lot of code to make it work.
>
Nice, let's go. (pun intended only for those that want to see it)
> On Apr 20, 2016 12:49 AM, "Koushik Das" <ko...@accelerite.com>
> wrote:
>
> Another way to look at it would be to make isolated network a special case
> of VPC (having a single tier).
>
I would love to see that.
>
> -Koushik
>
> ________________________________________
> From: Nick LIVENS <ni...@nuagenetworks.net>
> Sent: Tuesday, April 19, 2016 2:46 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
>
> Hi all,
>
> Currently, there is no reliable way to tell whether an offering was created
> for an Isolated Network or for tiers in a VPC. This is determined based on
> providers. (ConfigurationManagerImpl.isOfferingForVpc)
>
> In the UI, you have the possibility to check a flag for "VPC" during
> creation of a network offering. This flag changes the list of providers per
> service. However, this flag does not get sent to the backend, and is not
> persisted as a result.
>
> It is possible to create a network offering that was originally meant for
> VPCs, but without using any of those providers which results in a network
> offering that can't be used by VPCs because of this check. This is very
> confusing for an end user, and is actually wrong.
>
> Short term, I suggest we persist this flag "forvpc" in order to determine
> whether a network offering is meant for VPCs or Isolated Networks.
>
> Long term, we might want to rethink this implementation to a more generic
> solution to make network offerings usable for both Isolated Networks and
> VPCs at once, if possible.
>
> What do you guys think?
>
> Kind regards,
> Nick Livens
>
>
>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>
--
Daan
Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Posted by Will Stevens <wi...@gmail.com>.
I'm not sure that is a good idea. There are a LOT of implications with this
idea.
For example, many hardware appliances can not handle overlapping ip space
between networks. Because of this they can't be implemented in a vpc, only
isolated guest networks.
I know there are a lot more examples like this, so it would be a dramatic
rewrite of a lot of code to make it work.
On Apr 20, 2016 12:49 AM, "Koushik Das" <ko...@accelerite.com> wrote:
Another way to look at it would be to make isolated network a special case
of VPC (having a single tier).
-Koushik
________________________________________
From: Nick LIVENS <ni...@nuagenetworks.net>
Sent: Tuesday, April 19, 2016 2:46 PM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
Hi all,
Currently, there is no reliable way to tell whether an offering was created
for an Isolated Network or for tiers in a VPC. This is determined based on
providers. (ConfigurationManagerImpl.isOfferingForVpc)
In the UI, you have the possibility to check a flag for "VPC" during
creation of a network offering. This flag changes the list of providers per
service. However, this flag does not get sent to the backend, and is not
persisted as a result.
It is possible to create a network offering that was originally meant for
VPCs, but without using any of those providers which results in a network
offering that can't be used by VPCs because of this check. This is very
confusing for an end user, and is actually wrong.
Short term, I suggest we persist this flag "forvpc" in order to determine
whether a network offering is meant for VPCs or Isolated Networks.
Long term, we might want to rethink this implementation to a more generic
solution to make network offerings usable for both Isolated Networks and
VPCs at once, if possible.
What do you guys think?
Kind regards,
Nick Livens
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is
the property of Accelerite, a Persistent Systems business. It is intended
only for the use of the individual or entity to which it is addressed. If
you are not the intended recipient, you are not authorized to read, retain,
copy, print, distribute or use this message. If you have received this
communication in error, please notify the sender and delete all copies of
this message. Accelerite, a Persistent Systems business does not accept any
liability for virus infected mails.
Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Posted by Koushik Das <ko...@accelerite.com>.
Another way to look at it would be to make isolated network a special case of VPC (having a single tier).
-Koushik
________________________________________
From: Nick LIVENS <ni...@nuagenetworks.net>
Sent: Tuesday, April 19, 2016 2:46 PM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Network offerings for Isolated Networks / VPCs
Hi all,
Currently, there is no reliable way to tell whether an offering was created
for an Isolated Network or for tiers in a VPC. This is determined based on
providers. (ConfigurationManagerImpl.isOfferingForVpc)
In the UI, you have the possibility to check a flag for "VPC" during
creation of a network offering. This flag changes the list of providers per
service. However, this flag does not get sent to the backend, and is not
persisted as a result.
It is possible to create a network offering that was originally meant for
VPCs, but without using any of those providers which results in a network
offering that can't be used by VPCs because of this check. This is very
confusing for an end user, and is actually wrong.
Short term, I suggest we persist this flag "forvpc" in order to determine
whether a network offering is meant for VPCs or Isolated Networks.
Long term, we might want to rethink this implementation to a more generic
solution to make network offerings usable for both Isolated Networks and
VPCs at once, if possible.
What do you guys think?
Kind regards,
Nick Livens
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.