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
