Meetings/GroupBasedPolicy

Weekly meeting page for the Neutron Group Policy Sub-team occurring Thursdays at 1600 UTC on #openstack-meeting-alt

Notice

Please note the Feb. 6th meeting is cancelled. An email was sent to the openstack-dev list. We will continue with the PoC work and other items on the agenda next week on Thursday Feb. 13th.

February 13, 2014

• Action item review from a couple of weeks ago
  • mestery to setup shared github for work
    • https://github.com/mestery/neutron/tree/group_policy
  • s3wong to work with the rest of the PoC team to get first draft of API proposal out.
    • https://docs.google.com/a/mestery.com/document/d/1b_ywmSTKYW4PBjhkXREPePRgVmz-Uwv_Bb-i7Jaqsu4/edit
• 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
• 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

January 23, 2014

• Action item review
  • mestery to setup shared github for work
    • https://github.com/mestery/neutron/tree/group_policy
  • s3wong to work with the rest of the PoC team to get first draft of API proposal out.
    • https://docs.google.com/a/mestery.com/document/d/1b_ywmSTKYW4PBjhkXREPePRgVmz-Uwv_Bb-i7Jaqsu4/edit
• PoC: Starting to code
  • https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit?usp=sharing

January 16, 2014

• Action item review
  • mestery s3wong banix to flesh out more details in the document and assign tasks to interested parties
    • https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit?usp=sharing
• 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
  • https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit?usp=sharing

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:

1. Converged model by allowing to have a destination group and a source group to each have one or more end points
2. Minimum set of actions to support: security, redirect, qos
3. 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

• Blueprint
• Google Doc

Previous Meeting Logs

• Available here: Neutron Group Policy Logs