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, 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, not at all (though having > that format set is VERY helpful). The key is the lexicon, the registry of > shared types/attributes and value codes that (i) get used over and over > again across many Enactor/Enforcement domains, and (ii) have > domain-specific registries for domain-only types / attributes & values. Eg. > IPv4addr will be in the all-domains, thus a (i), and AccessControlAction, > and it's value codes of Permit, Deny, Reset, SilentDrop, Log, etc., will > live in (ii) FWaaS registry only. Just examples. This way, each domain > (e.g. Neutron L2/L3, Nova-placement, FWaaS, LBaaS, StorageaaS) can define > their own attributes and publish the TLVs for them, and do so VERY quickly, > independent of the rest of the Congress domains. > > > thinrichs & glebo: Agree that domains should be empowered to build their > own ontologies. We’ve shied away building them in Congress because we don’t > believe we can succeed, too many different ontologies between problem > domains (e.g., FWaaS vs StorageaaS) as well as vertical markets (e.g., > Finance vs. Tech). E.g. maybe all the major financials get together and > develop their own ontology and publish it, based on their needs. And there > will probably need to be a base set of Types/Attributes for building policy > that get used by 80% of the varying ontology domains that would need to be > defined by Congress, to start, the specific Enactor groups can create their > own extension ontologies. > > > glebo: So we need to specify a language / protocol for these > various communities and vendors to send/receive their declarations of > policy that are expressed using a wide set of types/attributes and values > from a registry? And their would need to be allowance for vendor specific > types/attributes. > thinrichs & glebo: we need to look at this from the perspective of > insertion. The above described is a great end state. How do we get from > today to insertion to desired end-state? Once we gain traction, customers > will start wanting more, and at that point we'll have the leverage to tell > them "well we need the other vendors of services that we're supposed to > manage to utilize some standard interface/language/protocol/whatever”, then > the standardization of ontologies is very useful. > > > For some Enactor/Enforcer (we used GBP since it's logicy) figure out how > Congress and that Enactor *should* interoperate. Some questions to think > about: > > - What information do that need to exchange? > - What if someone other than Congress gives that Enactor instructions? > - What happens when the policy cannot be completely delegated to > Enactor? > - What happens when Policy is delegated to Enactor and Enactor > says, “I can’t do that today.”? > - What if a hierarchy of policy (reflecting organizational stake > holders) exists? > - What if coordination is needed between two Enactor engines? The > Enactor can’t bear sole burden in this case, can it? > > Possible path forward, that considers insertion to end-state: > > - Desired end-state for Congress —> Enactor declarations: > - single carrying protocol for bits on wire and ordering, etc. > - single “base” ontology covering the 80 of types needed, published > publicly (registry) > - multiple domain-specific ontologies for various affinity groups > published publicly (registries) > - vendor-specific ontologies published publicly (registries). We > want to keep these as small as possible, and encourage participation in > the > base or affinity group registries as much as possible. > - Note that there really are only 4 or 5 Enactor types today (although > many more are popping up very quickly) > - We want to put a stake in the ground now, ASAP, so emerging Enactor > domains and vendors can start immediately toward the end-state > - Meanwhile, we will support existing APIs (a very small number) for > existing Enactor types, but on a short term basis only, with a published > plan to deprecate the use of the multiple, and transition toward the use of > the one protocol with many ontologies. > > > discussion started #openstack-meeting-3 Oct 14, 2014 at 17:24:00 [1] > Discussion then moved to #congress 18:01:40 [2] > > [1] > *http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-10-14-17.01.log.html > <http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-10-14-17.01.log.html>* > 17:24:00 > [2] (could not find the transcript for #congress. Pointer appreciated) > 18:01:40 > > Hope it helps, > ---- > Open industry related email from > Gregory M. Lebovitz > -- ---- 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