thanks Will, That is a bummer and a discouragement. On Wed, Apr 20, 2016 at 2:47 PM, Will Stevens <williamstev...@gmail.com> wrote:
> Ws: Inline > > On Apr 20, 2016 8:24 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: > > > > On Wed, Apr 20, 2016 at 1:26 PM, Will Stevens <williamstev...@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....@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.liv...@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
