Ordering of security group and rule application during port binding

In Openstack, security group and group rules present us a way to apply the firewall/flow rules in a platform agnostic manner (vmware, hyper-v, KVM). Typically, these security groups are created such that it caters to various categories or layers of the application stack, such as for example, Service hardening group of rules, Connection security rules, Block Rules, Allow Rules and finally Default rules. And when a Virtual Machine port is being bound on the virtual networking infrastructure on the hypervisor, these rules are applied as applicable to the port in the order in which it is received from the Controller. And the number of rules applicable to a VM port could go large in numbers depending on the environment and its regulatory policies.

And since these rules are first applied during the VM port preparation phase, it is important to complete the operation as quickly as possible. The primary proposal in this blue print is to enable the tenant provider classify the security group and respective rules as provider(a.k.a base infrastructure) rules and non provider rules depending on the state and nature of the rule and apply the provider rules (base infrastructure rules) during the VM port preparation operation and schedule the application of rest of the non provider or application/service eccentric rules post VM port preparation. This would enabled fast boot of VM instances with minimal infrastructure to be able to communicate to core infrastructure services like DHCP and obtain and apply the necessary configuration for it to be called up and running.

The non provider scheduled groups and rules would be in the mean time posted to a queue, where these rules would be applied as the post VM port binding operation.

The motivation of this requirement is that while running under a scale environment, where the number of VM boot operations are large, the application of security group and their respective rules could take considerable amount of time (we have observed it to be around 1 minute(s) in case of Hyper-V) due to which VM port binding would be delayed, and as a result the Guest OS cannot communicate to the infrastructure service to obtain some necessary configuration like IP configuration to be called successfully up and running.