 All right, I think we're ready to go here. I'll kick it off. I'm Mike Cohen from Cisco. And today, a number of us are going to be talking about group-based policy for OpenStack. You'll start out. I'll be presenting vision. Then we'll be talking about the group-based policy model and the architecture, and then giving you guys a quick demo. So let me start off with a basic premise. IT exists to run applications. And it needs to do so in a way that's scalable, easy use, reliable, and fast. So what do we do? Well, we build automation. But the automation we built to date really borrows from human middleware. We took the commands we used to type into our CLIs, and we built scripts and low-level APIs to automate them. The end result is automated, but it's hardly scalable, reliable, or easy to use. Ultimately, computers benefit from abstraction. That's what we've learned from years of computer science. They don't enjoy being micromanaged any more than you do. And in the end, this industrialization of micromanagement is not the answer. So what does this mean for OpenStack? Well, OpenStack was designed to abstract different systems and architectures. But to date, it does so through a number of relatively low-level APIs. And exposing these low-level APIs actually bleeds implementation details from the different OpenStack projects through to the automation. And this leads to a very close coupling between these two components. This was OK when the systems were simple. But as the feature sets expand, it's actually causing more trouble. The end result is complexity. And complexity is the enemy of automation and scale. And who does this impact the most? Well, it impacts the poor application guy, who now needs to understand all of these low-level details and has to interact with them as he builds different automation. But the reality is, he knows exactly what his application looks like. He's the one that built it and architected it. But he has to deal with all these low-level APIs. His intent is lost. This is bad. It's actually the root of the problem we're trying to solve. So what should we be doing? Well, we have to capture the intent of an application. We have to think about it as a collection of components that actually needs to be deployed across storage and compute infrastructure. And it has dependencies on different services within the environment. And different services also depend on it and interact with it. We need to model these directly. We need to do it in a way that's abstract, portable, self-contained, and doesn't bleed information across these different interfaces. And in reality, if we think about an application, it's more complicated than this. It's a number of different components like this that interact with each other. They may be built by different teams. And those teams don't want to have to coordinate with each other as they're evolving the things they're doing. So if we build this directly, we can actually model things like networking and security implicitly as part of thinking about application intent. Because really, we need to look more broadly at the policy problem. And it really comes with multiple services. One of those services is intent, understanding what the user wants from the infrastructure. Another one is capturing the capabilities and state of the underlying system. That needs to be blended together with the operational constraints from a different set of people that actually run the cloud. And finally, also, governance and business requirements need to be attached to the system as well. All these things come from different people. And they need to be able to be inputted directly, simultaneously, and ultimately, continuously enforced across the system. So again, what can OpenStack learn from this? Well, one, we need to think a little bit differently about capturing intent at the automation layer. We also need to think about capturing domain-specific intent in a way that can be enforced through the different OpenStack projects directly on top of the infrastructure. And we also need a mechanism of capturing governance requirements and allowing them to influence this enforcement. This is the way we'll achieve a system that's scalable, reliable, easy to use, and fast. So how do we get there? Well, there's a lot of different work going on across these different dimensions. In the automation space, there's projects like Tosca, which are thinking around intent-based interfaces. There's group-based policy, which is what we're going to focus on today, looking at domain-specific interfaces to capture intent. And then there's other projects like Congress, which are looking at the governance angle of policy. Ultimately, we're actually imagining a world where we see policy as part of the broader OpenStack architecture. You could think of having a policy repository capturing application intent in business policies, and ultimately rendering these down through application-specific intent APIs with business policies essentially coming through a rules engine, which can create conditions to influence the outcome of the system. Now let me hand it off to Samit, who's going to talk more about group-based policy in particular and how it could fit into this architecture. Thanks, Mike. Mike laid down the vision, the philosophy behind capturing intent of the user, and how that drives the group-based policy model. What we're going to look at next is taking this insight into perspective, how we have built the group-based policy model framework and have adapted it inside OpenStack to complement existing components. So like Mike said earlier, essentially, we want to be able to capture the intent or the infrastructure needs, realizing that how it is implemented underneath is completely orthogonal to the expression of the intent. The same intent can be realized based on different infrastructures, different technologies, and so on and so forth. So let's take a very specific example and motivate the group-based policy model using this example. We identify that there are three roles here in this system. You have the developer. You have the cloud operator or the app deployer. And then you have a security or a compliance officer. And each of them have their specific roles in the system. Each of them have a specific way to express what they want out of the infrastructure, how they want it to get configured. For example, the app developer expresses the intent that he knows how he has built his app. So he says that I need you to provide me access to this particular port. So he knows his application, and that's all he cares about. Whereas the cloud operator cares about how this infrastructure works in general, which tenants can talk to each other, who can have access to the external world, who can access from the external world, to have access to this particular application, what are the, you know, so on. What are the different services that are in the mix? And finally, the compliance officer tends to look at the entire infrastructure as a whole and make sure that it complies with certain security goals that are required for compliance, right? So taking this, if we were to take today's system, today's open stack constructs, we would have to go through a number of steps in mapping that intent, which was expressed in the earlier slide by these different roles, and map them to all these open stack constructs, right? You would need to recognize what the subnets are, how do you set up routing between the subnets? You would need to recognize the fact that there is a VIP that needs to be configured on the load balancer because you wanted a highly available application. You needed to be able to understand that to provide external access for the VIP, you need to associate a floating IP with that. You need to be able to understand the firewall policies that are subject to the compliance and so on and so forth, right? So essentially two things, the intent which was spread across the different roles is also spread across several different constructs which are available, yet they are scattered in different places. And to be able to actually realize each of these, it's not the responsibility of a single entity in the system, right? For example, the app deployer needs to put his app in a particular subnet. He doesn't know what subnet to assign, so he opens a trouble ticket, right? He needs to be able to get external access. He doesn't know what to do. He has to open a trouble ticket. So over and over again, the requirements cross the roles and boundaries, and that actually creates blockages in the system and complexities, right? So essentially what I just said, we have good abstractions today for modeling the sort of lower level constructs that are required to achieve connectivity and orchestration inside the entire infrastructure. However, they are spread across different constructs, right? L2L3 addresses, you'll be able to configure outing rules, security groups, different service configurations, and moreover, this is all manual reconciliation that needs to be done, right? You might do it once, but if something breaks or you need to change something, you need to go back and manually reconcile all of these things, right? So it requires a lot more knowledge across roles and across people and for them to work together to be able to actually get this thing going, right? So obviously the question is, can we do better or how can we do better, right? So again, let's take that same specific example and let's see how the problem specified in human language lends itself to how we can organically evolve the group-based policy model out of that, right? So we recognize that there are, in this particular example that there are two tiers, right? And we can model those two tiers as groups, right? We have some existing services that are there in the system. Those can also be treated as separate groups, right? Then we recognize that these groups need to talk to each other or need to communicate with each other, but that's based on certain constraints, criteria, or as we call it, classifiers over here, right? For example, in the first case, we say that the web tier needs the port 80 to be open, right? So that becomes a classifier. Network communication between DB tier and the web tier needs to happen in a specific way. Specific traffic needs to go to and from the internet, right? So these are captured in the GBP model as classifiers. Then we have the notion of policy tags. And policy tags are more specific constraints on the groups and the relationships between the groups, right? So for example, in this case, we could generically model the app tier and the DB tier and then still be able to have more finer granularity classification, like one needs to behave as a production group and the other needs to behave as a dev group, where the constraints on them are very different, right? Maybe one can access the web or the internet, one cannot, and so on, right? And finally, things like having access to the internet, the fact that the traffic between certain groups is inspected by a firewall or is load balanced can be captured in the form of actions. So if you put all of these things together, we get the simplified form of the group-based policy model, right? You have the notion of groups which are connected together by policy rule sets. Policy rule sets have policy rules which have a classifier and an action. And then action itself can actually point or redirect to a service chain, right? And then you can have further classification and constraints between the relationships based on policy tags, right? So this is a simplified, high-level, organic sort of definition of the group-based policy model, right? With that, let me hand over to Prasad who will walk you through more specific examples. Thank you, Sumit. So what I will hear you talk about is what considerations we took as we started to design and architect the APIs. The basic tendency is to kind of further simplify the automation, right? So in order to do so, what we want to look at is how does various owners of a data center in terms of either the application owner or the deployer of the application or the infrastructure person, how do they express their intent, right? Well, the first thing is make it more simple. The second part of it, I mean, once you make it simple, we can design and architect a policy engine which can render that in a very deterministic manner. The second part of it is separation of roles. There are already a lot of roles of, I mean, either from an application designer or the implementer to the deployment person again to the infrastructure person and how do you enable them to create their own policies and independent of each other, right? So there's a clear, you need to make sure the policies are independently described and then there's an engine which can combine all together and render them. So that, and the third one is, of course, you want as these policies get described, they can be reused over and over again. For instance, a particular infrastructure policy is typically applied to many applications. You don't want to create, for each of those applications, an infrastructure, separate infrastructure policy. You want the ability to reuse the same infrastructure policy. So these are the basic tenets we started looking at it and then created the, I mean, looking at how to create the APIs and structure the whole APIs. Neutron already provides a, it has fair richness in terms of the networking, in terms of the APIs. What we wanted to do is build on top of it, simplify it further so that the operator can automate it a lot more easier. In order to do that, basically in terms of, both in terms of expressing the intent in a declarative manner, secondly, separation of roles, so that each individual role, the policy can be expressed and then we can combine them together. And the third one, of course, is in terms of reusability of a particular policy. And to that extent, we took the policy, we started building policy engine on top of existing Neutron engine. So it runs on top of the Neutron driver and to that extent, it existing ML2 drivers that all work with the policy engine. Secondly, as some of these drivers provide some innovation, how do we support that? So some of the things we pass, some of the policies directly to the engine so that they can innovate in specific areas if they need to. For instance, a service-chaining driver might innovate and make implement better, so they could innovate. How do we kind of extend that beyond what is there? So to that extent, we started in terms of supporting some of the native drivers where they can use the existing Neutron resources and where they provide innovation, they can extend that. And thirdly, as we go further down, the policy can be extended to other existing OpenStack resources such as compute, storage, so that we can build on top of those existing APIs which are already there in OpenStack. And then you can combine into a more infrastructure-level policy. So now, again, coming back, how do we, we took a very simple case of kind of building what we've built so far. One of the key things is application developer kind of expresses this policy in terms of web servers and app servers. And then, therefore, we might say that, basically, my port OAT needs to be open and the back end application server, some other port needs to be opened. So he expresses that level of policy. And then there's a deployer who says this particular application needs to be highly available. So he puts a, maybe a load balancer in front. So there's a policy which he creates and we add along to the policy on top of the application, the implementer policy. The application itself could use an external application which are existing applications such as they might have gone in terms of a payment service or a monitoring application or they've gone to a database which are extremely existing out in the cloud. So now the applications now consuming policies which are described outside of the domain. And these needs to be independent of each other so that as these applications, if they change, you don't want to re-architect your, what you deployed already. And then the, for instance, the payment card in the payment service, the infrastructure person might have said, I need to log everything which goes through my service. And he puts a firewall. The application who's using it does not know that. He doesn't need to because you're going to a well partition policy between those two, right? And then the existing application, those policies can be moved or new APIs can be supported but the basic application deployers or those policies are not changing. And thirdly, the infrastructure person comes in and says in order for me to deploy this particular application on the internet, I need to pass through a service chain of security, a bunch of security infrastructure. Maybe it's a firewall. It could be a combination of firewall ideas or it could be an IPS. So how do I now basically now put the policy together? So the infrastructure person is going to put a policy in front of what exists for the application to be deployed. Now how do you kind of combine all these policies where each one is being kind of generated independently? And then you can, and then that's where what we're trying to do is the kind of group-based policy renders all these services or all these policies in a way that are independent of each other. So, and for instance, in terms of the simple case of the service chain, a service chain needs to be changed especially from a high availability which the application person has put in and the infrastructure put in, how do I combine both of them independent of each other? So the group-based policy takes care of that. So the idea behind all of this is to kind of simplify and automate, simplify the automation further on top of what we already have. We already as a community built. So that's what we're trying to do in the group-based policy. With that, I give it to Sumit and Steve. Steve and we have a nice demo of what we built and they can talk about that. Thank you. Thanks Prasad. So I'm not sure actually there's gonna be enough time to run through the entire demo. What I'll sort of fall back on is probably we have a heat template already deployed. This is a snapshot of the heat template. This heat template is essentially orchestrating the group-based policy resources which you earlier saw. We have two groups created here and we are having the two groups connect to each other via redirect through a service chain. So I just want to show you, so we've run through actually deploying this through heat and I want to show you what the end result is. So like I said, we have two groups in here, the user and the app group and then we are modeling the connectivity between these two such that there is an action to redirect to a service chain comprising of a firewall and a load balancer. So if you see the deployed heat stack, so this is the set of resources that were created. In this particular stack you can see the app group was created and the user group was created and then a number of other things like the redirect to chain was found, we have the service chain spec and then there is a firewall and a load balancer node in that. I can quickly switch over to the policy view. So we have the two users, two groups. The user group is actually consuming a policy rule set that provides access to the app group such that the redirect is through a service chain and the app group is actually providing that particular rule set. And we have separation between the application policies and the network and service policies. So the application policy is codified in the form of a policy rule set. The policy rule set has rules. This particular rule is to allow TCP traffic such that it is redirected to a service chain and like I showed earlier, each service chain has, this particular service chain has a load balancer and a firewall node. So the load balancer is using the reference HAProxy implementation. It has some pools and members configured here. The firewall has a firewall policy that is being used here. You don't see it here. So we just wanted to give you a quick flavor or validation that this is ready to be used for by early adopters. We have the wiki page and the links that I would like to bring up. So before that, in terms of where this work is happening, this is the launchpad page for the group-based policy project. The bugs, blueprints, QA, everything is driven from here. We follow the regular process via Get It Reviews. And like I mentioned earlier, please refer to the wiki page where we have instructions for actually installing this through DevStack. It's a really simple install. You need to pull our specific DevSab branch and then it installs by itself and you would get to play with all that you just saw here. The horizon interface is available, CLI is available and you have heat capability as well, heat deployment capability. In terms of the actual design-related discussions, we do have a design discussion session tomorrow at a little afternoon where we'll be taking up many of these topics in detail what we touched upon today and also reviewing the future roadmap and features that are under consideration. With that, I think we can open up for QA. Or we can wrap it up. Questions, like if you use this kind of architecture to describe a data center, right? So what's the relationship between DHCP, like get the IP address and has some relationship with this policy? How to describe it? This is the first question. Second question is because on the DC, it's not just the DCN, we also include the management network, office network, like this kind of network. Is there any intention like extended this architecture to this other networks? Yeah, definitely the design of the external network, management network, this gets a little bit complicated into complicated cases. So we don't have the example here, but the notion of the policy ruleset or the contract that we used to call it earlier is specifically meant to capture that intent. So between modeling either the external networks or the management networks as groups and defining the right policy ruleset with the right classifiers and actions, yes, it's definitely possible to model this scenario. As far as DHCP is concerned, you will notice that the way we capture intent here is specifically we leave out the modeling of IP addresses out of this because we consider that to be more of an implementation or a deployment specific detail. So in this case, what we have is we are leveraging the existing DHCP capabilities that Neutron provides us. We also have the notion of what we call as L2 and L3 policies, which we actually did not show here. But if you look at the UI or the CLI, you will see those resources also being modeled. So you can specify a pool of IP addresses, for example, that you would want to provide a particular tenant to consume. So every time a group gets created, for example, over here, a subnet is automatically created and that subnet is created, the IP addresses are pulled from a pool of IP addresses. So that policy also, we are trying to sort of define the separation of concerns between the application deployer or application developer and the network admin, so to say. And the DHCP management or the management of IPAM IP addresses in general falls under the purview of the network admin. And we have specific policy constructs to model that as well. We didn't have them in the presentation here, but we can follow up offline or you can look at the model and you'll find us. I have a question. I have multiple VMs running OpenStack with very advanced firewall. Is it safe to remove this firewall and put it to the group policy based? Group based policy is, offers you a framework of abstractions. It is not substituting any specific layer four to seven capability, for instance. What it will help you to do is, it will help you to orchestrate your system and automate it in a much better way. So today you had to probably manually put the firewall in there, figure out what policies are required, how it is wired between different VLANs or what side of the firewall is facing the external network. All those kinds of complexities, what interfaces. Group based policy will allow you to express or your app user to express this in a way such that that can be mapped to an underlying implementation. So if your question is, will I be able to use existing firewalls or for that matter existing services when I transition to using the group based policy model? Absolutely yes. Thank you. Repeat the questions too. Yeah, so the question, two questions. Is heat the way to communicate intent for the group based policy model? Is that the language for group based policy? And the second question was, how is the service chain model, is it based on some existing standards or how does it, so maybe Prasad can answer that. Yeah, in terms of the, the first one is the API, what the group based policy is describing the API, whether that's going to be described through heat is one way of doing it, the other way of doing it is through CLI or a REST API directly, right? So that's the API is what the group based policy describes, that's the first one. The second one is in terms of the service chain, the what group based policy is providing is a construct as an action to say for the infrastructure to say, infrastructure person to say in order to deploy my app, I need to redirect to something, right? And then there is a description of what the service chain is all about is going to be described in the policy. How it's going to be rendered and implemented is going to be, is going to be how the implement, the implementation is going to be done. For instance, for what we did is we took load balancer and firewall, the firewall as a service, we implemented service chain on top of that. Whereas the expression of the chain is expressed in the policy, right? Also note that what an app user expresses as a service chain is different from what actually the system composes as a service chain because you might have the infra guy introducing certain services in the path. You might have the app guy actually having his own set of, and ultimately the system has to actually reconcile these and that leads to a composed chain which might actually map to an SFC kind of an implementation. Let's say if it's an ODL controller which is realizing that, for example, and it can create that, right? Go ahead. I have a kind of a similar question regarding the language. In the examples you gave, it seemed like you were specifying the connectivity between applications. Do you have any plans or designs to specify the resources that the application needs? Yeah, I think that question kind of leads into the direction of actually extending the group-based policy model to compute and storage. So definitely, I mean, we didn't get as much time to actually go through the workflow, but the way we launch, for example, instances in this is through the notion of this group. And that group has all the properties that are needed, let's say, for that VM. So that includes compute, storage. So we haven't modeled in detail yet what the compute policies would look like or what the storage policies would look like. But yeah, this is the starting point with the network. So yes, the intention is to be able to extend that, and that is some of the discussion that we'll be having tomorrow in the design session as well. But however, the networking resources is already expressed. So for instance, if you look at L2 policy, which you talked about, the range of IP addresses you want to use. So that resources, today we are focusing on, as Simi said, on the network part of it. How about bandwidth? The QoS is an action which is there, which we don't support it in terms of the implementation. But the action is there, the QoS. Yeah. Yeah. Currently, the path that we have taken is to be able to leverage existing Newton abstractions when we are trying to actually orchestrate this implementation layer. And we are leveraging the reference implementation for most of these, so be it services, or be it the plumbing constructs, so whatever is there. But the model itself is definitely extensible to that. Sorry, I misunderstood your question regarding the networks. Can you hold the mic, please? I guess we can do a couple of more questions. So you said you're building on top of Neutron, right? Is there any plan to unshackle from Neutron and maybe even use ODL as a basis for doing not just R and Neutron and ODL as? That's exactly the slide. Basically, there are Neutron, if a particular driver optimizes on certain area, then you can basically pass to that particular implementation. Neutron is just the starting point. No, Neutron, all these things use Neutron, right? Ultimately, there are a lot of Neutron resources which are already being used. So some resources you might want to optimize better or provide more functionality, in which case you should be able to do that. That flexibility is there. Hi, so if the network already be configured with the traditional, you know, like a manual configuration, how do I migrate to this model if I want to use this group-based model? Or if you have any plans to cover that in the future? So I guess your question is how do we migrate from a legacy network? Yeah, existing to the group-based policy model to deprive the users. Yeah, so obviously, so there's an element of your question which ties into, you know, how do I migrate to OPFI? If I have a legacy environment, I want to migrate to using Neutron, where I'm now delegating to my tenants the ability to configure networking, right? So some of the problem we would face in migrating GBP is similar to that problem, in that now you have to delegate, you know, you have to modify your processes to delegate these behaviors to tenants and you're delegating them as group-based policy rather than a network router logical construct. And a lot of that is sort of an internal kind of management process. There's a flip side angle which is, you know, there's information in this model which if you look at your existing network today is not captured, which is like, what does my application actually look like? A lot of people have this in documentation. You know, at the time the app was launched, they created it, you know, people have told me they created a document that described it all or the guy had built it knows how it works. So, you know, there is a set of tools, you know, that exist to some of this reverse modeling, but a lot of it, you know, a lot of the best ways to do it are when you're building your application or that you essentially use this as a way of documenting the behavior. So one of the big advantages of group-based policy is it is a self-documenting model for what the application looks like as it's deployed on the infrastructure. So a lot of the best ways of capturing this are from the application developer directly or from essentially the person that built the application and them describing it. It is possible to infer some of these relationships by looking at the network configuration. And there's some tools to help with that, but obviously the best way is to, you know, start with the intent-based design like we were just discussing. Also, one quick final thought is that if you are looking at the migration from an OpenStack interface perspective, you can actually, the way we have developed the Neutron Reference Mapping Driver, you can actually leverage your existing plugins for whatever technology they are built as is and be able to overlay the group-based policy constructs on top of that. Thanks. All right, thanks all for attending. Thank you.