I'm with Prasanna here, the behavioral inconsistency is baffling. How would we document the differentiation at the api level?
On Wed, May 15, 2013 at 12:34 AM, Koushik Das <koushik....@citrix.com>wrote: > > > > -----Original Message----- > > From: Prasanna Santhanam [mailto:t...@apache.org] > > Sent: Wednesday, May 15, 2013 12:25 PM > > To: dev@cloudstack.apache.org > > Subject: Re: Firewall rule question > > > > On Wed, May 15, 2013 at 06:43:44AM +0000, Koushik Das wrote: > > > Prasanna, > > > > > > Interesting point. On one hand there is consistency and on the other > > > hand flexibility. Not sure if the framework should be restrictive or > > > as flexible as possible but I personally like the latter option. > > > > Sorry, don't mean to hijack this thread: > > > > But I'm not sure of the flexibility you speak of, is it given to the > tenant? If I > > was a tenant using a network offering using the VR and had programmed my > > FW rules accordingly. On upgrading my network offering to say, a PaloAlto > > FW, if all my instances suddenly become unreachable, I don't see that as > > favourable behaviour. > > > > The tenant will have flexibility to select network offering but the admin > will decide what all offerings to provide based on > Capabilities/limitations etc. Let's take the e.g. of VR and PaloAlto as > firewall service provider. Currently the framework > allows certain type of firewall rules which works with VR provider. Now > say PaloAlto is more restrictive and in order to > accommodate it more validations are added in the framework. The use case > you have mentioned above is still broken for > existing networks. > > When there are varied external devices, it's a difficult problem to arrive > at a common validation layer. It's possible that > every time a new device is integrated you may find the validations too > restrictive or too flexible. > > > -- > > Prasanna., > > > > ------------------------ > > Powered by BigRock.com > >
