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.

=== Agenda ===

=== 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
* 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

=== 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:
# 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 ===
* [https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction Blueprint]
* [https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Google Doc]

== Previous Meeting Logs ==
* Available here: [http://eavesdrop.openstack.org/meetings/networking_policy/ Neutron Group Policy Logs]

Meetings/GroupBasedPolicy

2014-02-18T23:53:29Z

Mandeep:

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.

=== Agenda ===

=== 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
* 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

=== 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:
# 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 ===
* [https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction Blueprint]
* [https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Google Doc]

== Previous Meeting Logs ==
* Available here: [http://eavesdrop.openstack.org/meetings/networking_policy/ Neutron Group Policy Logs]