Open Stack

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