Re: [openstack-dev] [policy] [congress] Protocol for Congress --> Enactor

[Gregory Lebovitz]

anyone read this? comments?

On Sat, Nov 1, 2014 at 11:13 AM, Gregory Lebovitz 
wrote:

> Summary from IRC chat 10/14/2014 on weekly meeting [1] [2]
>
> Topic:  Declarative Language for Congress —> Enactor/Enforcer
>
> Question: Shall we specify a declarative language for communicating policy
> configured in Congress to enactors / enforcement systems
>
> Hypothesis (derived at conclusion of discussion):
>  - Specify declarative protocol and framework for describing policy
> with extensible attributes/value fields described in a base ontology, with
> additional affinity ontologies, is what is needed earlier than later, to be
> able to achieve it as an end-state, before too many Enactors dive into
> one-offs.
>  - We could achieve that specification once we know the right structure
>
> Discussion:
>
>- Given the following framework:
>- Elements:
>  - Congress - The policy description point, a place where:
> - (a) policy inputs are collected
> - (b) collected policy inputs are integrated
> - (c) policy is defined
> - (d) declares policy intent to enforcing / enacting systems
> - (e) observes state of environment, noting policy violations
>  - Feeders - provides policy inputs to Congress
>  - Enactors / Enforcers - receives policy declarations from
>  Congress and enacts / enforces the policy according to its 
> capabilities
> - E.g. Nova for VM placement, Neutron for interface
> connectivity, FWaaS for access control, etc.
>
> What will the protocol be for the Congress —> Enactors / Enforcers?
>
>
> thinrichs:  we’ve we've been assuming that Congress will leverage
> whatever the Enactors (policy engines) and Feeders (and more generally
> datacenter services) that exist are using. For basic datacenter services,
> we had planned on teaching Congress what their API is and what it does. So
> there's no new protocol there—we'd just use HTTP or whatever the service
> expects. For Enactors, there are 2 pieces: (1) what policy does Congress
> push and (2) what protocol does it use to do that? We don't know the answer
> to (1) yet.  (2) is less important, I think. For (2) we could use opflex,
> for example, or create a new one. (1) is hard because the Enactors likely
> have different languages that they understand. I’m not aware of anyone
> thinking about (2). I’m not thinking about (2) b/c I don't know the answer
> to (1). The *really* hard thing to understand IMO is how these Enactors
> should cooperate (in terms of the information they exchange and the
> functionality they provide).  The bits they use to wrap the messages they
> send while cooperating is a lower-level question.
>
> jasonsb & glebo: feel the need to clarify (2)
>
> glebo: if we come out strongly with a framework spec that identifies
> a protocol for (2), and make it clear that Congress participants, including
> several data center Feeders and Enactors, are in consensus, then the other
> Feeders & Enactors will line up, in order to be useful in the modern
> deployments. Either that, or they will remain isolated from the
> new environment, or their customers will have to create custom connectors
> to the new environment. It seems that we have 2 options. (a) Congress
> learns any language spoken by Feeders and Enactors, or (b) specifies a
> single protocol for Congress —> Enactors policy declarations, including a
> highly adaptable public registry(ies) for defining the meaning of content
> blobs in those messages. For (a) Congress would get VERY bloated with an
> abstraction layer, modules, semantics and state for each different language
> it needed to speak. And there would be 10s of these languages. For (b),
> there would be one way to structure messages that were constructed of blobs
> in (e.g.) some sort of Type/Length/Value (TLV) method, where the Types and
> Values were specified in some Internet registry.
>
> jasonsb: Could we attack this from the opposite direction? E.g. if
> Congress wanted to provide an operational dashboard to show if things are
> in compliance, it would be better served by receiving the state and stats
> from the Enactors in a single protocol. Could a dashboard like this be a
> carrot to lure the various players into a single protocol for Congress —>
> Enactor?
>
> glebo & jasonsb: If Congress has to give Enactors precise instructions on
> what to do, then Congress will bloat, having to have intelligence about
> each Enactor type, and hold its state and such. If Congress can deliver
> generalized policy declarations, and the Enactor is responsible for
> interpreting it, and applying it, and gathering

[openstack-dev] [openstack] [neutron] Comments on peer reviews

[Gregory Lebovitz]

As committed last week, I've provided review comments in the draft
peer-review process [1].

Hopefully we can discuss a bit in today's 2pm PDT Neutron weekly, and more
at Summit.

Hope it helps.

[1] https://etherpad.openstack.org/p/neutron-peer-review

-- 

Open communities related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [policy] [congress] Protocol for Congress --> Enactor

[Gregory Lebovitz]

Summary from IRC chat 10/14/2014 on weekly meeting [1] [2]

Topic:  Declarative Language for Congress —> Enactor/Enforcer

Question: Shall we specify a declarative language for communicating policy
configured in Congress to enactors / enforcement systems

Hypothesis (derived at conclusion of discussion):
 - Specify declarative protocol and framework for describing policy
with extensible attributes/value fields described in a base ontology, with
additional affinity ontologies, is what is needed earlier than later, to be
able to achieve it as an end-state, before too many Enactors dive into
one-offs.
 - We could achieve that specification once we know the right structure

Discussion:

   - Given the following framework:
   - Elements:
 - Congress - The policy description point, a place where:
- (a) policy inputs are collected
- (b) collected policy inputs are integrated
- (c) policy is defined
- (d) declares policy intent to enforcing / enacting systems
- (e) observes state of environment, noting policy violations
 - Feeders - provides policy inputs to Congress
 - Enactors / Enforcers - receives policy declarations from
 Congress and enacts / enforces the policy according to its capabilities
- E.g. Nova for VM placement, Neutron for interface
connectivity, FWaaS for access control, etc.

What will the protocol be for the Congress —> Enactors / Enforcers?


thinrichs:  we’ve we've been assuming that Congress will leverage whatever
the Enactors (policy engines) and Feeders (and more generally datacenter
services) that exist are using. For basic datacenter services, we had
planned on teaching Congress what their API is and what it does. So there's
no new protocol there—we'd just use HTTP or whatever the service
expects. For Enactors, there are 2 pieces: (1) what policy does Congress
push and (2) what protocol does it use to do that? We don't know the answer
to (1) yet.  (2) is less important, I think. For (2) we could use opflex,
for example, or create a new one. (1) is hard because the Enactors likely
have different languages that they understand. I’m not aware of anyone
thinking about (2). I’m not thinking about (2) b/c I don't know the answer
to (1). The *really* hard thing to understand IMO is how these Enactors
should cooperate (in terms of the information they exchange and the
functionality they provide).  The bits they use to wrap the messages they
send while cooperating is a lower-level question.

jasonsb & glebo: feel the need to clarify (2)

glebo: if we come out strongly with a framework spec that identifies
a protocol for (2), and make it clear that Congress participants, including
several data center Feeders and Enactors, are in consensus, then the other
Feeders & Enactors will line up, in order to be useful in the modern
deployments. Either that, or they will remain isolated from the
new environment, or their customers will have to create custom connectors
to the new environment. It seems that we have 2 options. (a) Congress
learns any language spoken by Feeders and Enactors, or (b) specifies a
single protocol for Congress —> Enactors policy declarations, including a
highly adaptable public registry(ies) for defining the meaning of content
blobs in those messages. For (a) Congress would get VERY bloated with an
abstraction layer, modules, semantics and state for each different language
it needed to speak. And there would be 10s of these languages. For (b),
there would be one way to structure messages that were constructed of blobs
in (e.g.) some sort of Type/Length/Value (TLV) method, where the Types and
Values were specified in some Internet registry.

jasonsb: Could we attack this from the opposite direction? E.g. if Congress
wanted to provide an operational dashboard to show if things are in
compliance, it would be better served by receiving the state and stats from
the Enactors in a single protocol. Could a dashboard like this be a carrot
to lure the various players into a single protocol for Congress —> Enactor?

glebo & jasonsb: If Congress has to give Enactors precise instructions on
what to do, then Congress will bloat, having to have intelligence about
each Enactor type, and hold its state and such. If Congress can deliver
generalized policy declarations, and the Enactor is responsible for
interpreting it, and applying it, and gathering and analyzing the state so
that it knows how to react, then the intelligence and state that it is
specialized in knowing will live in the Enactor. A smaller Congress is
better, and this provides cleaner “layering” of the problem space overall.

thinrichs: would love to see a single (2) language, but doesn’t see that as
a practical solution in the short term, dubious that anyone will use
Congress if it only works when all of the Enactors speak the Congress
language. It’s an insertion question.

glebo:  the key is NOT the bits on the wi

[openstack-dev] [Policy][Group-based Policy] Audio stream for GBP Design Session in Paris

[Gregory Lebovitz]

Hey all,

I'm participating remotely this session. Any plan for audio stream of
Tuesday's session? I'll happily offer a GoToMeeting, if needed.

Would someone be willing to scribe discussion in #openstack-gbp channel?

-- 

Open industry-related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Policy][Group-based Policy] Audio stream for GBP Design Session in Paris

[Gregory Lebovitz]

Mandeep,
thanks a ton for setting it up. I just didn't see the email before I went
to sleep, so I didn't bother to get up for the session. Now I wish I had!

To affirm the attempt, Yi Sun opened up a google hangout for me today in
the split meeting. Even as crappy as the audio was from the mic on his
laptop, it was S helpful to have an audio stream to go along with the
ether pad.

Think that could happen for the advanced services meetup later today at
2:30pm?

Thanks again for going out of your way for me. I really appreciate it!! -
Gregory

On Tue, Nov 4, 2014 at 3:12 AM, Mandeep Dhami 
wrote:

>
> As no one was online, I closed the webex session.
>
> On Tue, Nov 4, 2014 at 10:07 AM, Mandeep Dhami 
> wrote:
>
>> Use this webex meeting for Audio streaming:
>>
>> https://cisco.webex.com/ciscosales/j.php?MTID=m210c77f6f51a6f313a7d130d19ee3e4d
>>
>>
>> Topic: GBP Design Session
>>
>> Date: Tuesday, November 4, 2014
>>
>> Time: 12:15 pm, Europe Time (Amsterdam, GMT+01:00)
>>
>> Meeting Number: 205 658 563
>>
>> Meeting Password: gbp
>>
>> On Mon, Nov 3, 2014 at 5:48 PM, Gregory Lebovitz 
>> wrote:
>>
>>> Hey all,
>>>
>>> I'm participating remotely this session. Any plan for audio stream of
>>> Tuesday's session? I'll happily offer a GoToMeeting, if needed.
>>>
>>> Would someone be willing to scribe discussion in #openstack-gbp channel?
>>>
>>> --
>>> 
>>> Open industry-related email from
>>> Gregory M. Lebovitz
>>>
>>> ___
>>> 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
>
>


-- 

Open industry-related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] rescheduling meeting

[Gregory Lebovitz]

I'm just a lurker, so pls don't optimize for me. FWIW, here's my reply, in
order of pref:

wed 1600 UTC
wed 1800 UTC
wed 1700 UTC

On Mon, Nov 3, 2014 at 11:42 PM, Doug Wiegley  wrote:

> Hi LBaaS (and others),
>
> We’ve been talking about possibly re-schedulng the LBaaS meeting to a time
> to is less crazy early for those in the US.  Alternately, we could also
> start alternating times.  For now, let’s see if we can find a slot that
> works every week.  Please respond with any time slots that you can NOT
> attend:
>
> Monday, 1600UTC
> Monday, 1700UTC
> Tuesday, 1600UTC (US pacific, 8am)
> Tuesday, 1700UTC
> Tuesday, 1800UTC
> Wednesday, 1600UTC (US pacific, 8am)
> Wednesday, 1700UTC
> Wednesday, 1800UTC
> Thursday, 1400UTC (US pacific, 6am)
>
>
> Note that many of these slots will require the approval of the
> #openstack-meeting-4 channel:
>
> https://review.openstack.org/#/c/132629/
>
> https://review.openstack.org/#/c/132630/
>
>
> Thanks,
> Doug
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Open industry-related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Reminder: No meeting this week

[Gregory Lebovitz]

Wow, that's fantastic!!
Do share a few details.

On Mon, Nov 10, 2014 at 10:22 AM, Kyle Mestery  wrote:

> Since most folks are either freshly back from traveling, in the midst
> of returning, or perhaps even with a new baby, we'll be skipping this
> week's meeting. We'll resume next week at our normally scheduled time
> [1] of 1400UTC on Tuesday.
>
> Thanks!
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Network/Meetings
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Open industry-related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

[Gregory Lebovitz]

I'd be happy to donate a Go To Meeting for the session, if desired. Not
sure if / how it is better than Google Hangout. I know we can get GTM's for
100's of participants. Not sure how many Google Hangout can support, with
something like slide sharing occuring. Anyway, let me know if you'd like me
to set one up.

On Tue, Nov 11, 2014 at 6:14 AM, Kyle Mestery  wrote:

> On Tue, Nov 11, 2014 at 8:00 AM, Gary Kotton  wrote:
> > Hi,
> > For those unable to attend will there be an option of remote access?
> > Thanks
> > Gary
> >
> We'll do our best to make this happen. I'll see if we can get a Google
> Hangout going in the room, and make sure people are on IRC.
>
> Thanks!
> Kyle
>
> > On 11/11/14, 3:04 PM, "Kyle Mestery"  wrote:
> >
> >>Hi folks:
> >>
> >>Apologies for the delay in announcing the Neutron mid-cycle, but I was
> >>confirming the details up until last night. I've captured the details
> >>on an etherpad here [1]. The dates are December 8-10
> >>(Monday-Wednesday), and it will be at the Adobe offices in Lehi, Utah,
> >>USA.
> >>
> >>We're still collecting information on hotels which should be on the
> >>etherpad later today.
> >>
> >>Thanks, looking forward to seeing everyone I missed in Paris!
> >>Kyle
> >>
> >>[1] https://etherpad.openstack.org/p/neutron-kilo-midcycle
> >>
> >>___
> >>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
>



-- 

Open industry-related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Policy][Group-based-policy] GBP Juno/Kilo next steps meeting

[Gregory Lebovitz]

+1, summary?

On Tue, Nov 11, 2014 at 3:31 AM, Igor Cardoso  wrote:

> Hello Sumit.
> Unfortunately I could not go to the round table meeting, sorry for the
> absence.
> Did you talk about traffic steering? Is there some place or etherpad with
> a summary of what was discussed/outlined?
>
> Cheers,
>
> On 5 November 2014 17:22, Sumit Naiksatam 
> wrote:
>
>> Hi,
>>
>> We had a productive design session discussion on Tuesday. However, we
>> could not get to the point where we discussed all the next steps and
>> specific action items for Juno/Kilo GBP releases. We will be meeting
>> tomorrow (Thursday) morning from in the Le Meridian to cover these.
>>
>> Time: 10 to 11 AM (before the Neutron sessions start)
>> Location: Round tables (just outside the design session rooms), Floor
>> -1, Le Meridian.
>>
>> Thanks,
>> ~Sumit.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Igor Duarte Cardoso.
> http://igordcard.com
> @igordcard 
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Open industry-related email from
Gregory M. Lebovitz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev