I would think that an ACL container is associated with a VPC and not with multiple VPCs. You could create an ACL container that makes sense for VPC #1 but not for VPC #2. If you update the container for VPC #1 you might unwittingly make a dangerous change in VPC #2.
Also, isn't the term redundant? (Access Control List Container). Should the original API be aliased to createNetworkAclItem or createNetworkAclEntry? I'd like to suggest the following API name changes * updateNetworkACL -> updateNetworkACLItem * removeNetworkACL -> deleteNetworkACLItem (not specified but mentioned) * replaceNetworkACLContainer -> replaceNetworkACLAssociation * createNetworkACL -> createNetworkACLItem * createNetworkACLContainer -> createNetworkACLList (yes redundant, but not introducing new terminology) Other comments * I don't see removeNetworkACL (deleteNetworkACLItem) being specified * createNetwork - I like this idea of being able to specify at creation time, but it should fail if the ACL service is not present * createNetworkAclItem - adding new mandatory parameters breaks the old API which cannot be done in 4.2 (needs 5.0) * createNetworkAclList - needs VPC id * deleteNetworkAclList - does this delete all the ACL items contained? Can you delete the default one? * listNetworkAclContainers - listAPIs usually have filters as parameters. You are proposing two filters -- by ACLList Id and network id. I could easily see filtering by list of network ids, by vpc id, those that contain a particular ACLItem, etc. At the very least can we rewrite the API that takes a filter as an input ? How do I know which ACLList is the default one? * How do you list the ACLItems inside an ACLList? Can you filter? List only ingress? * vpc_id should be required in all APIs? * call out the asynchronous APIs vs the synchronous APIs * Scripts - do you propose deleting and re-creating the entire chain when you update a rule? Or do you plan to surgically move around the rules as the ordering changes? * what are the contents of the default ACLList? * firewall_rules - should we create a new table instead? The upgrade can move the rules to the new table On 3/28/13 3:49 AM, "Kishan Kavala" <kishan.kav...@citrix.com> wrote: >Chandan, > User can assign any number as rule priority. But the number has to be >unique within the container. Two ACLs in the same container cannot have >same priority number. >e.g. >ACL1 - number 10 >ACL2 - number 40 >ACL3 - number 30 > >In the above example, ACL1 will have the highest priority followed by >ACL3 and ACL2. > >Priority number of the deleted rule can be re-used. Priority number can >be modified using updateNetworkACL API. > >Same NetworkACLContainer can be assigned to multiple tiers (belonging to >two different VPCs also) as long as they belong to same account. > >Regards, >Kishan > > >> -----Original Message----- >> From: Chandan Purushothama >> Sent: Thursday, 28 March 2013 5:19 AM >> To: dev@cloudstack.apache.org; Kishan Kavala >> Subject: RE: Question pertaining to the Support of ACL deny rules >> >> Kishan, >> >> Can NetworkACLContainer be used for two network tiers belonging to two >> different VPCs? >> >> Thank you, >> Chandan. >> >> -----Original Message----- >> From: Chandan Purushothama [mailto:chandan.purushoth...@citrix.com] >> Sent: Wednesday, March 27, 2013 4:37 PM >> To: dev@cloudstack.apache.org; Kishan Kavala >> Subject: RE: Question pertaining to the Support of ACL deny rules >> >> Kishan, >> >> I referred to your FS at >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+ACL+de >> ny+rules . May I know how does a user choose a rule priority number. Do >>we >> allow two rules with the same priority for any reason? Can the user >>re-use >> the priority number of the deleted rule? Can the User shuffle the >>priorities >> between rules at any time? Can more information pertaining to the rule >> number priority be mentioned in your functional specification, >> >> Thank you, >> Chandan. >> >> -----Original Message----- >> From: Chandan Purushothama [mailto:chandan.purushoth...@citrix.com] >> Sent: Monday, March 04, 2013 10:00 AM >> To: cloudstack-...@incubator.apache.org >> Cc: Kishan Kavala >> Subject: RE: Question pertaining to the Support of ACL deny rules >> >> May I know how can I use this feature in CloudStack. I mean, What do I >>need >> to do on CloudStack to specify multiple ACL deny rules? >> >> Thank you, >> Chandan. >> >> -----Original Message----- >> From: Pranav Saxena [mailto:pranav.sax...@citrix.com] >> Sent: Friday, March 01, 2013 9:35 PM >> To: cloudstack-...@incubator.apache.org >> Cc: Kishan Kavala >> Subject: RE: Question pertaining to the Support of ACL deny rules >> >> This feature is also under development and I believe , Kishan is yet to >>check >> in his code . After that we'll be adding the UI support for this and >>then you 'll >> be able to do it from the UI itself. >> >> Thanks, >> Pranav >> >> -----Original Message----- >> From: Chandan Purushothama [mailto:chandan.purushoth...@citrix.com] >> Sent: Saturday, March 02, 2013 8:39 AM >> To: cloudstack-...@incubator.apache.org >> Cc: Kishan Kavala >> Subject: Question pertaining to the Support of ACL deny rules >> >> I referred to the feature presented at >> https://issues.apache.org/jira/browse/CLOUDSTACK-763 . May I know how >> can I use this feature in CloudStack. I mean, What do I need to do on >> CloudStack to specify multiple ACL deny rules? >> >> Thank you, >> Chandan. >
