357fbd4d83
1. Each controller will have a polling thread which will query Nova API every 1 min to get the list of nova VMs and use that to build up/update the DB cache. 2. There are 2 types of udpates, one is the full udpate which will query all the nova VMs while the other is the incremental update which will only query the new/updated VMs in the past 10 mins. We will do incremental udpate every 1 min then a full update every 10 mins. 3. Inside get_gbp_details(), it will then query this DB cache instead for the VM name. If its not there, it will just use the device_id instead for the time being to speed up the performance. 4. Then when there are added/updated VMs, the polling thread will call notify_port_update() to trigger an update to the corresponding EP file. 5. This patch can also take care of the VM name change case. 6. The VMNameUpdate DB table is used to corodinate which controller's polling thread should be in charge of the periodical updates. So at any given time, there will be only one active polling thread doing the updates. Change-Id: I820d8078825dbc1e801b7e87752138e9509369d8 |
||
|---|---|---|
| devstack | ||
| doc/source | ||
| etc | ||
| gbpservice | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| TESTING.rst | ||
| babel.cfg | ||
| openstack-common.conf | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Group Based Policy (GBP) provides declarative abstractions for achieving scalable intent-based infrastructure automation.
GBP complements the OpenStack networking model with the notion of policies that can be applied between groups of network endpoints. As users look beyond basic connectivity, richer network services with diverse implementations and network properties are naturally expressed as policies. Examples include service chaining, QoS, path properties, access control, etc.
GBP allows application administrators to express their networking requirements using a Group and a Policy Rules-Set abstraction. The specifics of policy rendering are left to the underlying pluggable policy driver.
GBP model also supports a redirect operation that makes it easy to abstract and consume complex network service chains and graphs.
Checkout the GBP wiki page for more detailed information: <https://wiki.openstack.org/wiki/GroupBasedPolicy>
The latest code is available at: <http://git.openstack.org/cgit/openstack/group-based-policy>.
GBP project management (blueprints, bugs) is done via Launchpad: <https://launchpad.net/group-based-policy>
For help using or hacking on GBP, you can send mail to <mailto:openstack-dev@lists.openstack.org>.
Acronyms used in code for brevity:
- PT: Policy Target
- PTG: Policy Target Group
- PR: Policy Rule
- PRS: Policy Rule Set
- L2P: L2 Policy
- L3P: L3 Policy
- NSP: Network Service Policy
- EP: External Policy
- ES: External Segment
- SC: Service Chain
- SP: Service Profile