The demand of a contemporary data center is agility. Traditional policy enforcement done manually is not meeting this specific need.
We can see IT vendors is favoring to use policy for their products. For example:
- Cisco - Application Centric Infrastructure
- VMware - NSX
- F5 Networks - Access Policy Manager
- Nuage - Virtualized Services Directory
- VMware - Profile-Driven Storage
One objective for OpenStack Congress is to provide an abstraction layer/As a Service with a common interface to apply policy or policies to elements in the OpenStack Infrastructure.
There are 2 specific purpose/function outlined for OpenStack Congress - governance and compliance.
Governance
The first purpose of OpenStack Congress is governance which is to use a high level declarative language to define the stat of the cloud infrastructure. Puppet is a declarative language and so is OpenStack Heat Template. Declarative mean, only the desired end state is specified without giving detail or step by step instruction as to how to attain the desired end state.
The declarative language used by OpenStack Congress is Datalog which is basically SQL with syntax that is closer to traditional/procedural programming language. Extracted from OpenStack Documentation the grammar of this declarative languages are:
<policy> ::= <rule>*
<rule> ::= <atom> COLONMINUS <literal> (COMMA <literal>)*
<literal> ::= <atom>
<literal> ::= NOT <atom>
<atom> ::= TABLENAME LPAREN <term> (COMMA <term>)* RPAREN
<term> ::= INTEGER | FLOAT | STRING | VARIABLE
<rule> ::= <atom> COLONMINUS <literal> (COMMA <literal>)*
<literal> ::= <atom>
<literal> ::= NOT <atom>
<atom> ::= TABLENAME LPAREN <term> (COMMA <term>)* RPAREN
<term> ::= INTEGER | FLOAT | STRING | VARIABLE
Compliance
Another purpose of OpenStack Congress is policy enforcement. There are 3 ways that the policy is enforced:
o
Proactively:
preventing violations before they occur
o
Reactively:
correcting violations after they occur
o
Interactively:
give administrators insight into policy and its violations, e.g. identifying
violations, explaining their causes, computing potential remediation,
simulating a sequence of changes.
Monitoring is an important element of OpenStack Congress for enforcing policy reactively and interactively. I can see that OpenStack is interacting with OpenStack Keystone, OpenStack Heat and OpenStack Mistral. Not sure how Congress is doing the monitoring function. I would think the best fit is to interact with OpenStack Ceilometer. I will have to find out and update this section.
Use Cases for Congress
If you want to look into OpenStack Congress beside reading the official OpenStack document, you must take a look at this article (part 1) and this article (part 2). As of this writing not much blog post or documentation is available for this subject.
OpenStack Document outlined a few use cases and this article by Tim Hinrichs and Scott Lowe has 4 specific use cases called for OpenStack Congress.
- Neutron Group-Based Policy
- Swift Storage Policy
- Smart Scheduler/SolverScheduler - manily for NFV
- Nova Policy-Based Scheduling Module
In the coming days I am sure there will be more use cases as this project moves to maturity and integrate into the OpenStack release. In the Juno release there is ground works done in Nova to support NFV which is again a hot topic.
Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 6: Cinder - Block Storage Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 8: Neutron - Networking Service
OpenStack Series Part 9: Horizon - a Web Based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 13: Docker in OpenStack
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack
OpenStack Series Part 18: Network Function Virtualization in OpenStack
OpenStack Series Part 19: Storage Polices for Object Storage
OpenStack Series Part 20: Group-based Policy for Neutron
Reference:
"Congress." - OpenStack. N.p., n.d. Web. 30 Oct. 2014.
No comments:
Post a Comment