OK, very warm welcome to all of you to this webinar. It's all about how you have usability in terms of pipelines, specifically in the modern context in a cloud native world. But before we head into it, a little bit of context in terms of what is happening in the current market right now, specifically in large organizations which are involved in banking, telecom, finance, petroleum, industries, et cetera, just from our experience. So in the past, it was more like Kubernetes or container technology was adopted by organizations which are new age, more so like startups. Think Facebook, think Instagram, or think something on the lines of an e-commerce website that is within your region. But with the passage of time, Kubernetes has become the de facto standard. And what typically happens in such organizations is that there are multiple sources of where they source their applications from. With that being, some of it might be developed internally. Some of it might be like CODs applications which are supplied by external vendors. For example, take the example of Finnacle. Finnacle is developed by a company called Infosys, which is part of the core banking systems of many financial institutions. With that said and done, there is a need for distributing your applications across pretty much any cloud, one being business expansion, the other being technical limitations with certain clouds, lack of availability of infrastructure in a particular region. For example, in the Middle East, it's only now that AWS is entering this scenario. And for example, providing all of its infrastructure, tying up with local providers in terms of where the data centers are hosted, and eventually giving you a Kubernetes cluster. So although business demands that you expand to as many regions as possible, typically, in mature organizations, it's quite the challenge when it comes to getting your applications there. Now, think about it. If you've got a Kubernetes cluster, the eventual end goal of an organization is to run applications over there. So before we get into that, we would like to just introduce Mothish, who's a technical lead as well. Mothish, what are the typical problems that you see when it comes to a junior developer who's working on applications and needs to get his deliverables to any Kubernetes cluster? OK, thanks Prashan for the question. So I'd like to, in general, tell about what are the problems, individual DevOps or developers, even new ones, even the old or experienced ones face every day. So the main problem I see is the time that is spent on the development versus configuration or deployments onto multiple ecosystems and multiple infrastructures. Basically, whenever a developer comes into developing mode and he'll have to set up some of the things that is required for his day-to-day work. So for testing his day-to-day changes and delivering a solid proof, solid product, he has to set up some of the stuff. All the microservices, as of now, we have multiple microservices in our day-to-day work that are involved in setting up for testing the things. So the most of the time is spent on configuring all the different infrastructure components. And then he can test out what his features are. So this place, we are spending too much time. That is one of the problems I see in day-to-day DevOps workflows. And this happens not just a single day. It happens every single day. And it happens with every developer and every DevOps engineer. And that comes in a lot of time. And it requires a lot of training when it comes to, so if a new developer, if you are onboarding a new developer onto your team, so you'll have to train them regarding your infrastructure, how the different components fit together, and for him to get up and running with the setup of our everyday development workflow. So you'll have to train those new engineers or even the experienced ones who came from a different organization to your organization. It happens every day. And it can be, we can't do it right all the time. So even for experienced developers, it happens that they'll get into some configuration issues and they'll try to debug those issues. And it consumes a lot of time in the process of development, delivering the product from development stage to the deployment stage. So this is not repeatable if we are doing it manually. And there is a, so what if some of the infrastructure goes down and you'll have to communicate with different teams and you'll have to raise tickets and communicate with the team, get it resolved. And all these things are, as of now, it's manual, which takes a lot of time. And you can't give, in typical companies, we'll have multiple infrastructures, multi-cloud infrastructure where we'll have different setups for development, one type of setup and for production, there is another type of setup. And how do you control the access between development and production workflows? That is another area where we have to improve a lot. Got it. Interesting thoughts, but just, we wanna delve a little more into the teams. So now what the current scenario that we have in our product team is such that you have independent teams like which are managing microservices and considering that it's heading towards a microservice level architecture. And what are the challenges that you foresee? Like do development teams have their own preferred frameworks for let's say quality analysis or security scans, et cetera? Like what is the scenario right now? Yeah, the typical development process from development to production, how it grows, is like when a developer submits their code, the reviewer has to go through the code and has to approve the pull request. And I can't be guaranteed that a reviewer can identify all the security issues that are happening, that might arise in the future. And it goes beyond the developers control where it'll have to go into some staging setup or an alpha setup where your quality engineers, quality assurance engineers will test it out and figure out if there are any issues and there is another aspect. So quality assurance can guarantee it to a certain level. On top of that, there is some companies will have security teams who actually try to test the security issues in the product. And this cycle will take a lot of time to proceed further. Like from development to the deployment, it takes a lot of time to validate each and every step and go through the process of delivering that solid proof and secure product. So there we need to improve that. Got it. On the terms of reusability, what are the typical challenges when it comes down to let's say a developer consuming like let's say security standards or quality standards. And again, let's rewind back to someone who's setting standards at a framework level. Like you might have Node.js that one team prefers and you might have another team programming on go. So is this a major point that an organization follows that you have a standard repeatable process? And if so, what are the typical gaps from you as a technical? So whenever I observe people, whenever there are like multitude of tools that are available today and each individual developer has their own preference towards using those tools. Even though they are outdated, they might not want to use the latest technologies and they might not want to learn new technologies. Some of some people are passionate enough to learn new technologies and try to experiment with the new ones. So most of the people I find are hesitant to move from what they know into what new features, new tools that are available, even though they are more secure and more powerful than what they are using because they learned they have spent too much time on those tools and they stick to that because of their inertia to move from one technology to another. And there are well-known vulnerabilities in the old versions of the tools. And some tools are no longer valid for the latest use cases. So this area, so if I have to move the developers from one tool to another, we have to train the developers and it takes time. So and it also depends on the practices that the developer follows in delivering a product or features. So there are some standards that we can, each individual organization can have its own standards and there is no universal standard as of now that can guarantee products, security and stuff. Exactly, that's very well put, Modish, thank you for that. So the point that we are trying to bring out over here is that you've got so many teams that are following so many frameworks. Some security scan, scanning tools do not support like let's say older frameworks like let's say Spring Boot but they're really good at like identifying or meeting the needs of a specific team. Now when we've got a microservice level architecture, the one aspect that you've got is like self-sufficient teams that is driving the whole software development life cycle into pretty much like product and platform engineering teams where product teams or product engineers are wholly and essentially responsible for all of the quality and all of the security but yes, you have platform and security coming in and setting those standards. That is where the whole cultural shift is happening and this is typically defined as a shift-left movement where it's not that you develop an application and leave it to somebody else to verify the quality or security compliance aspects. You pretty much tackle it much, much more earlier within the software development life cycle. Preferably like even like before the development environment stage that again is subject to the organization that you're in and the scale of your application delivery and the scale of the possible risks that are involved that virus over here. I mean business loss, downtime or like compliance issues, regulatory issues. So if you make a mistake, it's gonna be really, really costly especially in the sectors that we typically deal with. So again, there's one very important point I think that we need to cover before we head into the full technicalities of what reusability means in the modern cloud native scenario and that is like, you know, the skill set. So Moutish, how difficult is it? There are two questions that I have here. One is how difficult is it for developers to pick up like let's say the whole CNCF ecosystem of like, you know, Kubernetes and the security aspects, the quality aspects, compliance aspects, et cetera, XYZ. And the second thing is do they really need to know all of this? Okay. So today Kubernetes has is the de facto standard for everything that's happening in the world. When it comes to Kubernetes, it is rapidly changing and there is a huge ecosystem that is growing beyond our control that happens every day. Like every day we see every month so many projects are getting added to CNCF and so all these tools have their own purpose and they have their own ways of adding functionality to what Kubernetes offers as a base. For us to learn these things and okay, we would be used to some of the technologies and some of the workflows that we use every day for Kubernetes. So if we had developed and deployed our infrastructure in a certain way and there might be a new tool that is coming up in the next days and we may not be ready to actually accept that into our infrastructure because there will be a lot of moving parts and if we put that new tool into the infrastructure that might break some of the stuff. And it's also not easy to expect. It's not easy to learn the new things that the rapid rate at which the new technologies coming up in CNCF. So it's not really, it's not easy to learn all the new things that are happening. So we need a unified way of saying each developer doesn't need to know all the tools. So if there is a system that can provide all the things that are required and if some set of engineers if somebody is taking the time and effort to put together all the stuff CNCF projects and giving it as an abstract functionality to an infrastructure team, that would help us in a big time, yeah. Very well put. Thank you, Moutish. With that, I will hand it over to Moutish to take you through the technicalities of what is usability and how is it changing in terms of a cloud native world where Kubernetes is the de facto standard. So thanks. Over to you, Moutish. Thank you, Prashant. So extending the problems that I defined earlier. So what it takes to achieve a consistent and an efficient deployment mechanisms on the multiple ecosystems of multi-cloud infrastructure. So as of now, we don't have any standards that are defined across teams and across companies, across organizations. So each organization follows its own standards and they have their own ways of deployments and this is not repeatable. Basically, even when you have within the same organization when you have different set of environments where development teams will work on some environments and the production environment, staging environment, these different types of environments and if you have especially when you have multi-cloud infrastructure. So you should have a way of deploying your own infrastructure, deploying your own microservices onto different platforms in a repeatable fashion. So you can't just manually do it every time. It takes up too much time. So automatic validation and it takes too much time to actually certify a build and then deploy to staging and then to production. If we do it manually, it takes too much time. So in the fast moving world today, so we can't afford to have that much of time lag between releases. So a lot of developers time and even DevOps engineers time and SREs time is getting wasted in this area. So if you are not repeatable, if you have infrastructure, deployment is not repeatable. So it's not the efficient way of working. So we should have a simple and easy to have deployments and it should be error free. So what happens when you do manual deployments is it causes human errors. So if we are deploying and if it works, the common notion is like, it works in my laptop, it works in my environment. So this typical developers usually have heard of this phrase. Basically it works in my setup. So that's why it came, Docker came and we will ship our own Docker image. So even then now it exploded into microservices and whole new set of problems arise because of that. So we'll have complex communication mechanisms between different microservices and service measures is a different concept that comes into picture here and configuring those service measures. And it's a different volume and it's very difficult and it's not easy to get that done without errors. And we need a notification mechanism that can detect errors in the infrastructure and notify us about the issues. And if you are doing it manually, once again, it's not the efficient way to do it. So in this regard, how we can have standardization and an effective interface that can bridge the gap between the development and deployment, I'd like to present some of the ideas. So what if the first idea is what if we can visualize our infrastructure on the screen, on the computer screen and what if we can drag and drop your applications onto your infrastructure just like in a computer game. So what if the UI shows deployment dependencies on all your configurations? If you do something wrong in the configuration before you even deploy it onto your infrastructure, if the system is ready to show you, this is what you have done wrong. If you deploy this particular application, you'll get into errors. What if the system is intelligent enough to suggest you that kind of errors? And what if we have a whole new set of libraries, pre-built libraries for deploying into multiple architectures and multiple models or modes of deployments like blue, green deployments, canary and if we have pre-built the Github's workflows set up, and what if we can achieve deployments without writing any code? It's a complete 100% deployment automation, what if we can do it? And if we could manage all the cloud accounts, nowadays organizations will have multiple cloud accounts and they have different environments, different clouds. So what if we can manage all those cloud accounts within one platform? This is an area where a unified platform can help. So in that regard, so there is an open source tool called Tecton, which is a very useful tool and which is lightweight and generic and it's very flexible as well. So with Tecton, you can actually automate all this on the stuff that I have discussed earlier. So most of the infrastructure aspects and deployment aspects can be automated with Tecton and because it is a cloud native project, so you can readily use it for Kubernetes and there will be no bottlenecks. I'd like to share some of the problems that I see in Tecton. So basically, it takes a bit of time to learn Tecton, but not everybody knows how to create Tecton task and how to run a Tecton task. So in this regard, some of the tools that are in the market today are helping out a lot in this respect. So we call that as a value stream delivery platforms. So they're built on top of Tecton, which extend the functionality of Tecton and provide a lot more than Tecton. So it actually integrates with all these, some of the solutions that we have today are Jenkins X, Ozone, Scaffold, GainE2 and OpenShift pipelines. So some of the things I have are multi-cloud ecosystems and OpenShift especially doesn't provide you with functionality to manage your own cloud. So you'll have to go with OpenShift. Ozone on the contrary can provide you with a lot of multi-cloud ecosystem management utilities and you can connect all your ecosystem of multiple cloud accounts and multiple repositories and you can automate most of the stuff in your deployment process. And these tools have a very good user interface and Ozone especially has a drag-and-drop functionality where you can build your own pipelines with just a few clicks and you can automate most of the stuff that I discussed earlier. So yeah, these tools have some predefined templates and Ozone has a huge set of predefined deployment templates that you can reuse, tecton templates. And even extending the tecton templates like for achieving GitOps kind of deployments, blue, green, canary, there are predefined templates for that and you can manage all your cloud accounts within one screen. So it absolutely has no learning curve so it's easy to use. So with that said, we are here up to some level we have achieved a pretty good value stream delivery mechanism for on top of tecton and we are still in the process of improving that and we are trying to make the deployment procedures easy to do and repeatable. So this is where, this is how what I want to say about the repeatable deployments and yeah, reuse of pipelines. Yeah, thank you guys. Over to you Prashant. Thank you, Motish, very well put. So again, the callback is towards a multi-cloud scenario which is being driven by largely from a compliance perspective from business and lack of availability of certain technologies like cloud technologies within certain regions which again pretty much boils down to the region that you host your data at. The second point over here is that a shift towards like the traditional architecture of like how you split your teams which is your developers, your quality analysts, you've got security analysts who define policies and you've got like site reliability engineers who help out with your operations. Now, all of these are being merged into pretty much two domains which is platform engineers and product engineers, right? So with that said and done, like not everyone needs to know the underlying aspects of like how things function in Kubernetes, how like things are handled from the whole entire workflow. It's actually detrimental to what they can contribute because at the end of the day, if you look at it from a product point of view, you're pretty much looking at the value that you deliver to a customer. That is the core aspect of a value stream delivery platform where it helps you actually benefit like from a business angle. That is like you might have a DevOps process that is like in the, that is very defined or some of you may think. But the question that we definitely should ask ourselves as a whole organization is that, is it really delivering value?  By that we mean, is it repeatable? Is it reusable? Is it scalable? Is it secure? And more so after all of these points, are you able to deliver without compromising on quality and security? That is imperative in a world where attacks on systems are very, very common and there are new vulnerabilities that are being discovered day in, day out. So it becomes like the core system that you will rely on for agile development process which is, or agile philosophy I must say, which is like being followed by more or less everyone within the software development life cycle. So again, the ways that you might measure like how your automation processes are efficient, there are certain gaps in terms of visibility. Like for example, if an engineering manager would like to identify, is it something on the approval that's taking time or is it a build process that needs to be optimized? How do you identify all of this? And add a complexity in terms of multiple tools like being followed by individual product teams. For example, some team might be preferring SonarCube because it's already built in, everything has been baked in, it's all grandfathered in in terms of standards. But a new team comes in tomorrow and says, hey, I wanna use something like, let's say Claire or I wanna use something like Snake because it fits much better for my use case and it solves my problem. So you do want to give the product teams, agile teams, that kind of flexibility. That is where the complexity comes in. Although Kubernetes solves like one layer of like orchestration problems, but as is always the case, if you consider entropy of the world or if you consider physical concepts, introducing lack of complexity in one angle is always gonna generate complexity on the other side. Now, this complexity is being transferred to developers and developers are not in a position. Not all, I mean, there are some really high class developers who believe with it, but what I'm talking about is a generic organization or somewhere where it's widely distributed, not everyone has visibility over all of it. So visibility is a challenge. Like for example, how do you debug issues? Like you might have logs from the framework level, but what if something is going on at the infra level? Do you really want to give like Q-Batman access to those guys? Of course not. So you need to be able to like pretty much visualize all of it in one single platform. That is where VSDPs come in and help you optimize your DevOps tool chain, like in terms of continuous delivery. It helps platform engineers define standards so that they can pretty much optimize their time and efforts into developing something which is automatable and more importantly, repeatable and scalable in the organizational context. And by that I mean like from like scaling the organization. Like let's say you're 40 developers now, tomorrow you might be 500 developers, who knows? So you need to have all of these like moving parts in place right before you scale. Otherwise, once you scale, you're not going to really see the benefits of like your automation processes. And it should not be a single point of contact from most all of it. It should be standardized within a framework. That is where value stream delivery platforms come in and really help you scale your DevOps transformation processes. With that, I would like to take a pause and hand it over to Abilash. And Abilash, please go ahead with your inputs and conclusions if whoever may be in your mind as well. Yeah, sure. Thanks Prasanth and Mothi for this webinar because we've seen the term of value stream delivery platform or a VSDP come up multiple times across maybe as being created as a separate category by Gartner or blogs popping up on the net. And we just thought through this webinar if we can help consolidate all those informations through this webinar and put forth also the point that how Tecton as a framework enables you to reuse your pipeline and standardize your deployments across cloud and how a VSDP basically extends that capabilities in the form of giving you an UI, giving you a user interface that Mothi has explained all the capabilities that can, you know that you have those capabilities we are making it much more reachable across to the audience, much more accessible. So you can leverage the benefits through a VSDP and as a name itself says the platform helps you map your value stream across your DevOps phases and the end-to-end value delivery from code to customers is actually pretty streamlined through a VSDP which the likes of which like Ozone or Jenkins X or whatever platforms are there, they help you deliver this value to your end customers. So how they do it is what we have seen through this webinar and you can have more information on the respective tools, websites or there are many, we hope that the category of VSDP comes up soon on Gartner and the vendors who are listed on the Magic Quadrant I think that would basically give everyone a kind of clarity as to what exactly a VSDP does. So yeah, thanks. Thank you everyone. Thank you everyone for joining us on this webinar and please keep having questions. Please post in our channel.


Hello, greetings. See about half of you may have been on the telco music group. Which just ended. This meeting CNF working group is being recorded. It's be published to YouTube. We'll get started in about three minutes at five after. You can add your name and any agenda items to the meeting notes, which I've posted in the zoom chat. If you have any agenda items, you can drop them in zoom chat if you're not able to read the access to Google Docs, which I know doesn't work for some people's work firewalls. All right. Let's go start. Let's see. Who's had your name and if you have any agenda items. Let me know right now. Does anyone have anything they'd like to add. As I can look at pull open pull request. Try to work through some of this. All right. It's very quiet. I'm going to presume my audio is working. It worked on the last call. We can hear you. No worries. Yes, it still does. If no one has anything else, then I'll jump into the pull request. I'm going to work top down. So I think this one came out of comments in the last call about best practices and the template we'd put together was based on the Kubernetes enhancement proposals or caps. And this was before we actually had best practice proposed and trying to see what would be most relevant and useful for us. The test plan, just the wording around that was throwing throwing off some of the view of what we needed to have in there. And it seemed like test objectives was an agreeable one. Let's see if I can give some context like this. There we go. So when you're giving a test plan. I mean, talking about is the best practice testable is the main thing so thanks some of the comments where we put a plan to how detailed do we need to get when we hand it over is it so specific that anybody could implement it. That agreement was we're overall saying test objectives and is the best practice testable and letting implementation of that be up to whoever is writing the test. But this one looks pretty straightforward. If we could get some plus ones on the call, unless there's objections. To be clear, we removed the wording for test plan and instead it's testing objectives. Correct. Remove test plan replace it with test objectives. That's great. I think that's very clear. Thanks. I would. Should I do it right now. Yes, please. Please. I'm going to bring this one up since it actually has more context. But does anyone else have a question or comment about that. Oh, okay. So, and this one right here, test plan application which follows the best practice will not have any containers with processes running as root. This best practice will be tested by the test suite. Some of the comments where this doesn't have enough information as a plan for someone to just implement what are the inputs and outputs and other things like that. So rather than saying test plan we'd say test objective and that example testing objectives so higher level. All right, I got one plus one. We get some more on this call. Maybe I'll are doing it and I'm not saying it calls. I will know that I appreciate a Jeffrey's idea here of calling it testing considerations. But I think testing objectives is fine. It's under that you can put considerations for those objectives right have to reach them. So it's it's all about the details. I agree. And I think that's a good idea to put considerations and their when it's relevant. If there's something or someone has experience trying to communicate that would be great. If you want to. Thanks, Ronnie. I'm going to count that as a plus one you can also click on for those who haven't done this. So if you have any files click review changes click prove do a plus one or LGTM. This one's pretty minor one. I think we haven't like specifically labeled but for bigger ones we wanted five I believe and if I go look at the merge. And how we're going to do that. We probably consider this one like a smaller update on wording. If there's no objections I'm going to go ahead and merge it. Okay, the next one at format version CBB. Ian is off. I'll try to speak to this. Let's see. Bill are you on the call. Is this just a formatting issue. Lenting. Okay. Sorry, I was on me. Yeah, it was just adding the space afterwards all the checks could pass. All right, sounds good. Okay, so going over here. This is a hidden HTML comment. And I won't click rich shift because I think it may yeah disappear. But having the whenever anyone copies the content over that the best practice that you have would have like the template version so if we're updating it will know hey we changed test plan to test objectives. Let's make sure and get all those updated. So that's really what this is about. So I'm, I think this is probably a minor one. I'm going to say just thumbs up for myself but if there's no objections I'm going to merge this one. Oops. I don't know what just happened. So the next one is this best practice that you and I put in but there's been a lot of comments I think. So no plus ones, we have things to respond to. Okay, so Jeffrey and Ian are both not here. This one was a wording change just trying to make the summary a little easier to understand. Let's see, and Jeffrey says yes so I'm going to update that one. So the summary would be containers have a list of their own users and a bit of the host system, one of which is you at zero or the root user containers should run processes as a user other than root, which makes it easier to run these images securely. I'm just going to accept that for Ian since he plus one day and going down Victor application bug. Okay, so this is around goals. So opinion application bugs and generic term which cover application bugs or bugs are a generic term which cover many aspects. As far as I understand yet as far as I understand the main idea is to reduce the attack surface of by limiting permission. So this update was, I think, removing the behavior of applications when bugs occurs and in seem to not agree. And I also, I guess, disagree with the change. Because the, you could have non security issues but if there's, if you have root in a container and just something, some bug or anything occurs, then the application could do more problems because it's less restricted without being malicious or causing like a potential access to something maybe it just doesn't behave properly or you have data corruption or whatever else is a result of that.  All right. So I'm going to resolve it so that we can move forward. Unless my only comment is the British spelling of behavior. You like it. I, we haven't decided on the standard so I think so far we've been mixing English is, I think everybody will be fine with it. When that's decided we can go through and updated everywhere. All right. All right, so Jeffrey, I think talking about the way the goals section, it's I'm going to kind of scroll because you got to see the whole thing here. So the goals section, I think it was more of a formatting he verbalize this on the call and then added a comment as well. That it wasn't formatting way to see it as goals. I think was the main thing. And so I split it out. The where the reworded it. So this bottom line he's commented that's a goal avoid compromise up causing more damage so I took the way the Senate structure was improve the security and behavior of application when bugs occur. Added the defense in depth strategy against external compromises and then we have avoid compromised apps causing more damage. I think I'll have to delete a maybe this extra space so that they'll just be one after another. But that's the idea there. Can I ask a question. Yeah. In your sentence improve the security and behavior applications. Why is qualified to live and bug circle. Sorry, can you repeat the last why is what. So why qualify that same, you know that phrase by when bugs occur that phrase when bugs occur is not necessary. Okay. I think by itself we want to improve the security and behavior of applications. Yeah, that sounds good to me. Second thing is that this is replacing the root user. And that issue is still not addressed. You don't you want minimum or least you want to follow the privilege, these privilege principle right. And I think that should be captured. Because it says avoiding the root user in containers and you're replacing that with these two command or two principles but it's still not covers the root user. All right. I guess we were the summary captures not here. The goals. Yeah. Understood so the summary covers that motivation refers to the user. And I guess within, if you take the context of all of that and maybe the next sections on that like the proposal section. Then you get how are we going to do it so the whole best practices about don't use the right user. So it seemed like it may not be necessary to say, it's not the best practice is to avoid using the user, but the goal is to use the user. That's a way to get to the goals. Yeah. And you could also introduce one of the goals is use principle of least privilege. Okay, I got maybe let me. I'm going to adjust this one. And then, yeah, approve, improve the security favor when a box occur I agree with maybe improve the security behavior of applications. Okay, so that's okay. Sorry, go ahead. Yeah, this does read a little bit strange to me because these goals. They are so the general. And, and if we really do want to apply that principle I mean there are all these aspects that have well beyond root, you know, well if you're using another user have you given it full permissions to do anything at once it might as well be root are all your files set with attributes that allow any user to write them for example there's really narrowly focus here and but but the goals on the other hand are really really broad it sounds kind of strange. I tell I agree that we're going to have, maybe we could say duplication or overlap. However you want to see it between best practices and use cases. It's just known, and we may be able to share more as we go on and say here's some general information like the glossary. But we're not trying to get it perfect between them to get started. So if we have something general and then have another best practice based on least privilege, it may have some of the same goals. And right now I think we just recognize that and that's okay. If we have a specific goal though tell that you can think of or anyone else can think of that we can say oh if you do know root here's a very specific goal that's just applicable that that's great we can put it in. Well I kind of think your original wording was closest it wasn't written as a goal. But that captures it right it directly addresses roots. I think if we write goals that don't talk about roots, they just seem out of place to me. Yeah, but the no routine containers basically helps achieve the goals that are being listed. So improving security and behavior is a very good goal. And it, you know, no routine containers contributes to work. No routine containers also contributes to defense in depth if you will, as well as the least, least privilege. So what about using improvement the security and behavior applications by reducing the privilege of the container so something like that. Yeah, that works. So something like this, avoiding or in containers can help to improve the security and behavior of applications out of the fence and debt strategy against compromises avoid compromise apps causing more damage. How does it avoid compromised apps. I'm sorry. How does no routine containers avoid compromise apps. It helps to avoid compromise apps causing more damage so if you have an applicant, if you have an applicant. You, you understand. Yeah, I understand just that the promise missing avoid compromise the apps from causing more damage. Oh, all right. Let me go ahead and cancel. Yes. I think like that. Plus, I'm going to delete the extra line at a dash avoid compromise apps from outs from causing more damage. Yeah, that's what you're saying to say right. Yes. So just to underscore the point I was making I think this is the goal. This is the closest thing to what route provides. The other ones are just so general this this is what route does right route helps avoid compromise apps from causing more damage. And improves the security and behavior of applications right. Did you think that we have to specify where the damage is like in the host or like just in general. It shouldn't be the host otherwise there's something very wrong with your container technology. Or you're running in a privileged container which is another problem that we're not talking about here. But but we're assuming here that the container works and really containerizes. So it kind of things that route can do very much depend on what's running in the container so files, networking, anything, root can do anything it wants right. Normally, app uses a route to change IP tables and send information to the wrong place, something silly like that. Or of course change files. All right. So here's how it looks right now. Avoiding written containers can help to, and this is high level, then tell improve the security and behavior of applications so this will be what we could say a high level goal. Added a defense and depth strategy against external compromises. Again high level tied in with all the other work we can do, and then a specific avoid compromise apps from causing more damage. All right, if you have more suggestions please add it as a suggest commit. Let's see so the next is under the proposal comments looks like. I'll just read it for those who haven't seen it when building a container the container should be built to run its processes as an on route user set up s ID processes should not be required to do the work inside a container. This is the best practice. The root user is a container, the root user in a container has fewer rights and is distinct from the platforms route. The containerization process includes a user using a C group user C group which means the containers users are distinct from the platforms users and do not include the most dangerous elevated rights. So Victor you talked about this is the case for the mapping from the container from the platform, if it's actually enabled. And Ian was saying maybe we should talk about best practices that may be a platform type of best practice that you should do that and always enforce it. And I made a change here, Victor, and it looks like you did something an exception to that would be separation container runtime is not using username spaces, but it looks like you've made another change. Yeah, well, I was just trying to clarify the first thing which is talking about rights and units current capabilities. The first thing that you mentioned at the beginning. More like, yeah. So I guess it's more accurate I think. All right, so it sounds like you're doing just an alternative suggestion. So I tried to add it as an exception. And you just it looks like you're writing in a little different, but less words which includes two groups. So you dropped all the C group stuff. Yeah, because the group or my understanding is like controlling like restricting the amount of CPU or memory, which is not changing the users or a mapping. All right. And then, and it's confusing you're correct and once fixing its username space not see groups so we use the wrong word but namespaces some see groups do very similar things. Okay, so I don't think he oops, I scrolled way too far. Ian is disagreeing. He didn't explicitly give a thumbs up but he's saying the words wrong so I'm going to say that sounds like agreement. And I'm good with committing this. Ian and I like submitted this best practice together I'm good with just taking this one. grammar it should be fewer instead of less has Okay, I'm going to go ahead and unless Victor, Victor, do you want to modify it right here and right here and put fewer. The right user in a container has fewer. Okay, and then I'll commit that and resolve this issue to be clear should we just say containers root user has your Linux kernel capabilities. Let me say that. Sounds like you're wanting to reward the start to make it clear. And you could add it right in here to the, as a comment to Pankai. Let me add it as a comment. Victor, did you update with the fewer. I'm not seeing it. I'm going to refresh again. Yep, there it is. The containers root user has fewer. No problem. Has fewer. I'll just write like that containers root user has fewer than external permissions and maybe distinct from platforms root. If the container runtime enables us username spaces. Yeah. It just makes it one is consistent and it's basically is like platforms root containers root. I probably not even put this in parentheses vector we could say maybe when containers or user has fewer Linux kernel permissions and maybe distinct from the platforms root when the container runtime enables username space is remit feature. Pankai. Can you make a suggest edit. All right. All right. I'm going to go ahead and go on. I resolved it, but I'll. That's everybody okay with that. Well, you can put it down and then we can check it out. We're trying to get down to the point where we can actually get plus ones. Right now we have. Updates. Let's say if, yeah, only place updates. All right, so let's go on. We'll come back to yours in a moment Pankai. So under trade off constraints caveats and any notes that's a big section header. Okay, so just some comments about other best practices. Okay, and just where that could go. And that's it. So there's not really any thing to add there. That one could be resolved. I'm going to leave it open, but I don't think it blocks. And Victor you have a CVE that you think is relevant. Well, yeah. Container breakout all versions. All right. Vulnerability militia container with minimal user action over its host currency binary gains root level code, some other things. Yeah, that sounds good just add it in. So this section is, it's under the notes area, just so that people can look at more info and we have references so that if someone's wondering why we're suggesting this is a best practice. What benefits and everything else. This is references so you can go read what folks and industry are doing. And to add that if you'll do a suggested it vector. But we're in the references. Yeah, just add it to the, I would say yes to the references yes to adding the references. All right, alternatives. So, we just put a couple of things in here I don't know that these are alternatives. There are things you might do. You're allowing or what you could do. Talked about rootless Victor you put this forward we talked about this a bit and kept on that a new cap to address some rootless stuff. And I think the comments were saying that this may be a little different from this best practice. There's no hasn't been any updates. I guess we could mention it if you think alternatives when mentioning the rootless and user nets, then you could do a suggest edit as well Victor if you, you think there's something that's helpful. Then I would just added this is suggest that it. I'm a little confused about this alternative section. We're talking about alternatives to applying the best practice or caveats or ways to mitigate that there's a there's a huge discussion that can be had here. Yeah, this would be alternatives to using the best practice. So we have the caveats and you're in here's problems you're going to see or notes where you go. Whatever other comments when you're using the best practice. And this is alternative paths. And it may not be necessary on every best practice but and we're not going to list all of them either, by the way. So the assumption here is that somebody is not able to apply the best practices so okay if you if you absolutely have to use roots. Here's what here's what you can do that could be close to that is that what we're saying. So it's like compromises rather than alternatives, because they're not alternatives to there is no alternative to not using root. You either use it or do not. Maybe, maybe alternative slash compromises for this section might be good. So if we, they're probably our best practices where you could have the same outcome with two different best practices, and maybe this one doesn't we're just saying, you're either going to use root or you're not. And if you don't need compromise, then here's some other paths to deal with it. I guess what I'm looking for is something like considerations right okay why. Why do you absolutely need to use root and if you do what can you do about it something something like that that that to me is where it could become useful. Do not run the container in privilege mode I guess that's what it means. Well, I, is that an alternative. It's, it's, it's a different approach to and then achieve something else. So again, going back to the goals. You know, if these are our alternative ways to achieve the goals are goals, some of them are extremely general right so if, if you're looking for an alternative way to make your application more secure. There are lots of other things we can suggest. Sure, so if we don't have anything specific, like, then we just leave it, we don't want to block this but if there's something like Victor saying using. An alternative slash compromises whatever we're going to say on this, then maybe one of them would be, if you must use root, you could take a look at using cotton containers which give more isolation, and then a link over and we don't talk about it in depth that should go somewhere else which may be literally like the project, or we may eventually have using caught best practices for using cotton containers and we go go take a look at this best practice, or something, you know. But that would be if you have a concrete one towel, then add it in. If you can't think of something right now, we can always come back later and do a PR against the public best practice. I guess I think that what he is writing here is very beneficial I kind of think that everything else we had in the document so far is to me, reads as kind of trivial I know we're picking on low hanging fruit here because we want to get something out. But it's it's fairly obvious most of it. I think where we can make a contribution is exactly in this. Well, if you can't run route. Here, here's an in depth discussion of how workarounds you know, rather than alternatives maybe another way to think of it is workarounds right you absolutely must run route. Here are a bunch of suggestions we have for for how you can work in that situation. Then suddenly the document becomes useful. Probably 100% I think that's the gist of this work group to find these to come up with this recommendation I mean saying you don't have to run route you don't need this work group to say that. But we as a work group I think we are responsibility should be analyzing why do network functions need route like, for example, if you need to create a raw socket for your crazy protocol. How do you do that just saying don't run route. Okay, so I don't can't use my protocol. So we need to discuss here ways that maybe Kata containers is one thing, maybe others but I agree with 100%. This is what we're here for to help people with solution, not just saying, giving them the don'ts but giving them the dues as well. Alright, so that that I agree with y'all and the idea then is, let's get the trivial ones in place so that we have a baseline. And then we go okay so what is this use case. Someone put for use case where we have a application where we say we really think we need root here. It's going to be against this best practice so what are the best practices for having a container with root, and we can analyze that. So I think tall suggestion to call this work around, I think should be adopted. Instead of alternatives worker on is a much better word. It's not even work around that's exactly like that's the whole thing that we're trying to define here it's not a worker on it's like the solution so the problem is you cannot run route and here's the solutions solutions that we are proposing for you. I wouldn't call them even work around and I would call them by recommendations or solutions or whatever. It's a work around to getting around some of the problems of running route right. So, or you know just run route sometimes running route is the alternative. It is not the end of the world to run route. Yeah, you have to understand what the, what the trade off sir. The best practice. So what we're talking about here is the best practice, not the exceptions. So in the best practice you should do no root. And now we say, but what if we have another use case where we say we must have some type of privileges. Maybe that means that you say, well you should, you're going to need route, and you, we suggest you run it in cotton containers, or you're going to need root, and we suggest that you split it off and run it somewhere. I don't know whatever that is, that's fine. It wouldn't be in this best practice. So we're not giving the solutions in this particular one for running route. That will be an additional document which we can leak in here. So we close those up, and we do the work on it. We can put whatever we want to call this section alternatives, or best practice, we can have another section best practices for when you need root, and we will link out to that, which will be a different document. That makes sense to me so so I guess I'm just going back to what I said that calling the section alternatives is. I don't understand it, but still, I wonder if we still need it even and if we do add things in the future we could add those sections but I'm suggesting we just remove this section. And Taylor regarding this section is just related to Kubernetes or just CNN in general, or I mean, for example, user remap is not supported by Kubernetes by now, but it is supported by Docker so maybe using user namespace remap can also mitigate that problem. But definitely it's not going to be, it's not supported by Kubernetes yet. All right, like the user nets is it's coming related practices. It's trying to find a word towel that fits what we're talking about here. This section is to point people to and other places you've, you're saying we're going through this and some people may agree not agree with the root or whatever hopefully we convince them for the case that can but for your case towel. And Ranny, you get to a point where you go we understand this is a best practice, but we have to do it so what do we do. I think this section is supposed to kind of point people somewhere else. And right now it would be very limited because we don't have anything else other than we can kind of point some stuff out. Related practices. Alternatives related practices. Is there some wording that could fit for pointing people that using cota containers, or does everyone agree with just deleting this whole section. Sorry. I just wanted to say Taylor you said you know in the future we can have more PRs. Let's just not waste time on it right now, remove it. If in the future we want to add something maybe the name would be more apparent once we actually have content. I want to see what Victor you come up with. And if I don't. If we're right now we don't have any plus ones but I were, we still need the use case. So maybe next week, if we don't have anything useful in here, Victor if you add anything then we can take a look. And I'll think about it tell for just deleting or not on the wording, but add a comment here. If you can tell on your thoughts like about the section and stuff so we'll be able to come back to that. Yes, sorry for just being critical without having an alternative solution. I think putting myself in the right things just target audience like whoever reads that. I mean if we just say you cannot use root. That's it. Okay. How much value did we bring to the end you to the audience. I mean if we say, okay you cannot use root, but here's some further reading or some suggesting to marry where you might start I think that's more powerful than just saying you cannot use root period, go figure it out. There's alternatives. There's like something you're saying or anywhere it's this is like it's suggestions. Yeah, I would say it is like further reading or where to go next it's don't leave the audience and the audience hanging like. To solve all the cases I guess what you're saying, Randy, the so complex we end up getting at a point where we don't make any progress. So, the end goal would be all of these when you're reading a best practice, and it doesn't apply to you. It would be great to have links to alternatives. Probably what that's going to happen is iterative for this. Suggestions for you want something like this for when you must use root, something like that. Yeah, but we don't. We're not ready there yet but that's what we want. I'm going to delete that for now. If y'all have any like related alternatives that's what the section be about drop it in here. I'm going to move on. Okay, we said test objectives. This didn't get. Oh, that was from the other one. So just updating it here. I added my comment. So this section is. Let's see. Oh, sorry. Do not run the container and privilege mode. Okay, I'm going to grab that one. That one's pretty straightforward. Commit this Victor that CVE. I can resolve that. And okay, I'm going to leave that up until we read more, but it looks like all of them. I think all of them have been resolved at this point. Except for that one section. There has fewer privileges. And maybe to sync from platforms route if the container runtime. I'm good with this. I think it's just rewarding. So this is still showing as a draft. Because we haven't added the user story, which we've been working on, but it's not. A linked in or added in. So that would be holding it from moving forward. But if folks can take a look and see if there's anything else. Outdated outdated. All right. We have five minutes left. And the book is out, I think until next week. Is there been any progress on the glossary towel? I don't think so. Kind of left it where it was. The problem is I think there are just discussions there that haven't been. Resolved. We can revisit and talk again. I've resolved a few that seem to me, seem to me to be resolved. But for some of them, I'm not sure everybody is completely on board. So, um, yeah. We don't have to have agreement if we can have a. If we feel like everybody's been heard and we're. I don't think there's a point to accept it. I don't think there's a point at a point to accept it. Even if we disagree, or we had a point to accept it as is where we can update it. So this physical network function, PNF. Definition. There's been a lot of talk about it, but no suggest edits. And I don't think any. Right. Yeah. That's why I'm stuck. That's why I'm stuck a little bit. I feel like a lot of these conversations are just. Conversations. Yeah. Yeah. So this one, one where. Do we have, are there any objections to resolving it for now, as is to keep. And then we can go update the glossary later. If there's changes. If there's no objection, I'm going to resolve it. Also regarding the glossary. We have another discussion. For some networking terms for the glossary. And this hasn't moved for, for a while. There's no objections on the terms currently. So if you people can just review it a bit, and maybe we can create an extra PR for that. If everybody is on board with those terms, I have pasted the link to the, to the agenda. So, yeah. Right. That actually seems sensible to me to have the discussion discussions. And then maybe create a PR from that. I don't know. I mean, we can still, I'm not trying to push my PR through, but we can accept my PR and just treat it as a draft, you know, and continue, continue iterating. Yeah, I agree. I agree with that. I'm going to resolve this one, the PNF. And let's go ahead. Yes. For talking on the discussion board. That's what those are for. If there's someone's unhappy with something that's being merged, please continue on the discussion board or create a new PR. And Demetrius, if, if you have something specific that you want to add, ideally glossary terms, we want to add the minimal amount necessary at any given PR so that we can get it through sooner. But if you have one, then please put that in. I've gone ahead and resolve the. Physical network function. I'm going to work through some of these. Let's see what's next. The cloudified. Um, That was the most controversial, but the, the, the one problem with removing this cloudified network function term. Um, it, it, I, and the, and the KNF term, I refer to this. I use it as a classification and here I explain kind of why that is needed. I didn't have a real response to my response. So I, um, Anyway, I feel, I feel like it's still just unresolved. Um, and we, we are at the top of the hour. I can suggest maybe we can put this at the top of the agenda for next time and really just try to finally, finally close this. Sounds good. Let's do that. And, um, please. Check out the, try to, I guess, add any comments on ones that you fill or if you're good to go forward with any given one, then give it a plus one as the work in progress. And if anyone else has comments and please add them, and we'll continue with that one. Continue with glossary. I'll just say that I think that the biggest block right now is in fact, you Taylor, you, you had the biggest objection to the classification, clarified network function term and, uh, maybe we can just discuss privately and see if, if, if there's a, some compromise we can find. Sure. And I can add more comments myself to it. Yeah, that's, that's my worry that the comments just start getting very, very long, long speeches about, uh, the, the, the, the, the short term. So, uh, I feel like we're in a bit of an impasse there. So, um, But yeah, we could, we can discuss this next time. Sorry. I don't want to take more time. People have to go. Thanks everyone. See y'all next week. Same time. Thanks everyone.


With your look around the Air Force, I'm Senior Airman Naomi Sabornin. The B-21 Raider rolled out in a formal unveiling ceremony, giving the public a first look at the Air Force's new long-range strike bomber. It's a state-of-the-art aircraft that Secretary of Defense Lloyd J. Austin III says is the embodiment of America's determination to defend the Republic. The B-21 Raider is the first strategic bomber in more than three decades. It is a testament to America's enduring advantages in ingenuity and innovation. And it's proof of the department's long-term commitment to building advanced capabilities that will fortify America's ability to deter aggression today and into the future. The Raider is still several years from being operational, but it will eventually replace the B-1 Lancer and B-2 Spirit bombers currently in use. For the first time ever, three airmen got to fly the Lyft HEXA, an electric vertical takeoff and landing aircraft. The flight was part of a two-week familiarization program. The participants had prior experience with helicopters. The successful flight validated HEXA training for the uncrewed electric vehicle. The Lyft HEXA is one instance where the Air Force is leveraging civilian partnerships for future military use. The Air Force Research Laboratory launched a multi-million dollar, multi-year, multi-industry partnership to turn flowers into tires. The plan is to extract natural rubber from the crushed roots of a specific dandelion species as an alternative to relying on imported rubber from rubber trees. Industry experts say the demand for natural rubber is about 10 years away from exceeding supply, and the Air Force needs a secure supply chain of rubber, a critical material for the production of aircraft tires. The domestically sourced natural rubber supply chain is expected to increase in the next five years, and that's your look around the Air Force.


So, good morning everyone and welcome to this session on global health and pandemics. This is the fourth time we have a session on pandemics. The first one was a virtual session in 2020, you may remember. Before anything, I'd like to thank Thierry de Montbriale. Thank you, Madame Kwon, for inviting us and Madame Minister, warmly thank the government of the UAE for the wonderful welcome and hosting this conference. We have an excellent panel of speakers today with broad expertise in global health and geopolitics. But before we start, I'd like to show one slide for everyone to remember about key figures on COVID-19 as the political attention and the public opinion attention is rapidly waning. What people often call the cycle of panic and neglect, we are actually in a phase of neglect. And that's why entitled the slide, COVID-19, are we being dismissive? So, let's not forget that the COVID-19 pandemic has been the worst combined health and socioeconomic crisis in living memory. It has infected at least 250 million people across the globe and the global death toll is estimated to be 27 between 18 and 33 million people. At the highest point of the pandemic, 90% of school children across the world were unable to attend school. At least 150 million people have been pushed to extreme poverty and the economic cost has been huge, estimated by the IMF at being $14 trillion to be lost in the period 2024, the toughest shock to the global economy since World War II. And the last point on the slide is that the pandemic is not over. And it continues to have a profound impact on the lives and livelihoods for many people, millions of people with what we call long COVID, but also as the economic recovery, whereas it somehow is taking place in the high income countries. It still is very slow in recovery in the poorest countries. So we'll discuss today about where we are with the pandemic and which are the perspectives of preparing ourselves to a next pandemic. And the question that is posed today is, are we ready for a next pandemic?


Hello! Recently I returned from a trip to Nevada where I work as a contractor so I go out and stake claims for mining companies, but while I'm out there I look for cool specimens that I can bring back and enjoy and share with you. So I'd like to show you what I found. I have a few that I decided to keep. This one, I don't know how well you can tell the color in here, but it's a very interesting dark, dark green with kind of this orange-brown modeling through it, and it's kind of an interesting agate. Just thought it was cool, but I might be able to do some with it. This right here is a piece of common opal. It's got a very nice pink flesh color to it with a nice rim. Might be able to do something with that. And the ones I like the most are some pieces of Wonderstone. There was a ton of Wonderstone up there, but these were the two that I liked that I felt like hiking back with. It is a bit of a hike, and what you come back with you have to carry so these are the ones I decided to come back with. Very nice pieces of Wonderstone. I love how nicely they broke off.


pairs I'm going to call them smooth and F pairs These are pairs X and D and I will be writing S and P in short throughout my talk where X is a complex smooth projective variety of dimension M and D at least for my talk will be an anti-canonical divisor Which is effective reduced and normal crossings and I'm going to be writing all the way up to DR For some positive integer DR for it's a reducible components And I want to insist that each irreducible component DI is Moved so it has no negative intersection with any curve in in X examples So in dimension one I can take X to be the projective line and D to be the union of zero and infinity Just north and south the real sphere in this case M is equal to one and R is equal to two Or for one example two for Some more exciting action. I can take X to be the projective plane and D to be I Can choose if D is irreducible since I'm insisting that each irreducible component is smooth and D is anti-canonical Then D has to be a smooth cubic Or I can consider a two component case I can take D to be the union of a conic and The line that's not tangent to it or I could take D to be the union of the toric prime divisors of of the plane 1 2 3 of the coordinate axis Some piece of jargon that's not at all standard, but it's just something that I will employ For simplicity during my talk is that I'm gonna call a smooth and F pair X D Toric if X is and D is a Toric boundary T is the big Torus orbit in X and I'm gonna call it lohenga if X is a surface and D is singular so in particular since the irreducible case is always smooth This will lead to R being greater than one so example one is Toric The last example is Toric and lohenga The middle one is lohenga, but not Toric at a top one is neither Toric nor lohenga Have I butchered the Dutch pronunciation of the name enough? I'm asking for to the Dutchman in the audience Now the title that I've just raised is So basically the mantra of this talk is that I will want to relate a pair of enumerative theories of these pairs X and D so X a variety and D a divisor with special properties inside X and Well before I do it, let me forget for a second about the divisor all together and remind you about Gramm-Witton theory It's just a bit of a primer about rational from a Witton theory X So informally what I would like to do is if I have a collection of close-up varieties One to some number n inside X. I would like to attach to it some Count is informally the count of Degree D rational curves Passing through my given collection of cycles B Well the Gramm-Witton way of doing it is to consider parametrized curves So to X we attach the modular space M0 and bar Xd Which is the modular space of stable maps to X So I consider equivalent classes of maps from a source core curve C with n markings I Want the curve to be rational and I want The map to be degree D so push forward of fundamental cycle of C to be equal to D and I consider this up to automorphisms of the domain map and The bar over here, which I'm going to extend over here as well Is that I'm considering a compactification of the space where this map where this curve is smooth by allowing ordinary double points on the domain curve and I will request that the map is only allowed to contract components when they have a finite automorphism group now This modulate space is It has many downsides in general it's often not nice in the sense of lotters thought before But this compactification does at least the job of giving you something compact. So it's a proper Dilling-Monfer stack With an expected dimension equal to the dimension of X minus 3 Plus the anti canonical degree of the map plus the number of punctures and In the smoothness case, this is often as close as possible as being unobstructed. So it is actually nice in In the cases that we will consider but regardless it supports in general a virtual fundamental class living in pure homological degree equals to twice this expected dimension and my thought for counting nxd So this is nxd of say B nxd of B is given by an integral against this virtual fundamental class pullbacks of Poincare duals to my cycles by evaluation morphisms Yes, no, no at some point There's there's a word refined in brackets that you should understand as how you're genius in some sense And not in other senses of refinance. No everything is unit zero to this point Did I put the genius somewhere by mistake? I think I've been consistent Okay, so this knew nothing about the divisor D and that's what I'm going to introduce now so the first enumerative theory that I'm going to touch to a Smith-Nef pair xd is the local again g to zero Drama with the theory what I do with D is I construct a Vector bundle over x which is given by the sum of the Dual line bundles to each component of D xd local is the definition the total space of Our sum on to R the example one of p1 minus 2 points I'm considering the total sum of o minus 1 plus o minus 1 on p1. That's the result corner fold example number 2 was D this with cubic so I have o minus 3 and p2 there are two examples where o minus 1 plus o minus 2 and o minus 1 plus o minus 1 plus o minus 1 So this is a Kalbiya m plus our fault because D is anti-canonical and As I did before I would like to compute numbers again informally count Degree D curves rational curves in this total space when well a stable map To this total space is the same thing as a stable map to to the zero section at least when the intersection with The boundary divisors are Generic what reason is that since each of these guys Neff My stable maps are not allowed to deform holomorphically of the zero section There's there are just no sections before doing that So it's a scheme this modular space is exacted modular space that we have without the bundle however the the two obstruction theories differ and And This is codified by the fact that there's a canonical obstruction bundle on the modular space of stable maps to x the base His fiber at a smooth model I point like Curve C map phi and marking speed is the H1 pullback by phi of this this vector bundle and The virtual fundamental class in this case is defined as the intersection of the virtual fundamental class for the theory of the base with the top turn class of this obstruction local m0 and bar xd were intersected with the top turn class xd and Just by simple counting off the number of will dimensional this vector space just by certain quality you're cutting down the expected dimension by the anti canonical degree minus the rank of this vector dimension is Is m plus r minus 3 there's a second thing that I can do with my divisor and It's imposed sort of boundary conditions to my map and consider the relative theory of X to this divisor in this case informally I'm interested in a different set of numbers There's a b over here, and there's a through b over here. I want to count the numbers of degree d rational curves in X Through b with the condition that they intersect each component of the boundary divisor in a unique point of Maximum content order now there was no issue with properness in the ordinary case and There was a for theory no issue with properness in this local case It's every all the action was happening in the theory of the base But the moment you consider relative stable maps you'll run in the problem of having a compact modulized space So if you if you have a relative stable map with some prescribed Order of tangency at a divisor you have a sequence of those You can have a limiting stable map where some of the components of your curve fall entirely into the divisor so that in the limit the notion of Specifying a tangency doesn't make any sense and so this has been a source of Major headaches both in the algebraic and symplectic category and one And possibly the only one in the case in which we have more components Way to deal with it is to view X Through the lenses of log geometry So you will be with you X as a log scheme With a divisorial log structure induced by D Now somehow this means that informally you come to terms with the fact that you can have some components falling into the divisor But you remember the fact that you have some some contact order with this divisor by some homomorphism of ghost sheeps in the setting of log geometry If you're unfamiliar with this, I'm just gonna list the upshots of dealing with this modular Compactification, so there's a modular space space of log stable maps xd degree D With plenty of nice properties well first of all this is proper and Of expected dimension the same as that of the local theory Under some some canonical lift of a notional stable map to the log world and If X is log smooth, which is the case for us it supports a Natural perfect obstruction theory giving you a virtual fundamental class of the expected dimension And drama with an invariance relative drama with an invariance can be the form in terms of by integration against this Again as was done for what the local and the global theory Okay, so let me wrap up since I'm like halfway through my talk I got this fair given by a variety and a divisor in it and Starting from them from that I do two very different things in one case the divisor defines an embedding into higher dimensional Non-compact Calabi all manifolds and I look at the grama with them theory of this guy with no strings attached and The other thing that I do with my divisor is that I impose in quotation marks boundary conditions So I just impose contact orders at each of the components of this boundary divisor And I'm just looking at the setting in which this This tangency condition is maximum just a unique point of maximal contact order for each device I Priority there's nothing whatsoever that These two halves of the blackboard have to do with each other Other than depending both by the same ingredients and having the same expected dimension so somewhat surprisingly it was proposed towards the Well less than two years ago That there is indeed the universal relation Between the local and the relative grama with them counts. So conjecture log local principle of the title of the talk and this is due to vanguarel Graber and root dot is that there's a universal relation these two Sets of invariance differ by universal factor. The relative invariance are multiple multiples by a factor given by Minus one to the intersection of D With my jth component of the divisor times d times dj Times the local in there Before I give arguments pro and against and you will only hear the pro side because there's no against until now About whether this is true or not one thing to to notice is that there's a This is an identity between something relatively new this login variants That I was talking about that have a tendency to be closer to being a numeracy than ordinary grama with an invariance With something that's pretty much old at least to well studied for more than two decades And for which we know plenty of information from the calculational point of view via local mirror symmetry So there's a lot of power that we have over here that we can transfer to Do actual calculations that are pretty scarce on the left-hand side If this were true, then is it true well in the in the case in which the divisor is smooth This was proved by vanguarel Graber root dot in the original paper and And Then two papers appeared on on the archive last month on the general case and and they're pretty much orthogonal in the methods So first of all, I'm very happy to Give a plug to a beautiful work of nabijou and Ranganathan in August this year where They proved the conjecture with a mild positivity assumption on on the eyes So the de eyes have to be hyperplaced actions and that's essentially by Clever read reducing to the R equals one case and then use that the original FGGR theorem and So that that's about establishing the equality and in an orthogonal direction. There's a Rather more combinatorial result Which is what we obtained with pyrrhic busso myself and Where we don't prove the quality we just solve the full gram-width in theory engine is zero for the left and the right-hand side in a variety of cases There's there's enough.  I'm not up to speed entirely with the literature. So you're asking whether there's a log version of the Graber ponderic on the virtual localization Without any extra effort to be put and actually don't know it No, I don't know. I don't know. So what we do is Probably need slides to to present the statement of the theory It's going to be a little colloquial, but basically the result is that we can solve both the log and the local Grammar-width in theory is in June 0 for xd either Toric, so we actually compute both sides of the correspondence and solve the theory completely and Once you solve the theory can ask yourself is the principle true and The answer is yes So start start holds for the resulting invariance Now the way this we have the complete solution of both sides of the of the Correspondence is on the left-hand side, there's a tropical correspondence theory, which is a general thing in in log-gram-width in theory or in log geometry and This log-gram-width in counts are reduced to tropical curve counts with some multiplicity And what's special about these smooth and F pairs is that the tropical multiplicity can be determined in close form So I should probably add this in close form. So we have close form formulas for these invariants as functions of a degree and say the weights in the g it presentation of these guys and On the local side, there are equilibrium theorems of codes and given tile that we can adapt to our case and we can extend to To the full B quantum comology using some vanishing properties of the worksheet corrections to the mirror maps for for these special targets so there's just this Random observation that things are This smooth and F condition is enough to make things calculable on both sides. So a This is Probably bound to work In larger generality and B what we do prove is that we can drop the smoothness Condition on X or D. So probably pretty much everything I said works for variety replaced by Dling month for stack. This is something that we prove in the Toric case so this is bound to to work more generally and Speaking of Generalizations, there's since it was a request in this case All this story is lives By construction in junior zero. Is there any hope of extending this to the to the higher genus theory? Now, this is basically some It started off with some sort of annoying We're exciting and annoying result and I'm going to restrict my Discussion the case in which XD is a locking up here with two components of the boundary Now the the expected dimension in this case is What's M plus R? Minus 3 plus N So M is 2 and R is 2. That's an M plus 1 for the junior zero theory and for the higher genus theory This grows linearly and we have a plus G That enters in the expected dimension so if you want to define some Dimension zero virtual count what one typically does in grommet Whitton theory is that you add extra Incidents conditions so that you reduce to something that that gives you a number So that's something that you can do But I will want to do something else so for example if I start with one mark point and in junior zero I Have a two-dimensional moduli space so I can offset that by an insertion of a punk or a dual of a point and in juniors G Normally, I would have to add extra insertions, but instead of doing that I Consider something different which is I define to be as the integral over the virtual fundamental class in juniors G with one mark point of X and D and I retain my insertion of the point and I need something that's Degree G to get something that matches up with the dimension of the virtual fundamental class And my choice will be to use minus G times lambda G So the top-turn class of the hodge bundle This mom for its So I've got a vector bundle on on this moduli space whose fiber at a smooth moduli point is the space of holomorphic differentials on my curve That's a rank G vector bundle and I think it's it's top-turn class that I intersect with that now So Has a remarkable Prediction, which is actually a theorem About what this genus gene variants should look like in terms of the gene zero one or an appropriate modification of the gene zero one and The statement is that this is the log to G minus one to G minus two Q Taylor coefficient at Q equals one so at log Q equals zero of Some explicit Explicitly computable Rational function of Q sorry Q Q plus minus one and the way you move to from the genus zero invariance to the all genus invariance and in fact to this all generating function is by taking the tropical count that computes for you the genus zero invariance and Replacing the tropical multiplicity with its Q n log. So there's actually a natural tower. There's a actual Natural generating functions for the higher genus theory that live wholly on the locals on the log side and in view of the log local principle You are compelled to ask yourself whether there's any local interpretation for this relative higher genus relative invariance and This has put some pressure on the on the local side of this collaboration aka yours truly here because there is it's it's hard to come with a natural definition of What this refined higher genus local invariance? what they should be and One problem with that is that if you go to higher genus Instead of increasing the dimension your expected dimension of the modular space as you did for the case of the surface Your expected dimension here becomes negative As soon as genus is greater than one so there are no invariance to play with in in the first place So the natural guess I will take higher genus local invariance that just doesn't work because there's nothing There in the first place I'm not on the Calabi out free for because I'm on a surface and I'm at I have our equals to so I'm on a Calabi out fourfold That's exactly So in a Calabi out fourfold you have either point insertions on the surface in genus zero or Unpointed invariance in genus one and then nothing in higher genus So with well the answer to this is we've come up with three refinements They're all supposed to coincide One dates from Thursday night, so I'm I will not be so brazen as to just give a talk about that today One is a couple of weeks old, so that's not very mature, but I will give her a mark at the end about that and So let me give you the more mature one Which is what we call Summiting properly The refined Well, the conjecture is as follows If you take a locking up air With two components for the boundary divisor you can attach to this fourfold a pair Yd D Yd is a Toric Calabi out threefold and LD is a Toric special Lagrangian brain inside Yd such that the following holds First of all, they are genus zero local invariance What insertion of a point are equal to the Generating function of holomorphic discs in Yd with boundary on this Lagrangian so we have its Dimension zero virtual counting problem here and in this Calabi out three setting even when we consider the open sector This remains genus zero for for all general. So in particular we can ask your ask ourselves What if we construct generating functions window of Q Such that These are defined To be the genus G open-gramma weighting counts in Yd LD and The second condition So the first needs to hold and the second is that the relative invariance of the pair xd in D are Given by We have the same sign factor that we had in the unrefined case and The intersection multiplicity is that we have in the unrefined correspondence get cutiform. So I take the Q analog of this number and I multiply With my refined local invariance I Guess I should I have 15 minutes. I'm going to use five to motivate this I Have no geometric intuition why this has to be true But there's some well-defined thought process that leads to postulate this sort of correspondence and reason is Well in one word is four-dimensional Calabi of four geometric engineering Plus some generalized open-closed string duality Which is due to Petter Meyer Almost 20 years ago. So one way to one time on her way of Try to dig out this sort of statements and in the context of mirror symmetry is to See what these things compute in real life for example in some target space interpretation of The topological string theory and see how you can relay them through some some chain of physical dualities Now if you want to ask yourself if I take a calabi out for and I take a type 2a Compactification on a calabi out for well if I did it with a calabi out 3 we know that the For example gauge theory pre-potentials can be computed by geometric engineering on just as an effective theory coming down from this Calabi out 3 compactification So if we try and play the same game in by compactifying down from 10 to 2 dimension We get a holomorphic super potential term Computed on on an effective and equals to two theory Attached to this calabi out well the fact that you're compactifying on something non-compact just means that you have some non-gravitational theory you're essentially pushing the the Planck mass of infinity and reduced to some Honest and equals to two gauge theory But there's not the only way where you can compute topological couplings in in a string compactification You can consider Wrapping d4 brains on special Lagrangian And you look at what happens on on the transverse direction, which is two-dimensional And again the discample you compute exactly the same type of term in the effective action But more over there's a there's a whole tower of couplings With the gravitational chiral super field, which you don't see in this four-dimensional perspective Which is why we don't know how to give a Just just purely in terms of the geometry of this calabi or for an interpretation for these invariants But we can't do it through through open grommet within theory on on this special Lagrangians and Well a fact is that to any to any XD log We can indeed associate a pair yd LD by partially inverting the my recipe for going the other way round and Once you have that Last five minutes may or may not have made the blindest bit of a sense to you. That's fine What I have is that for some irrational reasons or not I postulate that there's an identity between this refined local invariance computer in terms of open grommet width and counts and their relative invariance with insertions of higher genus Lambda classes It's a statement. Is it true or not? Well, you can prove it or disprove it and one Piece of evidence towards the fact that it is true is that it is true we can actually check that all this higher genus open curve counting in The calabi o3 pair with special Lagrangians attached to a the local space from a locking up pair Match with this prescription to with with a login variance The two other refinements I don't have enough time and it's it's too young a subject For me to actually tell you something sensible about it Let me just conclude about so one When I wrote down the unrefined log local principle, I Was saying that the relative invariance are something for which we don't have any almost any explicit calculation so far and We can the use of the principle is that we can transfer all our local mirror symmetry wisdom from 1999 onwards over to the left-hand side and The obvious question is whether we can do the same at this refined higher genus level. Do we know more? Or do we know less about this higher genus setting? in this restricted case of two two component locking up pairs and Well, the answer is quite I'm just gonna keep it brief there's There's a lot of structure that has been attached to the local theory of Toric Calabiel three-folds with the grunges in them after the work of Well, I'll breached Marko's and and collaborators in in the last 15 years in particular whatever applies to the generating function of open ground weight tuning variance for this Toric three-folds can be transported over by this But the refined local principle log local principle to the log side. So in particular To any locking up pair we can attach a matrix model a crystal model a tile function of some integrable hierarchy, which is a reduction of the two-toda hierarchy and family of spectral curves such that the Modeling the b-model Conjecture slash here and now after work of Melissa Liu Fong and Jew Computes the log grung with an invariance with this lambda insert is at higher genus. It's just something that cannot have been Presumably predicted without any sort of relation with this parent theory Another thing The refined principle accomplishes is that They're a strict Integrality Statements that hold true for this open grung weighting counts in terms of open gopacum or Vaffin variance Well an open version of gopacum or Vaffin variance So it was conjectured by by Pierre egg in That's right. Yeah It was conjectured by Pierre egg that generating function of log grung with an invariance in a different setting when you have only one contact order at naturally the form of Oguri Vaffa partition functions, so the log grung with an invariance were naturally Open bps invariance for some putative theory of count curve counting theory of three-folds That it was difficult to visualize What the principle does is well It gives you that theory and it gives you the identification with this actual open bps invariance And this also holds true for the closed theory of the fourfold itself So in particular if we can establish mathematically an integrality statement about these open bps invariance We can prove Integrality statements at a level of this local theory for the fourfold and this was this is a conjecture of Albrecht with Rahul Pundari Pande in 2008 where they proposed some definition in terms of multi covering formulas of closed bps invariance for this for fourfolds and Whatever we can establish at the level of the threefold with a brain we can transport over to the fourfold theory and it actually turns out That we actually can because a further piece of free information that we get from the from the log local principle is that there's naturally a quiver theory and An analog of the not squivers correspondence This follows by work of Kucharski Reineke and Sulkowski Such that the unrefined DT invariance coincide with the unrefined log invariance and in particular with the closed Gopakumar Vafa putative integral invariance in the middle so we can actually prove this conjecture for fourfolds and I like to use some of the time to Tell you something about so this in particular this this relation with DT theory Comes with for free with a with a further refinement by consider the motivic story on the DT side and We have very encouraging signals that this actually matches the open ground with the story that I presented before And yeah, I guess I could stop here. Thank you


So my beautiful people I am back with another out and ring video and a short but sweet one today guys showcasing to you and that's your mask I Got by accident had no idea it was in the game It's super unique. It's madlocking and it's called the black Dumpling what the heck is all this about as it going guys my name's DP Jane if you do enjoy the video Even I like who helps out and if you like what you see you want to see more Be sure to subscribe. Okay, so the mask itself the black dumping crazy name Okay, so as you can see here raises attack power when aware of suffers from madness. So that's actually real unique Seriously unique and I can I know there's some thoughts going through some people's heads watching this thinking Yeah, I can actually do with a mask. I like that But yeah, how it's got like I said up ain't no use to me I know it will be definitely useful somebody out there. We're not not useful me at the minute. I'm gonna create a madness But it probably will be okay. So where this is obtained. It's pretty simple Well, firstly, you need to come to the temple of eagerly this place is on that volcano man Basically, yeah, yeah, I mean a lot of people have been here already. If you don't know how to get here guys I'll post a link in the video description to a previous guide. I made it's like 30 secret areas of hidden paths That will bring you to here. There's actual God's skin Is it God's skin noble God skin jewel bus here? You have to take out once you take them out. You'll get the actual Grace point, but you actually don't need the grace point to actually get this thing. I'm just using it from this Direction, you know, so you want to come out here In fact, if you actually the first time you come to this area come up these steps guys And you come into the room where the bus is you don't need to go into the bus. It's turn this way turn left Turn left guys, and then Activate the bridge you have to activate the bridge the bridge will come down or come off I can't remember and then go across it now There may be more of these ads somewhere else in the game All I can say is and showcase you guys is where it dropped from me. That's simple as that I mean if anyone else knows where there's more of these ads in this area or in this game even Which ain't such a pain to get to please let everybody else know down below in the comment section guys That's what we gotta do guys gotta help each other Given all the way down here I'm past all these trying to dodge this big old dirty bird. He's gonna try and put me in the stomach. No, no, no Leave me alone. I've been down here guys. Just keep running down here I'm past these dogs. Don't worry about them. That's just about them. And you'll see this big old but it looks like a Wayne manna, but yeah, that front door actually won't be open yet. She'll have to open that front door Which I'll show you where to go and how to do that So you want to jump off? Leave me alone. Leave me alone Well, you come down this way. This one is a ladder here. Yep. This is the way almost look up and come up this way guys If you have to jump down into the back door, let me have a quick look probably Is it down here? Yeah, it's down there. So you need to jump down onto that now probably take some damage You can't remember. Oh, no, you should be good And you're coming through this way and it adds basically guys are roaming around this area And like I said, I was just wondering around Is it this area actually? Well, let me get rid of him.  Get out of here. Get out of here. It's this area. There's a way out of you somewhere. Is it there? Yep, you can go through that way. There we go And now we'll end up down here guys and you go through this door and you'll see a lot of these like weird I don't think that's one but they are There's one. There's one right there guys. See me up Drop me.  Get out of here big boy So, yep, there's a lot of the miniseries guys tons of them So yeah, what you want to do guys is farming obviously silver tier helmet mask and Silver scarab helps that as well.  I've never had this helmet drop It's obviously a drop But it's super unique. So yeah guys, it's definitely worth your time. Your farming is 100% Yes, that's how you get the black dumping mask. Absolutely amazing I don't there's a grace point in here. If there is I haven't found it yet. Let's just run up here Just to see if there's any more of these ads up here Probably not. Oh, I don't know. I like one That isn't right. Yeah, there isn't a grace point in here. I don't think but yeah guys That's the only way and I know which you can farm this uh black jumping mask Hey, like I said, if anybody else knows, please let everybody else know down below Give me a comment section because this is gonna be a useful mask for many many people guys and there we have it Another short but sweet video on how to get this wild Black dumpling mask. Wow Craziness and there we have it guys guys. If you enjoyed the video, leave a like really helps out If you like what you see and want to see more out of the ring be sure to subscribe and hopefully people I will see you on that next One