that came out wrong, I mean You are right! On Wed, Apr 20, 2016 at 2:59 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> 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 > -- Daan
