Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
Kyle, Thank you for organizing this. I think the original email you sent out did not solicit any comments (except for possibly proposing a different time for the weekly meetings). So that is probably why you have not heard from anybody (including me). So we are ready to have the meeting but if the consensus is that people need more time to prepare that is fine too. I think we need to set an agenda for our meeting (similar to what you do for the ML2 calls) so we have a better idea of what we need to do during the meeting. In the proposal, we have identified new object resources. Should we start making those definitions and their relationship with other objects more precise. Just a suggestion. Thanks, Mohammad From: Kyle Mestery (kmestery) kmest...@cisco.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 11/13/2013 01:09 PM Subject:Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: Hi Kyle, So no meeting this Thursday? I am inclined to skip this week's meeting due to the fact I haven't heard many replies yet. I think a good starting point for people would be to review the BP [1] and Design Document [2] and provide feedback where appropriate. We should start to formalize what the APIs will look like at next week's meeting, and the Design Document has a first pass at this. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Thanks, - Stephen On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) manuel.st...@alcatel-lucent.com wrote: Kyle, I'm afraid your meeting vanished from the Meetings page [2] when user amotiki reworked neutron meetings ^.^ Is the meeting for Thu 1600 UTC still on? Ack, thanks for the heads up here! I have re-added the meeting. I only heard back from one other person other than yourself, so at this point I'm inclined to wait until next week to hold our first meeting unless I hear back from others. A few heads-up questions (couldn't attend the HK design summit Friday meeting): 1) In the summit session Etherpad [3], ML2 implementation mentions insertion of arbitrary metadata to hint to underlying implementation. Is that (a) the plug-ing reporting its policy-bound realization? (b) the user further specifying what should be used? (c) both? Or (d) none of that but just some arbitrary message of the day? I believe that would be (a). 2) Would policies _always_ map to the old Neutron entities? E.g. when I have policies in place, can I query related network/port, subnet/address, router elements on the API or are there no equivalents created? Would the logical topology created under the policies be exposed otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes. No, this is up to the plugin/MechanismDriver implementation. 3) Do the chain identifier in your policy rule actions match to Service Chain UUID in Service Insertion, Chaining and API [4] That's one way to look at this, yes. 4) Are you going to describe L2 services the way group policies work? I mean, why would I need a LoadBalancer or Firewall instance before I can insert it between two groups when all that load balancing/firewalling requires is nothing but a policy for group communication itself? - regardless the service instance used to carry out the service. These are things I'd like to discuss at the IRC meeting each week. The goal would be to try and come up with some actionable items we can drive towards in both Icehouse-1 and Icehouse-2. Given how close the closing of Icehouse-1 is, we need to focus on this very fast if we want to have a measurable impact in Icehouse-1. Thanks, Kyle Best, Manuel [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting [3] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron [4] https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit# -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Montag, 11. November 2013 19:41 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings Hi folks! Hope everyone had a safe trip back from Hong Kong. Friday afternoon in the Neutron sessions we discussed the Group-based Policy Abstraction BP [1]. It was decided we would try to have a weekly IRC meeting to drive out further requirements with the hope of coming up with a list of actionable tasks to begin working on by December. I've tentatively set the meeting [2] for Thursdays at 1600 UTC on the #openstack-meeting-alt IRC channel
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
On Nov 14, 2013, at 9:38 AM, Mohammad Banikazemi m...@us.ibm.com wrote: Kyle, Thank you for organizing this. I think the original email you sent out did not solicit any comments (except for possibly proposing a different time for the weekly meetings). So that is probably why you have not heard from anybody (including me). So we are ready to have the meeting but if the consensus is that people need more time to prepare that is fine too. Lets go with the time slot I've proposed, as no one objected. I think we need to set an agenda for our meeting (similar to what you do for the ML2 calls) so we have a better idea of what we need to do during the meeting. In the proposal, we have identified new object resources. Should we start making those definitions and their relationship with other objects more precise. Just a suggestion. Can you add this to the agenda [1] for next week? Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Thanks, Mohammad graycol.gifKyle Mestery (kmestery) ---11/13/2013 01:09:02 PM---On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: From: Kyle Mestery (kmestery) kmest...@cisco.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 11/13/2013 01:09 PM Subject: Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: Hi Kyle, So no meeting this Thursday? I am inclined to skip this week's meeting due to the fact I haven't heard many replies yet. I think a good starting point for people would be to review the BP [1] and Design Document [2] and provide feedback where appropriate. We should start to formalize what the APIs will look like at next week's meeting, and the Design Document has a first pass at this. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Thanks, - Stephen On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) manuel.st...@alcatel-lucent.com wrote: Kyle, I'm afraid your meeting vanished from the Meetings page [2] when user amotiki reworked neutron meetings ^.^ Is the meeting for Thu 1600 UTC still on? Ack, thanks for the heads up here! I have re-added the meeting. I only heard back from one other person other than yourself, so at this point I'm inclined to wait until next week to hold our first meeting unless I hear back from others. A few heads-up questions (couldn't attend the HK design summit Friday meeting): 1) In the summit session Etherpad [3], ML2 implementation mentions insertion of arbitrary metadata to hint to underlying implementation. Is that (a) the plug-ing reporting its policy-bound realization? (b) the user further specifying what should be used? (c) both? Or (d) none of that but just some arbitrary message of the day? I believe that would be (a). 2) Would policies _always_ map to the old Neutron entities? E.g. when I have policies in place, can I query related network/port, subnet/address, router elements on the API or are there no equivalents created? Would the logical topology created under the policies be exposed otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes. No, this is up to the plugin/MechanismDriver implementation. 3) Do the chain identifier in your policy rule actions match to Service Chain UUID in Service Insertion, Chaining and API [4] That's one way to look at this, yes. 4) Are you going to describe L2 services the way group policies work? I mean, why would I need a LoadBalancer or Firewall instance before I can insert it between two groups when all that load balancing/firewalling requires is nothing but a policy for group communication itself? - regardless the service instance used to carry out the service. These are things I'd like to discuss at the IRC meeting each week. The goal would be to try and come up with some actionable items we can drive towards in both Icehouse-1 and Icehouse-2. Given how close the closing of Icehouse-1 is, we need to focus on this very fast if we want to have a measurable impact in Icehouse-1. Thanks, Kyle Best, Manuel [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting [3] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron [4] https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit# -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Montag, 11. November 2013 19:41 To: OpenStack
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: Hi Kyle, So no meeting this Thursday? I am inclined to skip this week's meeting due to the fact I haven't heard many replies yet. I think a good starting point for people would be to review the BP [1] and Design Document [2] and provide feedback where appropriate. We should start to formalize what the APIs will look like at next week's meeting, and the Design Document has a first pass at this. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Thanks, - Stephen On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) manuel.st...@alcatel-lucent.com wrote: Kyle, I'm afraid your meeting vanished from the Meetings page [2] when user amotiki reworked neutron meetings ^.^ Is the meeting for Thu 1600 UTC still on? Ack, thanks for the heads up here! I have re-added the meeting. I only heard back from one other person other than yourself, so at this point I'm inclined to wait until next week to hold our first meeting unless I hear back from others. A few heads-up questions (couldn't attend the HK design summit Friday meeting): 1) In the summit session Etherpad [3], ML2 implementation mentions insertion of arbitrary metadata to hint to underlying implementation. Is that (a) the plug-ing reporting its policy-bound realization? (b) the user further specifying what should be used? (c) both? Or (d) none of that but just some arbitrary message of the day? I believe that would be (a). 2) Would policies _always_ map to the old Neutron entities? E.g. when I have policies in place, can I query related network/port, subnet/address, router elements on the API or are there no equivalents created? Would the logical topology created under the policies be exposed otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes. No, this is up to the plugin/MechanismDriver implementation. 3) Do the chain identifier in your policy rule actions match to Service Chain UUID in Service Insertion, Chaining and API [4] That's one way to look at this, yes. 4) Are you going to describe L2 services the way group policies work? I mean, why would I need a LoadBalancer or Firewall instance before I can insert it between two groups when all that load balancing/firewalling requires is nothing but a policy for group communication itself? - regardless the service instance used to carry out the service. These are things I'd like to discuss at the IRC meeting each week. The goal would be to try and come up with some actionable items we can drive towards in both Icehouse-1 and Icehouse-2. Given how close the closing of Icehouse-1 is, we need to focus on this very fast if we want to have a measurable impact in Icehouse-1. Thanks, Kyle Best, Manuel [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting [3] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron [4] https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit# -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Montag, 11. November 2013 19:41 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings Hi folks! Hope everyone had a safe trip back from Hong Kong. Friday afternoon in the Neutron sessions we discussed the Group-based Policy Abstraction BP [1]. It was decided we would try to have a weekly IRC meeting to drive out further requirements with the hope of coming up with a list of actionable tasks to begin working on by December. I've tentatively set the meeting [2] for Thursdays at 1600 UTC on the #openstack-meeting-alt IRC channel. If there are serious conflicts with this day and time, please speak up soon. Otherwise, we'll host our first meeting on Thursday this week. Thanks! Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-pol icy-abstraction [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_ Sub-Team_Meeting ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
I do agree with need to sometime to recovery from HK and get the meetings started next week! Edgar On 11/13/13 9:57 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com wrote: Hi Kyle, So no meeting this Thursday? I am inclined to skip this week's meeting due to the fact I haven't heard many replies yet. I think a good starting point for people would be to review the BP [1] and Design Document [2] and provide feedback where appropriate. We should start to formalize what the APIs will look like at next week's meeting, and the Design Document has a first pass at this. Thanks, Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstract ion [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIru pCD9E/edit?usp=sharing Thanks, - Stephen On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) manuel.st...@alcatel-lucent.com wrote: Kyle, I'm afraid your meeting vanished from the Meetings page [2] when user amotiki reworked neutron meetings ^.^ Is the meeting for Thu 1600 UTC still on? Ack, thanks for the heads up here! I have re-added the meeting. I only heard back from one other person other than yourself, so at this point I'm inclined to wait until next week to hold our first meeting unless I hear back from others. A few heads-up questions (couldn't attend the HK design summit Friday meeting): 1) In the summit session Etherpad [3], ML2 implementation mentions insertion of arbitrary metadata to hint to underlying implementation. Is that (a) the plug-ing reporting its policy-bound realization? (b) the user further specifying what should be used? (c) both? Or (d) none of that but just some arbitrary message of the day? I believe that would be (a). 2) Would policies _always_ map to the old Neutron entities? E.g. when I have policies in place, can I query related network/port, subnet/address, router elements on the API or are there no equivalents created? Would the logical topology created under the policies be exposed otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes. No, this is up to the plugin/MechanismDriver implementation. 3) Do the chain identifier in your policy rule actions match to Service Chain UUID in Service Insertion, Chaining and API [4] That's one way to look at this, yes. 4) Are you going to describe L2 services the way group policies work? I mean, why would I need a LoadBalancer or Firewall instance before I can insert it between two groups when all that load balancing/firewalling requires is nothing but a policy for group communication itself? - regardless the service instance used to carry out the service. These are things I'd like to discuss at the IRC meeting each week. The goal would be to try and come up with some actionable items we can drive towards in both Icehouse-1 and Icehouse-2. Given how close the closing of Icehouse-1 is, we need to focus on this very fast if we want to have a measurable impact in Icehouse-1. Thanks, Kyle Best, Manuel [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_ Meeting [3] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neu tron [4] https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh 0Wl3YF2U/edit# -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Montag, 11. November 2013 19:41 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings Hi folks! Hope everyone had a safe trip back from Hong Kong. Friday afternoon in the Neutron sessions we discussed the Group-based Policy Abstraction BP [1]. It was decided we would try to have a weekly IRC meeting to drive out further requirements with the hope of coming up with a list of actionable tasks to begin working on by December. I've tentatively set the meeting [2] for Thursdays at 1600 UTC on the #openstack-meeting-alt IRC channel. If there are serious conflicts with this day and time, please speak up soon. Otherwise, we'll host our first meeting on Thursday this week. Thanks! Kyle [1] https://blueprints.launchpad.net/neutron/+spec/group-based-pol icy-abstraction [2] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_ Sub-Team_Meeting ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
Are there plans for a concrete policy language (e.g. a grammar and semantics) to be part of the proposal, or does each plugin to Neutron supply its own policy language? I'm trying to envision how Heat would utilize the policy API. If there's a concrete policy language, then Heat can take an app template, extract the networking-relevant policy, and express that policy in the concrete language. Then whatever plugin we're using for Neutron can implement that policy in any way it sees fit as long as it obeys the policy's semantics (according to the language--the semantics Heat intended). But if there's no concrete policy language, how does Heat know which policy statements to send? It doesn't know which plugin is being used for Neutron. So it doesn't even know which strings are valid policy statements. Or are we assuming that Heat knows which plugin is being used for Neutron? Or am I missing something? Thanks, Tim - Original Message - | From: Kyle Mestery (kmestery) kmest...@cisco.com | To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org | Sent: Wednesday, November 13, 2013 9:57:54 AM | Subject: Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings | | On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com | wrote: | | Hi Kyle, | | So no meeting this Thursday? | | I am inclined to skip this week's meeting due to the fact I haven't | heard many | replies yet. I think a good starting point for people would be to | review the | BP [1] and Design Document [2] and provide feedback where | appropriate. | We should start to formalize what the APIs will look like at next | week's meeting, | and the Design Document has a first pass at this. | | Thanks, | Kyle | | [1] | https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction | [2] | https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing | | Thanks, | - Stephen | | On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) | kmest...@cisco.com wrote: | On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) | manuel.st...@alcatel-lucent.com wrote: | | Kyle, | | I'm afraid your meeting vanished from the Meetings page [2] when | user amotiki reworked neutron meetings ^.^ | Is the meeting for Thu 1600 UTC still on? | | Ack, thanks for the heads up here! I have re-added the meeting. I | only heard | back from one other person other than yourself, so at this point | I'm inclined | to wait until next week to hold our first meeting unless I hear | back from others. | | A few heads-up questions (couldn't attend the HK design summit | Friday meeting): | | 1) In the summit session Etherpad [3], ML2 implementation | mentions insertion of arbitrary metadata to hint to underlying | implementation. Is that (a) the plug-ing reporting its | policy-bound realization? (b) the user further specifying what | should be used? (c) both? Or (d) none of that but just some | arbitrary message of the day? | | I believe that would be (a). | | 2) Would policies _always_ map to the old Neutron entities? | E.g. when I have policies in place, can I query related | network/port, subnet/address, router elements on the API or are | there no equivalents created? Would the logical topology created | under the policies be exposed otherwise? for e.g. | monitoring/wysiwyg/troubleshoot purposes. | | No, this is up to the plugin/MechanismDriver implementation. | | 3) Do the chain identifier in your policy rule actions match to | Service Chain UUID in Service Insertion, Chaining and API [4] | | That's one way to look at this, yes. | | 4) Are you going to describe L2 services the way group policies | work? I mean, why would I need a LoadBalancer or Firewall | instance before I can insert it between two groups when all that | load balancing/firewalling requires is nothing but a policy for | group communication itself? - regardless the service instance | used to carry out the service. | | These are things I'd like to discuss at the IRC meeting each week. | The goal | would be to try and come up with some actionable items we can | drive towards | in both Icehouse-1 and Icehouse-2. Given how close the closing of | Icehouse-1 | is, we need to focus on this very fast if we want to have a | measurable impact in | Icehouse-1. | | Thanks, | Kyle | | | Best, Manuel | | [2] | https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting | [3] | https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron | [4] | https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit# | | -Original Message- | From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] | Sent: Montag, 11. November 2013 19:41 | To: OpenStack Development Mailing List (not for usage questions) | Subject: [openstack-dev
Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings
On Nov 13, 2013, at 12:57 PM, Tim Hinrichs thinri...@vmware.com wrote: Are there plans for a concrete policy language (e.g. a grammar and semantics) to be part of the proposal, or does each plugin to Neutron supply its own policy language? There are no concrete plans for this right now, though I suspected this would come up. I'm trying to envision how Heat would utilize the policy API. If there's a concrete policy language, then Heat can take an app template, extract the networking-relevant policy, and express that policy in the concrete language. Then whatever plugin we're using for Neutron can implement that policy in any way it sees fit as long as it obeys the policy's semantics (according to the language--the semantics Heat intended). But if there's no concrete policy language, how does Heat know which policy statements to send? It doesn't know which plugin is being used for Neutron. So it doesn't even know which strings are valid policy statements. Or are we assuming that Heat knows which plugin is being used for Neutron? Or am I missing something? The APIs alone provide a mechanism for utilizing the new constructs, but the specific policy intent is left to the underlying plugin. This would be a good thing to discuss at our meeting next week. Thanks, Kyle Thanks, Tim - Original Message - | From: Kyle Mestery (kmestery) kmest...@cisco.com | To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org | Sent: Wednesday, November 13, 2013 9:57:54 AM | Subject: Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings | | On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com | wrote: | | Hi Kyle, | | So no meeting this Thursday? | | I am inclined to skip this week's meeting due to the fact I haven't | heard many | replies yet. I think a good starting point for people would be to | review the | BP [1] and Design Document [2] and provide feedback where | appropriate. | We should start to formalize what the APIs will look like at next | week's meeting, | and the Design Document has a first pass at this. | | Thanks, | Kyle | | [1] | https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction | [2] | https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing | | Thanks, | - Stephen | | On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery) | kmest...@cisco.com wrote: | On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel) | manuel.st...@alcatel-lucent.com wrote: | | Kyle, | | I'm afraid your meeting vanished from the Meetings page [2] when | user amotiki reworked neutron meetings ^.^ | Is the meeting for Thu 1600 UTC still on? | | Ack, thanks for the heads up here! I have re-added the meeting. I | only heard | back from one other person other than yourself, so at this point | I'm inclined | to wait until next week to hold our first meeting unless I hear | back from others. | | A few heads-up questions (couldn't attend the HK design summit | Friday meeting): | | 1) In the summit session Etherpad [3], ML2 implementation | mentions insertion of arbitrary metadata to hint to underlying | implementation. Is that (a) the plug-ing reporting its | policy-bound realization? (b) the user further specifying what | should be used? (c) both? Or (d) none of that but just some | arbitrary message of the day? | | I believe that would be (a). | | 2) Would policies _always_ map to the old Neutron entities? | E.g. when I have policies in place, can I query related | network/port, subnet/address, router elements on the API or are | there no equivalents created? Would the logical topology created | under the policies be exposed otherwise? for e.g. | monitoring/wysiwyg/troubleshoot purposes. | | No, this is up to the plugin/MechanismDriver implementation. | | 3) Do the chain identifier in your policy rule actions match to | Service Chain UUID in Service Insertion, Chaining and API [4] | | That's one way to look at this, yes. | | 4) Are you going to describe L2 services the way group policies | work? I mean, why would I need a LoadBalancer or Firewall | instance before I can insert it between two groups when all that | load balancing/firewalling requires is nothing but a policy for | group communication itself? - regardless the service instance | used to carry out the service. | | These are things I'd like to discuss at the IRC meeting each week. | The goal | would be to try and come up with some actionable items we can | drive towards | in both Icehouse-1 and Icehouse-2. Given how close the closing of | Icehouse-1 | is, we need to focus on this very fast if we want to have a | measurable impact in | Icehouse-1. | | Thanks, | Kyle | | | Best, Manuel | | [2
