Difference between revisions of "Meetings/GroupBasedPolicy"
< Meetings
(→February 13, 2014) |
|||
Line 17: | Line 17: | ||
** The idea is to map 1:1 to Group Policy Proposal here | ** The idea is to map 1:1 to Group Policy Proposal here | ||
** https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin | ** https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin | ||
+ | * Integration with network services | ||
+ | === Future Meeting Topics === | ||
* New directions | * New directions | ||
** Network aware scheduling | ** Network aware scheduling | ||
Line 29: | Line 31: | ||
**** Does it relate to the Group-Policy abstraction? If it is just a declarative model, maybe we need an orthogonal metrics model | **** Does it relate to the Group-Policy abstraction? If it is just a declarative model, maybe we need an orthogonal metrics model | ||
**** Should we discuss this issue now? I am happy to volunteer | **** Should we discuss this issue now? I am happy to volunteer | ||
− | |||
=== January 23, 2014 === | === January 23, 2014 === |
Revision as of 17:28, 13 February 2014
Weekly meeting page for the Neutron Group Policy Sub-team occurring Thursdays at 1700 UTC on #openstack-meeting-alt
Contents
Notice
Agenda
February 13, 2014
- Action item review from a couple of weeks ago
- mestery to setup shared github for work
- s3wong to work with the rest of the PoC team to get first draft of API proposal out.
- PoC: Starting to code
- https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit?usp=sharing
- Progress and discussion on PoC coding
- OpenDaylight Application Policy Proposal
- The idea is to map 1:1 to Group Policy Proposal here
- https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin
- Integration with network services
Future Meeting Topics
- New directions
- Network aware scheduling
- Some other interactions to consider (maybe at a later meeting) - how does network aware scheduling interact with this policy based network abstraction? [Debo~]
- Use cases:
- Affinity aware placement: Given a storage end point (x), obtain an end point y or an entity z which can construct an end point y, such that distance(x,y)=small or <c, where c is a constant.
- Anti-affinity: Want to place 2 VMs as far as possible
- Bandwidth constrained placement: Want to place 2 VMs with 2 end-point groups such that the bandwidth between them <c, c=constant.
- Other use cases: hotspot aware placement etc.
- Questions
- Does it relate to the Group-Policy abstraction? If it is just a declarative model, maybe we need an orthogonal metrics model
- Should we discuss this issue now? I am happy to volunteer
- Network aware scheduling
January 23, 2014
- Action item review
- mestery to setup shared github for work
- s3wong to work with the rest of the PoC team to get first draft of API proposal out.
- PoC: Starting to code
January 16, 2014
- Action item review
- mestery s3wong banix to flesh out more details in the document and assign tasks to interested parties
- Open Discussion
January 9, 2014
- Action item review
- banix and mestery to writeup PoC in Google Doc for discussion next week.
- PoC discussion and planning
January 2, 2014
- Action item review
- s3wong to update attributes table
- s3wong to update document to note "allow over deny" in action section.
- Anything else?
December 19, 2013
- Action items from previous meeting:
- alagalah to migrate taxonomy diagram into the main document
- Possible discussion points:
- Let us see if we can get consensus for the following:
- Converged model by allowing to have a destination group and a source group to each have one or more end points
- Minimum set of actions to support: security, redirect, qos
- Conflict resolution
December 12, 2013
- Action items from previous meeting:
- banix to flesh out the tables he put in the document.
- banix and alagalah to flesh out the tables started in the document, possibly adding a diagram showing the relationship
- s3wong to update action section in document to not reflect neutron objects directly.
- sc68cal Look over action example for QoS and provide feedback
- Possible discussion points:
- Group Based Policy Taxonomy Document: https://docs.google.com/drawings/d/1HYGUSnxcx_8wkCAwE4Wtv3a30JstOBPyuknf7UnJMp0/edit?usp=sharing
- endpoints/groups
- Endpoints belonging to multiple groups? If allowed (as is the case in the current model), how to deal with conflicting policies applied to a flow?
- Policies and Actions
- Do we need to define a minimum set of actions (and the functional definitions for them) that should be supported by plugins that support this extension? Do we specify an extended list of actions that may or may not be implemented by a plugin that supports this extension?
- Do we need a mechanism to query the list of supported actions by a given plugin/implementation? Would that allow the selection of actions from a list of pre defined actions (the extended list from the previous item)? Do we need to instead provide the framework for adding any type of action that a plugin may want to define and support?
- Policy rule attributes: Do we need the new attribute "priority" for policy rules?
December 5, 2013
- Action items from previous meeting:
- banix and michsmit to flesh out the objects and attributes we want to expose in more detail in the design document
- banix and s3wong to make first pass at defining initial rules.
- Link to Icehouse Neutron Project Plan:
- https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
- Please note Group Policy work is intended for prototyping and discussion during Icehouse, implementation in "J" release
- We need to come up with:
- A more precise list of the objects/resources we are adding with attributes for each
- Relationship to existing neutron objects/resources
- Assign people action items around these and track them from week to week
Links
Previous Meeting Logs
- Available here: Neutron Group Policy Logs