cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <williamstev...@gmail.com>
Subject Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Date Wed, 20 Apr 2016 12:47:21 GMT
Ws: Inline

On Apr 20, 2016 8:24 AM, "Daan Hoogland" <daan.hoogland@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 <nick.livens@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message