 OK, so it's four, so we could start. So thank you everybody for joining us today. So we are going to present you how talks are label wrangling, so how to manage what you barely know exists. My name is Jeremy Meschuch, so I'm a research innovation project manager at Devoteam. I'm presenting today with Carl Castagnet, which is a cloud DevOps architect. So this work and this presentation is based on a project we work on at research and innovation section of Devoteam. So we are working on the research axis on Autonomous Cloud. And the subject of label is key to allow us to construct this Autonomous Cloud. So that's why we work on label and represent today of this work. So OK, so let's start the wrangle. So this presentation is decomposed in five steps. So the first one will be to define what is a label, what is not a label. So it's the main key for cloud-native environment is labels. Then Carl will present you the common use case based on label. And what happened when you forget to consider labeling? And then I will take back and present you the labeling best practices and the wrangle for homogeneity. So what is a label? So a label is basically a key value pair, which is defined, which is tagged on resources. A resources has a name and technical characteristics. And the label will allow to add functional context to it. So two for an example, we'll take a pod because we talk about Kubernetes here. This pod is tagged, is labeled with environment, dev, and a project divo1, which say that these resources belong to the project divo1 and the developer environment. What we want also to say on the label, that they are not hierarchical, they are flat, and transversal. So you can use label on any kind of resources in cloud computing context. But any other context you can think of. And that's the topics. So what is not a label? So we consider two set of properties for a resource. So the first one, which is not labeled, are the intrinsic properties. So basically the kind, the image, the version, the request, and limits. So still in a pod context, in a pod example. And then which is labeled will be the extrinsic properties. So now we can see project, system, version, environment. We consider that as label. So basically, as I said, anything that can add functional context to the resource. But just to conclude this slide, labels does not produce anything. It allows you to identify what belong to the resource. So now that we said what is a label, what is not a label, we will see the purpose of labeling. So why are we labeling? So basically, we are labeling to group similar resources. And we apply this context on the label-based rules on several cases. So labels allow to group resources. So like that, we can see that we can group pods based on the project that is assessed on the second one, on another project, and on the third project. And then we can use these groups to apply a label-based rule for finance. For example, we can see that in several projects based on FINOPs, several projects based on FINOPs. We just use labeling to see what's the cost of a project, then on sustainability, which is basically the same context, the same use case, then globally on DevOps and C-Sops, and for security context, and also access control, observability, and any other. So now, Carl will present you the common use cases as presented here in a deep dive. Hello. I want to introduce label use case. So I'll reintroduce another view of common use case. And it's not exhaustive. And I'm sorry. Label use case is used in many cases. So first, I want to introduce label use case in control access management. In Kubernetes, the access wall are used in an airbag in Kubernetes. And for more granularity, you can use initial control. So if you want to be more granular, you have to use label to specify what you want to containerize. So you have different teams. And for each team, you can set up a notification access based on access control to access to resources. The second use case is for backup and operation use case. You have two main use cases. In the first, I will present, is at the infrastructure level and on the application level. In this case, the C-sub's team can manage the entire cluster. And the DBI team can access to the database through CoupCity ad commands. And through an application like Kastan, you can become teams, can use the labels for create boopling, type policy, recurrence, DRP, and access control rules. Without applying access control rules, they can give to application team some basic operation like resolution, monitoring, and backup. In the next use case, this is an abstraction of under eye technical function. If you go in CSP, you have many products that you can choose for a performance. And you can group them for many CSP in one. And you can abstract the performance by labeling the service. So this gives a catalog of this usable for all of your team. And it can be validated by your finance governance. And it's quite independent. So you can use one kind of performance in any cloud you are. And it's an explicit architecture that can help you to see how your application is deployed. It's very easy. The next use case is for service. You have sometimes application decomposed in multi-micro services. And probably, micro services are shared between two applications. So in this case, it's a good way to labelize your pods to see which application consumed this application to see the impact of an outage. So you can use it in long-end accession and make dedicated dashboards for troubleshooting. And you can manage also your SLA at the design stage and see if you have a discrepancy between micro services. The last one I want to introduce is label-based security. This is another topic because this leads to too many security issues. You know that you can use it for network policy, but you can use also for admin network policy at the cursor wide. And it can lead to perform some mistakes with this one. The other function control is the one I presented before. And it's used for the runtime security for group process, process rule, file access rules, and network rules in tools like Nuvector, StackRock, and probably Tetragoon, and so on. The point is pod security admission use label. And if someone can set a label on namespace, it can evaluate privilege. It's a very important issue. So now what's happened when we forgot to consider labeling? If you deploy application without think about label, you can have this agree information system. It's not manageable at scale at all. You can use label for a massive treatment. And you have to think this beforehand. So the message is label is governance first. And you have to think about how you have a governance about a label. This is the message. Now in classes, the deployment of an application, you have the day one, day two. And at day zero, you have to implement the governance announce that you set up. And you have to think also, if you don't have any use case for improve your governance and change it if you want. At day one, you have to build with what you decide. And at day two, you have to use this label. But not only, you have also to manage every change of the label, because it can lead to issue on operation and security. Now Jeremy will present his work on label for take homogeneity on label and solve a part of the issue. OK, so thank you. So we'll continue to labeling best practices. So as Carl said, what our work and reflection on what you have to define on your resources. So basically, the first question you have to ask is the focus still needs to be the resources. And then we will ask five question on what we need to be labeled on your resource. So the first one, which will be the organizational unit? So for who this resource will be used, who will use these resources? So for which application? So basically, for which application will use how resource? For which technical resources? So with which resource, how resource will interact? A lot of resource. Which type of resource will interact with them? And which type of resources, how resource is? And then the fourth question is the financial aspect. So basically, on the business model, so will it be on premise, on cloud, spot instances? So a lot of questions are related to business. So that's the fourth one. And then the last one, and the main one, it's an SLA, the SLA one. So on which SLA have we to enforce this resource? Because you have to manage these resources. So the SLA you have to respect is main question also. So now that we have all these five points, we're going to group them and put it on a knowledge base, which aggregate every information, how resource, how needs to be labeled on. So this knowledge base could be defined as an ontology or taxonomy. And it's knowledge representation, but it's a number of topics. And you will have to do some data governance on this knowledge base, but it's another topic. We don't cover here. So now we have a knowledge base, which is basically our framework. We will use it for several use cases, as Carol presented you. But how can we enforce it? That's the first question of this slide, so which we call a label coercition lifecycle. So the first step is defining the knowledge base. Then we will use it with admission controller policies on any types of them. Then we will have to apply these policies, which could be mutation. So inject new label on resource or validation to check labels defined on the resource you deploy. And then we will have the label based use cases as present Carol earlier. So this is the topics to the first part of our presentation on anticipation, which is the key if you want to truly manage your label. Now we will see of the wrangle, so the topics of the title of this presentation. And it's basically when you want to labelize, but you haven't anticipate. So how are you going to do? And that's what we propose here. So basically consider the developer or ops, or as you want anybody who can deploy resources on your cluster. And they want to deploy resources label on the environment development. And they want to say they are really nice. They had labeled to their resources and they had label. So the first one we'll define is resources as environment develop L, I think you can read. And then the other one will define also, want also to define in development environment, but he will define is label a key and value differently than the first one. So basically in this context, we will not be able to apply the same resource, the same rules on this two kind of resources because they don't have the same labeling. So assume based on that, we have a huge problem and considering. So now it's just an example, but consider it at 1000 scale with a lot of ops and way to define their label, their context. So just considering that. So to remediate to that, we propose an approach in two steps. So the first one, so this is your cognitive architecture, which is defined with bad labeling. You will start by extract label from that, that's what we propose. You will get basically a local referential, which is the aggregation of all your resources, all the technical, the technical characteristic as name of your resource and the label defined, which will be input in our intelligent label homogenization component, which will be based on the knowledge base. Sorry. And based on this component, we will have a recommended referential, which will be the correction and homogenization and the action to do to apply on the cloud native architecture and get homogenous labeling in our cloud native architecture. So we're going to deep dive in the two steps and two steps we propose. So the first one is the label extraction, because your context is cloud native architecture, we will have to consider and to interact with a lot of services of API, of context, of cloud service provider also. So we propose to use a cloud asset inventory tools, which is Resoto or Fix Inventory, which is a tool which gets you a graph-oriented databases of your architecture, which you can interrogate and get information for the local referential. So it could be a G-Zone or directly on the databases. Then the second point is the knowledge base. For the example, we keep it really simple. So we just consider label on environment, project, cost center, the key and value to use. But as I said, this could be really more elaborate and it's basically so knowledge management work. So in the next step, we have the Intelligent Label Ambogenization component we propose, which is, as I said, based on the knowledge base and it's based on natural language processing and similarity analysis, which will allow to connect the label defined in your local referential with data in your knowledge base, based on the syntactic and semantic analysis and get the recommended referential, which will be used as in the first slide. So just to insist on this example of natural language processing, this allows you to use syntactic and semantic. It's not just one of them. The syntactic will allow to detect so typing error as you can see in environment, which is an error we do a lot. And also in semantic, it will be more on the identify the concept we want to say to present. And this will be that. And I want to say that this technique will allow to compute score of similarity between the two words and that's where the decision is taken, if it has to use a label beyond another one. So just to elaborate the example, I have a slide, sorry. I have a slide with the knowledge base, which is the one I present to you. Now you have three resources, which are labeled on their own way. So you have on the environment. Then we will use our intelligent label homization component, which is, as I said, a combination of syntactic and semantic analysis. And it will get a recommended referential that you can apply on your collaborative architecture. So just to be sure to understand, this free information will be grouped as environment with syntactic and semantic analysis. And then we'll be applied on the several resources with environment. So here we just consider a key of label, but it could also be on the value if we want. And another example for project, it would be the same thing. And cost center is okay. And then to finish, so the perspective of this project will be to evaluate our system on new cloud native environment, because we only consider Kubernetes. And it could be applied on several use cases as any cloud service provider or anything you can label. Then extend our knowledge base because it's really an easy one. And work a lot on how to present this knowledge, how to formalize this knowledge. And then the last one is would be to have an open source project to open source, how code, directly to the cloud asset inventory, like Resort or Fix Inventory, or any other one. So to conclude this presentation, we will have, we have present to you that label our main components for cloud native environment and a key to manage a scale resources. There are several use cases on label as you can have seen on any of the talks in this four day. A non-homogeneous labelization can induce issue in operation and governance and anticipation is key, but remediation is possible with our approach. So thank you if you have any question. We'd be glad. So thank you. Thank you for your insightful presentation. So I found it really engaging and informative. My question is to know what could be your recommendation in a situation where no initial level are provided. So really good question. So as I said, you also have a label which is defined by the cloud native environment, by default, and then you can infer a label for all your resources based on their technical characteristics and also by information, so based as what user defined it, or what user deployed it, or in which context, we can relate information to define to labelize them. So every time there is a label, so there is no context where there is no information at all because if there is no information at all, we can't do anything. So thank you. You can use also the interaction between all the sources for labeling, not only intersex or source. You mentioned composition to enforce the new labels. Operations teams are usually very conservative. How did they respond to that? So that's a really good question also. They don't answer really good when we talk about that, but as I propose to do is just to add new label. So leave legacy if you want because this label will not be used, but if you want to keep it, we can keep it. But we will have new label, which will be correct and can be used. So thank you very much.