Jump to: navigation, search


< Meetings
Revision as of 18:40, 27 February 2014 by Cgoncalves (talk | contribs)

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

Integration Repo

Temporary integration repo: https://github.com/noironetworks/neutron-group-policy

Integration repo usage:

1. We will create a feature branch for any feature that requires collaboration between us before we can push it upstream. The API branch is for API changes, for a different feature, we will should create a new branch.

2. To work on that specific feature, we should take personal development branch from that branch. And when ready, we should create a pull request for the feature branch.

3. Once the feature had the multiple updates integrated and ready for upstream, we will push upstream from that feature branch

Current Branches

API branch https://github.com/noironetworks/neutron-group-policy/tree/api

Mailing List

Please use [neutron] [policy] in the subject line of your emails to the OpenStack Development Mailing List <openstack-dev@lists.openstack.org> when possible.

February 27, 2014

  • Action items from last meeting
    • banix to publish DB code to shared github for review
  • Plugin structure
  • Data Model
  • Policy API
  • Client library
  • Open issues

February 20, 2014

  • Action items
    • mestery to change this meeting to be at 1900UTC Thursdays on #openstack-meeting-alt going forward
    • SumitNaiksatam to update meeting page with temporary shared github address
    • mandeep to update wiki with collaboration instructions
  • PoC Status
  • Discussion on integration with network services

February 13, 2014

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

January 23, 2014

January 16, 2014

January 9, 2014

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:
  • 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


Previous Meeting Logs