cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] Network offerings for Isolated Networks / VPCs
Date Wed, 20 Apr 2016 13:21:16 GMT
that came out wrong, I mean You are right!

On Wed, Apr 20, 2016 at 2:59 PM, Daan Hoogland <daan.hoogland@gmail.com>
wrote:

> thanks Will, That is a bummer and a discouragement.
>
> On Wed, Apr 20, 2016 at 2:47 PM, Will Stevens <williamstevens@gmail.com>
> wrote:
>
>> 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
>>
>
>
>
> --
> Daan
>



-- 
Daan

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