Difference between revisions of "Meetings/GroupBasedPolicy"
< Meetings
m (→December 12, 2013) |
(→December 12, 2013) |
||
| Line 12: | Line 12: | ||
** sc68cal Look over action example for QoS and provide feedback | ** sc68cal Look over action example for QoS and provide feedback | ||
| − | * Possible discussion points | + | * Possible discussion points: |
** endpoints/groups | ** endpoints/groups | ||
| − | *** Endpoints belonging to multiple 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 | ** 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? |
| − | *** Policy rule | + | *** 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 === | === December 5, 2013 === | ||
Revision as of 03:09, 12 December 2013
Weekly meeting page for the Neutron Group Policy Sub-team occurring Thursdays at 1600 UTC on #openstack-meeting-alt
Agenda
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:
- 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?
- endpoints/groups
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
