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]
> | >>> 
> 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
> | > 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to