Re: [openstack-dev] [policy] [congress] Protocol for Congress -- Enactor
Thanks for the summary Greg—that was great! Here’s my take. It would be great if all the services Congress interacts with implemented the same protocol and used the same policy/data language. It is worth our time to figure out what that protocol and language should be. But we should not forget that there will always be legacy services that people are unwilling or unable to change that don’t speak that protocol/language. And right now no services speak that protocol/language (since it doesn’t exist). So it’s useful today and in the future to have an adapter/wrapper framework that enables Congress to interact with other protocols and languages. That means we need to push on 2 fronts: (i) designing the ideal protocol/language and (ii) designing the adapter framework. I’ve been focused on (ii) since it’s absolutely necessary today, but if anyone would like to spearhead (i) I’d be happy to help. Tim On Nov 1, 2014, at 11:13 AM, Gregory Lebovitz gregory.i...@gmail.commailto:gregory.i...@gmail.com 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
Re: [openstack-dev] [policy] [congress] Protocol for Congress -- Enactor
anyone read this? comments? On Sat, Nov 1, 2014 at 11:13 AM, Gregory Lebovitz gregory.i...@gmail.com 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 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,
[openstack-dev] [policy] [congress] Protocol for Congress -- Enactor
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 wire,
