Open Stack

On Nov 13, 2013, at 12:57 PM, Tim Hinrichs <thinrichs at 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)" <kmestery at cisco.com>
> | To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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 <s3wong at 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)
> | > <kmestery at cisco.com> wrote:
> | >> On Nov 13, 2013, at 8:58 AM, "Stein, Manuel (Manuel)"
> | >> <manuel.stein at 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:kmestery at 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 at lists.openstack.org
> | >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> | >>>> 
> | >>> _______________________________________________
> | >>> OpenStack-dev mailing list
> | >>> OpenStack-dev at lists.openstack.org
> | >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> | >> 
> | >> 
> | >> _______________________________________________
> | >> OpenStack-dev mailing list
> | >> OpenStack-dev at lists.openstack.org
> | >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> | > 
> | > _______________________________________________
> | > OpenStack-dev mailing list
> | > OpenStack-dev at lists.openstack.org
> | > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> | 
> | 
> | _______________________________________________
> | OpenStack-dev mailing list
> | OpenStack-dev at lists.openstack.org
> | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> | 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev