All right, thanks for coming and my name is Carol Chen.  This is, I think, the last session for the day for this track. So I thank all of you for being here and also for Force Asia for accepting my talk. So I have the chance to be here to speak to you. If you notice, probably there's another session supposedly after this on Managed IQ integration with Ansible, which was supposed to be delivered by my colleague Daniel Korn, but unfortunately he had a family emergency and was not able to make the trip at all. But I hope I could just give you an intro to Managed IQ and maybe at future events we'll give you more detailed presentations on the different integrations with Managed IQ, which you will learn is a very powerful tool. Doesn't it? So what does Managed IQ do? As you saw in the previous slide, it's an open source management platform and it has the ability to discover, control and optimize your hybrid environment. I'll go into more details about what each of these mean in the future slides, in the later slides. But first, a brief history about myself, an intro about myself. My nickname is Cybert. That's probably the easiest way to find me online because Carol is quite a common name, Carol Chen even. So if you just search for Cybert, most of the stuff should be related to me. So I was actually from Singapore, I mean I lived in Singapore for 14 years, but I left in 1996. So it's a rough idea of, okay, somebody's protesting. So that was almost 20 years ago, or more than 20 years ago, I left Singapore to study in U.S. And after I graduated, I joined Nokia Dallas in Dallas. And when I was working for Nokia, I kind of got acquainted with some open source projects, one of which was Helix. It's a video engine. It's a cross-platform video engine. I was working in the multimedia department. So I kind of got interested in the open source way of working. But it wasn't really until later on when I left Nokia and got more involved in community events and kind of, if you know me, go, which was like the joint effort between Intel and Nokia for open source internet devices that I got really more acquainted with, you know, the open source community, ways of working and collaboration. I really got passionate about all it stood for and the way it encourages participation and innovation. So after leaving Nokia, I joined YOLO. I'm not sure if anybody has heard of that company before. Okay, somebody pointed there. It's a startup, a mobile startup that kind of based some of the stuff from MIGO using the same Mercor and created our own operating system called Sailfish OS, which is, you know, it's a Linux-based mobile operating system. And, you know, it's really like efficient for mobile phones. And so through that, I forgot to mention I was a software engineer in Nokia for like eight and a half years. And when I joined YOLO, I went into more like community outreach and developer engagement type of role. So that's also similarly what I'm doing now in Red Hat, which I joined last year. And so here I am one year after that. Now in fast Asia, speaking to you and back in Singapore, one of my homes, I have like four different homes. I'm very happy to be here. And more of an unrelated note, I also play in an orchestra. So that's kind of like, I always say if I've never gone into this industry, I hope to be like a full-time musician somewhere, but that dream probably will never come true. But, you know, it's a side hobby project, whatever. So now enough about myself, here's kind of a history about managed IQ. So managed IQ actually has been around for quite a while. It was founded in 2006. I should probably get more information from the founders and one of some of the engineers who has been in the project for a longer time to learn about some interesting stories I can share at talks and events like this. But kind of the key dates are when Red Hat acquired managed IQ in 2012. And then of course, you know, Red Hat being an open source company. They, you know, got the code into shape and all the licenses in place and open sourced it in 2014. Anybody besides Red Hatters know which Red Hat product is based on the managed IQ project? Thank you very much. We've all done cloud forms. So, similarly, you know, like Fedora versus Ralph, Oveert versus Ralph. So managed IQ is the upstream open source version of Red Hat Cloud Forms. So you can see some of the kind of milestones. And one of it, which is the first design summit we had was, oh, actually, I don't have the date here. But it was in 2014. And we had the second one last year. I helped organize it when I came on board. I'll have more information about events and stuff at the end. So it has been where I've been trying to, you know, build up more community involvement and hoping to get more people interested in the project. So even though it has been only kind of open source quite recently in a couple of years, two and a half years. But it has, you know, getting already a lot of contributions, of course, mainly from the Red Hat engineers who are working on the project and for the Cloud Forms product. But also we have different partners in the community as well helping us. So recently we have also been splitting the repo, the main managed IQ repo into sub-repos because it was kind of, it was growing quite a lot with different providers, different new features. So it got to a point that it's not very efficient and it's very just a monolithic thing and we want to kind of make it into a more platform thing, plugable and modular. So things are more in the process of being more modular and the UI has been split out, different providers are in the process of being split into their own repos. And we found that actually when this is happening we're getting more commits, more PRs, more activities because the velocity got increased as the modules are smaller and more manageable and they have their own tests to eat and services, so things are also more efficient. So talking about the partners, some of these here are some of the partners that we have worked with to add capabilities into managed IQ. I won't go into the details, it's just some of the companies. So this is a high-level architecture diagram. In the nutshell, managed IQ is what we call a manager of managers or if you will, a meta-manager. It does not replace actually some of these element managers you might be familiar with like VMware vCenter, Kubernetes where you manage container clusters and so on. But what it does is it creates API connections to the different element managers and then it gets the information through this API and then creates this unified view or dashboard that you can see what's happening to the different providers and different elements. Another view which kind of gives a better picture of all the different types of providers we support which is not just clouds, so for the longest time we say this is a cloud management platform but it's really not just clouds, it's also like from middleware to containers to software-defined networking and storage. So each individually have the API connections to manage IQ and through the managed IQ interface you can drill down to the different levels and get more information, get reports, check the resources utilization and so on and so forth. So we can start with one of the features of managed IQ which is self-service. So what it does is through a service catalog you have different configurations and users can just select what they want and submit the request and while service request management is nothing new but the key things are automated. Previously maybe like with a manual fulfillment of the request it may take days for somebody or even up to weeks depending on the system but with the managed IQ we have this workflow orchestration process which helps to automate all this stuff and it will just take tens of minutes to come back with the resources needed to fulfill the request. So that definitely speeds up things, makes things more efficient but that's not sufficient. What happens when the resources are done with, what do you do with them? So we also have full, that's why we say complete life cycle management where you define the rules, what happens, certain time frame or certain conditions where you have to retire the resources that you deployed. So that's clear ownership rules, how to go about managing this for the retirement phase. So this is an example of a service catalog where you can select whether you want Amazon deployment or REL or Vmware and then you can select even multiple, you don't have to get one implemented deployed wait for the next one and so on because there's this shopping cart functionality where you can just select multiple or select all and say I send one request for all of them. And then the automated provisioning happens. So Managed IQ will provision everything configured according to what's specified in the service catalog and regarding provisioning, the automation part, there are two ways to do it. Previously the main way is to use the native Managed IQ which is writing scripts in Ruby and this may not be for everyone and it's kind of a very involved process and quite complicated. There's even a thick book written just on this automation topic but with the recent integration with Ansible which I think a lot of people are familiar with you can actually use playbooks to automate some of these stuff. But there's a choice, you can do it either way, whether natively or with Ansible. One of the other key features in Managed IQ is what we call continuous discovery. So what this does is that once you have connected a certain provider to Managed IQ it will continuously check the resources, discover the inventory and the relationship between the instances and gather all this information. And also when there are updates it listens for them and then it will reflect those updates in the system as well. So tracking all this data and configurations over time which will help with also later on we'll talk about root cause analysis because you have all this history of data. And to go more in depth we have what we call smart state analysis which has a nickname called Fleecing. If you know Fleecing like Fleecing a sheep you pull back the wool you expose some stuff but in a non-destructive way. So instead of just getting the metadata like the names of the VMs and the hypervisors they run on you're also getting the types of apps they have and the types of user accounts and things like that more in depth information. So with lifecycle management you basically get the visibility and control of the instances over their whole lifecycle from their history and you can clone the instances or migrate them from different providers and retire them or even suspend them the power functions shut down, suspend and so on. So you have access to all of that. So talking about the root cause analysis because Manage IQ gathers and tracks this performance data and configuration information over time so with this history information if something changes you can pinpoint when it happened and what changes caused it to happen. And with detailed these topology graphs you can see the relationships between the VMs which ones they are being deployed from and so through that you can also again go down into the layers and see what were the underlying issues and solve the problems through that. So not just problems and finding out information that way but you also want to optimize the system and again because of monitoring and tracking things that have been utilized, the resource utilization Manage IQ can use this information to kind of get trends and then predict future usage so you can suggest like maybe you can for this you can deploy things, instances of this size so you can better utilize all your resources so in this way you can optimize the system. So policies again with all this information drawn from smart state analysis you can define policies in two ways either across all the environments that you have for example you can say all the users across all my environments will have this type of access or you can say like okay firewall access so for production environments I want this set of rules but for development environments they are more permissive or something so you can enforce different policies for that and with resource utilization you want to find out for example this user how much he or she is using and this platform what type of usage is being consumed so you can rates apply to compute, memory storage network and you can use this information and get charged back and show back data which is show back is just reporting the data and then also monitor the usage if somebody is using too much figure out if you want to have some rules against that or charge them more so all these cool features of managed IQ but what platforms of what providers are supported well traditional virtualization platforms like VMware like Microsoft Hyper-V like Oveert which is the open source version of ReHat enterprise virtualization you can provision VMs and all those things we mentioned going to smart state analysis of the VMs and so on of course clouds have cloud management platform Google Cloud, Microsoft Azure, Azure how do you pronounce it and Amazon and nowadays containers are being used everywhere we also have full container management through OpenShift which is another product supported by ReHat and we have advanced containers scanning and you can check for vulnerabilities and making sure everything is secured so I think that's the overview of the features more about the project itself managed IQ releases are roughly in the six months, six to eight months well actually for the past four releases about six months cycle and we named them alphabetically Anand, Botvinnik, Kappa Blanka, Darga and Elva who knows what's the relationship between these names great, alright so because one of the founders of managed IQ is an avid chess player and so he named other releases after chess masters Ops, went too far and actually our next release will be named after the American grandmaster Ruben Fine so we're going to have a fine release coming up and I think in a week or so we're going to vote on the name of the G release so if you're interested check out we'll have links later on on the website when is the voting taking place and cast your vote you can get to name our next release so as I was saying previously about the first summit being 2014 so last year we had the second summit and you can see we have a crazy bunch of people fun bunch of people and we even have a chess somehow going on by Oleg who is our chess master so what chess somehow means that he goes one player to the next one person playing nine people at the same time and he beat them all so yeah it was really fun I guess that's one way we party and also there's this hallway track which as you know in conferences that's always sometimes even more interesting than some of the presentations although I think this one coincided with the coffee break so more events we have actually quite a lot of recently more and more interest about the project so we have been getting requests and also people have been just kind of organizing meetups to learn more about the project or you know work on it so here are some of them and if you notice they are mainly in Europe for now and we have some in the US as well and like the manager I could summon it was in the US last year and the two years, three years ago but we are also hoping that we get more interest in Asia region Asia Pacific region and we can have more events in these places as well actually we were in Picon, Pune last month was it last month because some of the QE stuff is written in Python so that's kind of related so maybe there will be more okay so we are trying to come up with avatar or mascot for the project and remember what I said about the nickname for smart state analysis anyone? yes thank you so if you might see a bit of relation with that but it's funny because we had that design for our last year's Red Hat Summit and somebody called it a bunny goat because it has long horse or years that make it look like a bunny and it has a sharp face which looks more like a goat than a sheep I don't know but it kind of also go with the whole hybrid theme I guess but we have been having some interesting designs by some of the community guys so just saying that sometimes contribution to an open source project is not just about coding but just different ways of participating because for example for myself when I first learned about project I was very overwhelmed because it's a huge platform and it's written in Ruby on Rails which I have no idea about because even though I've been an engineer for a while I've never touched Ruby but still up to today I don't really know how to contribute code-wise but there's many ways to be involved in the project so I hope I've given you an overview of what the project is about and how you might if you're interested to collaborate or connect with us so just basically remember ManageIQ because even though I list all these URLs over here it doesn't really matter the main thing ManageIQ.org you can anyway connect to most of these channels we have of course GitHub account and the Gitter is our chat pool of choice I don't see it anymore nowadays but Gitter is anyway tied to GitHub account I think GitHub as well we didn't get that much of them recently yeah exactly so you can use that talk it's our kind of forum and all these social channels and if you want to reach me again Cybert, just Google it so I think that's about it I'm in my own time well right on time so any questions, feedback if not I have some cool stuff here I have bags, I have stickers I need to find them in my bag and some microfiber cloths which are useful for cleaning glasses and phone screens and stuff like that so come on and grab something and thank you for your time


Hey, this is Brett and this 2018 Ram 2500 Crew Cab Short Box Big Horn is stock number 14067ZA. I am here at Summit Automotive in Fond du Lac, Wisconsin, you're new and used heavy duty truck and ram headquarters. This 2018 Ram 2500 has the 6.7 liter Cummins diesel engine. It's paired up with the 6-speed 68 RFE automatic transmission. This truck has been fully safety and inspected by our service shop per the state of Wisconsin inspection process. It has a fresh oil and filter change. All the fluids have been checked and topped off. It has four brand new tires and this truck is 100% ready to go. I'm going to go all the way around in this video inside underneath, start it up, take a look under the hood, show you all the options and just give you the most accurate representation that I can of the truck. Delmonico Red Pearl Coat is the color. I shoot all my videos in 4K. If you like the video, consider subscribing to the YouTube channel, click the bell notifications, get updates on the videos I do each and every day as well as having access to one of the largest catalogs of vehicle in the heavy duty truck walk-arounds on YouTube. 9,000 videos and counting. This one comes with the 18 inch polished aluminum wheels. They're in pretty nice shape. It has brand new Nexon Rodian CTA tires. These are LT 27570 R18s. Still have the little knobs on top. We put those on in our safety inspection. Frame and underbody is in pretty nice shape. This is a one owner clean title history, clean car facts from right here in Wisconsin. Front fender is in excellent condition as well. Headlight lenses are nice and clear. It does come with the factory fog lights. Front bumper is in excellent shape. I didn't see any major dents or dings on there. And you do get the chrome trimmed grille that is in really nice condition as well. You get the cab lights up top and the hood is in fantastic condition. I didn't see any major dents or dings on there. Passengers side front fender looks really good. And the passengers side front wheel, no major scuffs or scrapes on there. That tire is brand new too. Delmonico Reds got a lot of metal flake in it. And it is a pearl coat. Looks really good. As you go down this side of this 2018 Ram 2500 take note of how clean the body is, how reflective and mirror like that paint is. I take these HD videos so if you're far away or even if you're close by and just cannot make the trip down but you're still interested in purchasing the vehicle you can see the truck, hear the truck and of confidence in what you're looking at before you can get here. So when you do get here, there's absolutely no surprises and you can make a smart and informed buying decision from wherever you're at. Now if this video helps you make that buying decision, let your salesmen know that you saw the video that was helpful and that bread sent you. Then I can keep doing these videos for our great customers all over the United States each and every day. This one does come with the wheel-to-wheel side steps. They're in really nice shape. The back wheels are in excellent condition as well. And the back tires have just as much tread as the front tires. Picked up a rubber band on the way in here. Frame and underbody other than a little bit of corrosion by the welds looks really good. Has all the remaining factory exhausts that hasn't been altered in any way. And as far as all the underbody goes, looks really good. Cab corners or rockers all look really good. Didn't see any corrosion on them. And coming down the passenger side box here, no major dents or dings. Rear bumper is in great shape. No major dents or dings in there. It does have the full towing package with the receiver hitch four pin and seven pin wiring. And the tailgates in pretty nice shape. Just a couple little things to disclose. It does have a little ding right here. It's been touched up and a little ding right there and has a little bit of touch up on there. So if I'd have to knock this truck for anything, the tailgates got just a couple little issues. Comes with a very nice spring and bed liner. And it does have LED bed lights with the button. 2018 was the first year that you could get that button back here to turn those lights on. And that spring and bed liner goes on to the tailgate. Shuts nice and solidly. And coming down the driver side just as clean as that passenger side. No major dents or dings on the box. For full disclosure, this back wheel is in pretty nice shape as well. And there is just a little bit of touch up on this rear quarter right here as well. Cab corners all look pretty good. Didn't see any dents or dings on the doors. It does have the heated fold up till mirrors built in directional signals. They fold up like so. They fold in like that. Take a quick look at the back seats. Back seats are in fantastic shape. No rips, no tears, no stains. Latch child safety system. You get the power sliding rear window. Seats are in really nice condition. Factory, all weather floor mats back here. They fold up for extra storage.  You've got muddy boots or tools. Put them on there. You're not going to get your seats dirty. Or if you've got pets, put both sides down. And then they've got a nice flat place to lay storage underneath there. And you get in-floor storage on either side with removable bins for easy cleaning. You can put ice and drinks in there.  There's side corner bags. Or if you're not in Wisconsin, just extra storage space. Child safety locks on the back doors. And the inside and bottoms of the doors all look fantastic on this truck. I'll show you the VIN sticker here. No previously owned in Canada trucks here. And then the tire and loading information sticker. Inside, the Bighorn package gives you the gray cloth 40-20-40 split bench seating in the front. No rips, no tears on these seats. They are just as nice as the back seats. Does have power driver seat with lumbar. Factory, all weather floor mats up here. Auto headlamps, power windows locks and mirrors. And these mirrors do power fold in. I always like showing both sides so that you know that both sides are working properly. Pop inside, check out the miles, the radio and everything that this truck has to offer on the interior. You can see this one has the 7-inch LCD display, digital speedometer, compass and outside temperature display as well. Instrument cluster is very nice and clean. Comes with the leather-wrapped steering wheel. This is a heated steering wheel. Cruise controls on the right. Bluetooth and information center controls on the left. And you do get audio controls on the back of that steering wheel. This one comes with the 6-speed 68 RFE automatic transmission. It has the 8.4 3C radio. You get, actually this is the 4C radio, my bad. You do get the factory navigation system on there. There is highway 41. You can see that is working very nicely. You get AM, FM and Sirius XM radio capabilities.  And you can see both of those are working very nicely. Down here are all your different apps, including projection manager. You can project your cell phone to the screen via Android Auto or Apple CarPlay. The 4C radio was the first radio to be able to do that. Did a demo on a 4C with Android Auto. If you want to check that out, how that system works, that's in the upper right-hand part of the screen.  This one does have five auxiliary outfits, which is stability control, tow-haul and your factory exhaust brake. You get 115 volt, 150 watt plug-in and the passenger side format and seat are in excellent condition as well. No rips or tears. I don't think this truck has ever been smoked in and it smells very clean inside. The headliner is in fantastic condition. Map lights, power side and rear window controls and your home link buttons for your garage door security systems and lighting systems. The system SOS buttons in the mirror. Let's start it up. Take a look under the hood. As you can see, it starts right up. No check engine lights or anything like that. I would personally like to thank you for checking out the video today. And hopefully from this HD video, you've been able to verify the quality, condition options and, of course, cleanliness of this truck all the way around inside and out. I think for the age of miles on, it's a really nice shape. Under the hood, we have the 6.7 liter Cummins diesel engine. The engine base is very clean, runs very smooth. Once again, this truck has been fully safe and inspected by a service shop. It has a fresh oil and filter change. All the fluids have been checked and topped off. Shocks have done a nice job holding that hood up. It has four brand new tires. There is the emission sticker. And this truck is 100% ready to go. I would highly recommend this truck to make quality and condition standpoint. I think whoever is going to get this one is going to be very happy with it. And to see more pictures of this truck or one of other 550 new new Scars trucks, SUVs, minivans, Wranglers, half tons, three-quarter tons, one tons, you name it, we've got to go to the website right there. SummitAuto.com, full pictures and descriptions of every single vehicle, all at SummitAuto.com. If you'd like to check out more HD videos, you can go to youtube.com. Click the bell notifications to get updates on the videos they do each and every day. As well as having access to one of the largest catalogs of vehicle walk-arounds on YouTube. And stay current on our ever-changing and vast inventory here at SummitAuto. In fact, in a second you will see links to subscribe to my YouTube channel on the upper left. A link to all the Ram 2500 truck videos I've ever done in the upper right. Link to this vehicle on our website in the lower left. And a link to one of our latest YouTube videos in the lower right. Click those, check us out. We're super excited to help you with this Ultra Clean 2018 Ram 2500 Crew Cab Short Box Big Horn in Delmonico Red Pearl Coat. Thank you so much for checking out the video. Remember to like, subscribe on the YouTube channel. And thanks again.


I'd like to thank everybody who is joining us today. Welcome to today's CNCF webinar, Brigade Scripting Container Workflows on Kubernetes. You're in for a real treat today. My name is Locky Evenson. I'm a principal program manager at Microsoft and cloud native ambassador. I'll be moderating today's webinar and we would like to welcome our presenter today, Radu Matthai. He's a software engineer at Microsoft and maintainer of the Brigade project. Brigade is actually in the CNCF sandbox. A few housekeeping items before we get into it. During the webinar, you're not able to talk as an entity. There is a Q&A box at the bottom of your screen. Feel free to click that and drop your questions in there and then we will get to the questions as we see fit. So again, please don't ask questions in the chat specifically go down to the Q&A box and we will see them and we will get them answered throughout the webinar. Thank you very much. This is an official webinar of the CNCF and as such is subjected to the CNCF Code of Conduct. Please do not add anything to the chat or any questions that would be in violation of that Code of Conduct. Basically, please be respectful to all your fellow participants and presenters. And with that, I will hand it over to Radu to kick off today's presentation. Take it away, Radu. Hello everyone, good morning, evening, afternoon. Hopefully the daylight saving times in Europe didn't mess up too many schedules this week. Today we're going to talk about Brigade and scripting container workflows on Kubernetes. My name is Radu. I'm an open source maintainer for Brigade and the cloud native application bundles project. You can hear me talk about developer tools, OCI, security protocols, really, really into music and bicycles and I'm a software engineer at Microsoft. Today in this webinar, we're going to talk about Brigade and you could go ahead and check out the documentation. Throughout this presentation, they'll build links to multiple pages in the documentation. You can also check the GitHub project on github.com, Brigade Core. Before talking about Brigade, let's take a step back and think about what an operating system is, what its job is and essentially the program that after initially being loaded it manages all of the other programs, right? And if we think about it, an operating system manages processes on a single machine and Kubernetes manages containers in a cluster. So without stretching the analogy too much, we can think about Kubernetes as a cloud operating system. Going forward, we've been using operating system, shell scripting, bash, PowerShell for forever now, right? And essentially shell scripting in an operating system world is essentially flow control that wraps the execution of processes, but it's not opinionated about what's running inside a process or what the process would do. And so when bash we're able to iterate through a bunch of files, start a process, LS for example, take the output of it and then use it as input for another process, echo for example, and seamlessly pass data between multiple processes. If we continue the analogy, then how would we think about cluster shell scripting? I would like to have something that controls the flow of executing containers, but it's not opinionated about what the containers do or how they run. So I would like to be able to do something very similar to how I would do bash, but instead of starting processes on a single machine, I'd like to be able to start containers in a Kubernetes cluster. So how are we doing this right now? Well, first of all, we're using good old bash scripts and to some extent abusing YAML. And we're gonna see in a minute about that. We think that we have a solution for this problem with Brigade. Brigade is a cloud native, is a CNCF sandbox project and essentially the framework is an in cluster runtime for event-driven scripting on Kubernetes. It's really really lightweight and we're gonna see just how lightweight in a minute. And essentially it is used to chain together containers to create multiple workflows. And we were talking earlier about how would some cluster shell scripting look like? Well, I would like to start multiple containers in my cluster, iterate to the result, pass data between them, attach Kubernetes volumes, wait for them to finish, start them in groups and all that stuff, which so far we've been doing with either bash scripts, really, really complicated and unmaintainable or untestable bash scripts or some sort of trying to use YAML to do that for us. And thinking about the shell scripting, well, there were a bunch of questions that Brigade had to answer. First of all, is what programming language should we use? How do we share data between multiple containers, multiple jobs? And when are we supposed to execute scripts? And let's take each of those and talk about them. First one is we decided to choose a language and not write one. And if in 2017, 18, 19 or 2020, we're thinking about using a programming language to reach as many people as we can, well, honestly, there's only one language that fits that and that's JavaScript regardless of what we think about it. It's been the number one programming language over the last couple of years in all metrics. So, well, we chose to go with JavaScript mainly because it's extremely popular, has a very rich ecosystem of tools and it's extremely flexible. More than that, it has more than 1 billion weekly NPM package pools. Some of those are CI, but some of those are actual real humans using JavaScript. Second question was, how do we share data between containers? Think about it this way. I wanna start a job, wait for it to finish and get the results or an output or something from that job and pass it as input to the next job. If we, if you're thinking about how to do right now with Kubernetes as well, we're thinking about Kube control exec or Kube control run, paste the output in the console, grab through it, take some info and then pass it forward. JQ and Jason and Yan will help with that a bit, but it's still really, really painful. And we're interested in how to pass information to containers and how to get information from containers that have executed. And more importantly, because we chose JavaScript, we wanted to be JavaScript native to feel like you're actually writing JavaScript. And as important, we wanted to preserve existing paradigms for passing data to and from containers in a Kubernetes world. And at the end of the day, it's just JavaScript. It's a really, really simple syntax for writing scripts on top of Kubernetes, right? So I instantiate the new job, I add a few tasks, I add them in environmental variables and then I execute the run function. The third question was when do we execute scripts? And the most obvious was reacting to triggers or events, right? And event handlers become the entry point for brigade scripts. We live in a world where every system is able to trigger some sort of events, be it by webhooks or by a message queue or something like that. And essentially it made sense for us to execute to outside events. Where do these events come from? Well, they could be any HTTP webhook, either internal from your systems, it can be a third party like GitHub, Container Registries, Trello, or Kubernetes itself. Yet, I'm mentioning Kubernetes, in the end any event source can be configured for brigade in a component that we're gonna take a look at in a minute called gateway. And this is a complete script for brigade. If you add this to a brigade project, essentially you're able to execute it every time there's an event called sumEvent. And essentially what we're doing is we're importing the brigade package in JavaScript and then we react to an event called sumEvent with this function. We start a job, we add some tasks to be executed and then we run it. This is the most simple task that we can execute a brigade we're gonna see in a couple of minutes more complicated tasks and actual control flow. So what do people use brigade for? We've seen it being used as a foundation for opinionated CI-CD systems. We'll take a look at those in a minute. Overnight application security scannings, aggregating and analyzing data from multiple systems, building reports, creating preview environments on top of Kubernetes full request. So if you have a project that's in Git, Bitbucket, GitLab, GitHub, whenever there's a full request, we've seen projects that created a new namespace, essentially a preview environment of the entire application, allowed you to investigate the environment and then either delete it or promote it or to other GitOps-y things with it. Processing orders connecting to external services, databases, actual CI-CD. We've actually been using brigade to build and deploy brigade forever now we have an integration with the GitHub checks API that we're gonna see essentially allowing us to push back build logs back into the GitHub UI. So essentially we're using brigade with the existing checks API. And in the end, any potential container workflow that you wanna run on top of Kubernetes that would actually benefit from language features. So if your only use case is just starting three jobs one after the other or at the same time and you're not interested in actual control flow or I think gonna wait for some of those jobs passing easily passing data back and forth. And you could probably achieve that with either Kubernetes primitives or some other declarative system. But if you find yourself restrained by YAML then having a full programming language and environment could be of use. So how do we get started with Brigade? Well, Brigade, we can configure it with Helm. Helm install and then Brig check. I really encourage you to go check the docs brigade.sh website. You can find all of the getting started right on the website. Now there's a question of whether we can replace Docker files or manifest with JavaScript. Essentially, you can configure Brigade to work with a GitHub repo. And if you put that, if you put a manifest in your GitHub repo, you could. You could also choose to build container images before using them, but you would need a Docker runtime in your cluster to do that. We have an example of how to do it on the documentation. So how do we actually get started with Brigade? Is my screen still sharing? Okay. Yes. I did a Helm install a couple of minutes ago. Did you bump your font a little bit, Radu? Can you bump your size? I think so. Yeah. There you go. One, maybe one more. There you go. Okay. I was telling you that Brigade is fairly lightweight. Essentially, the default installation of Brigade is three pods. We have a completed pod that's just a cron job that's running, that's not running right now. So there are three main components for Brigade. There's a Kubernetes controller, which is looking for Brigade events. And then there's an API, which we can use it to essentially use it to interact with Brigade. And then we have a web dashboard that's obviously optional. So after we do a Helm install, we can do a Brig check to make sure that everything is running healthy in our Brigade installation. And if everything is running okay, then we can start the web dashboard to see if that's running. And that's gonna start your default browser. I'm gonna create a tunnel to Kubernetes and access the Brigade dashboard. And right now, we don't have any projects. We haven't configured anything. I just deployed Brigade a little bit earlier so that I don't rely on pulling Helm charts on the internet right during the call. So let's just start it with actually configuring a project and we'll see how that looks like. Big project create. And essentially it's a wizard that helps us configure a project and we're gonna choose the following. So we don't want to use a Git repo so far. I'm gonna give it a name, hello. We don't want to have any secrets and essentially we have a couple of scripts that we're gonna use. You can find them, I'll place the GitHub repo for this. Most of this thing you're gonna be able to find in docs.rigade.sh, the entire demo that I'm gonna show you right now is from the documentation. So please be sure to check that out. This is the first script that you're gonna use and you're gonna pass it at the default script to be used in case we don't use anything else. And we don't want any advanced options. So at this point, we have our Brigade project called hello and if we do a Brig run, essentially I was telling you that Brigade reacts to triggers and external events. Right now we're using the Brig CLI to create an event for us. And I wanna execute a new event and I wanna pass for the project, hello. And at this point, what's gonna happen is we also have a second terminal dashboard for Brigade. It's a CLI one in case you don't have access to a web interface. It's called Brig turn, Brigade turns someone from the community contributed this. We're super happy with the community and the things that they've been contributing so far. Essentially, let's walk through what happened. So Brig created an event. It was a simple run, exec event. This was called by the Brigade controller. We scheduled the Brigade worker and essentially our job was called do nothing based on an alpine container. And the only thing that was supposed to execute were echo hello and then echo world and then run and exit. So let's see how that looks like. We have the Brig run creates an event called exec that we're handling to that we're responding to. And then if we go any further, we can see that the job was called do nothing. And we can see the two tasks that were supposed to be executed echo hello and then echo world and then an exit. So Kubernetes get pods. And right now we're able to see the Brigade worker that was whose job was to execute this JavaScript file. And then our do nothing job which was a Kubernetes pod with a single container called based on alpine. So this is the simplest Brigade script that you could execute. There was a question of people not being familiar with JavaScript and how hard was it to learn? Essentially, this is the simplest way you can start with Brigade. We tried to have the syntax as simple as possible first of all for people who are not familiar with JavaScript, but at the same time if you are familiar with JavaScript and if you have written JavaScript before we're trying to make use of as many useful JavaScript patterns as we can. So we're gonna see throughout today's demo useful JavaScript features and things that are obvious to people who've used JavaScript but as well as easy enough to get started for other people. So let's have a look at a second script. Essentially, this one starts two jobs. So it's gonna start them at the same time one called hello, which will do echo hello and echo world and then one goodbye, both of them based on alpine. So we're gonna do the same thing, Brig run or Brig exec, that's the same command. And then instead we're gonna pass script number two. So the same thing is gonna happen, Brig is gonna create an event, the Brigade controller will catch that event and will schedule a Brigade worker and the worker pod will start executing the Brigade.js file that we see right here. Essentially the Brigade worker is using the Kubernetes JavaScript API to interpret this and start jobs. And then if we go back to our CLI dashboard, we can see that we have two jobs, one hello, one goodbye. Now we can see that they were both started at the same time. It doesn't really matter the order that you pass right here. And then here we can see that they were started at the same time, they both last as pretty much the same time. And then we can go into the logs of each job and then see them. We started them, essentially we first tried to start hello and then try to start goodbye, but we don't see the order here. We first see goodbye and then hello. How are we supposed to actually control the order, the execution and things like that? So we have something called groups, first of all. Essentially think of them as collection of useful methods in Brigade that allow us to control the execution. So we can run each which will first start hello and then start goodbye sequentially or run all which was started in parallel. So let's see how this is gonna execute. We're doing the same thing, passing this file. And what we're expecting to see is Brigade first starting the hello job and then starting the goodbye job. And we are essentially here started, we saw them getting started at the same time. We expect them to be started separately. So we first see hello, we started the execution and then finished. And then after hello finished, we see the second job being started. So we see hello and then goodbye. Let's see that through the web dashboard as well. The command was Brig dashboard, which will start the tunnels of Kubernetes and then open your default browser. We see the project called hello and then we see a bunch of events that were executed five minutes ago, two minutes ago and a few seconds ago, which correspond to our Brig run commands. And this is how it looks for a single event. You see the two jobs and then the jobs, right? These are the logs from the Brigade worker, the same ones that we see right here when we execute Brigade and then we can go further into the logs of each individual job. So this is very useful when you don't have access to the Brig CLI, essentially the Brig CLI that we've been using so far requires access to a KubeConfig. It uses KubeConfig to essentially talk to the Brigade API and Kubernetes API for that. What I didn't mention so far is that everything in Brigade is Kubernetes native. So it doesn't have any external dependencies. Everything is done as Kubernetes native objects. And then the web dashboard essentially is a read-only version that uses the API. It cannot be used to modify the state of the cluster or of Brigade. It can be only used to view logs and view jobs and things like that. We actually have a public version of our dashboard that be used for our projects. Let me see if I can find it. Yeah, so this is, if you're interested, you can see the logs from multiple projects of ours. For example, these are the logs from Brigade itself. And we can see that the last build actually failed. So this is interesting. If you're interested in this, you can deep dive into what's happening there, but essentially because it's a read-only version of what happens in Brigade, you cannot affect the state. You can only see the logs. There's a question in chat whether we're running Kubernetes jobs. Almost running Kubernetes pods, not exactly jobs. Jobs in Kubernetes are an opinion over pods. So far we've been using the underlying pods definition from Kubernetes. We can enter, go into the details of why we chose pods over jobs. I don't think it's worth going to discussion right now. I'll be happy to chat about that if you're interested. So we've seen how to use the group subtraction in Brigade to start jobs one at a time. Now let's see how we could use more advanced JavaScript features to get the same results. So essentially what we're doing is we're starting two jobs just like before, but this time we're using the I think a weight functionality from JavaScript to essentially wait for a job one to finish and then start job two and then do something else, right? Imagine job one configuring something in your cluster and then job two using that, right? So let's see how that... Essentially we're not gonna see anything different than we saw when we were using groups. This is just a different language feature that we're able to use with Brigade. Yes, the job function supports promises. That's how we're using the sync away functionality. There was a question of whether the job supports promises. There's another question of how is this similar or different to Tecdon CD to create pipeline jobs or pops? The way we're thinking about it is essentially, first of all, we're not using any declarative features. We're not using YAML to configure our jobs. So that's one difference. The second one is essentially Tecdon CD is particularly suited for CI CD purposes. We've seen Brigade being used for a bunch of other use cases as well. We are using Brigade for CI and CD and there are a bunch of opinionated frameworks on top of Brigade that have declarative features for CD. But if you're only gonna use CI CD, you could have a look at Tecdon, for example, other things on top of Kubernetes. Let's see the last event. It was 50 seconds ago and lasted 11 seconds and exactly what we were expecting, right? Nothing different job one started and then finished and then gave you good job two. Now, let's dive a bit into things that are not so easy to do with declarative approach, right? So in this scenario, what we're trying to do is share a particular storage between three jobs. We have a job one, which is gonna write into a file. We have job two, which is gonna write into the same file and then job three is gonna echo whatever was in that file. So think about it in this way. You are trying to share the same persistent volume in Kubernetes across three different spots. You could potentially achieve that using a very complicated bash script, create the persistent volume attach it to the configure of the first spot as a persistent volume claim, then wait for the first bot to finish and then attach the persistent volume claim to the second bot and then attach it to the third. Essentially, this is what Brigade does for you automatically by just doing storage enabled equals true. So if you do that, it's gonna attach the persistent volume to your bot. The Brigade storage is a persistent volume that is one for each build, essentially, that is shared across all of the jobs in this build. So let's do that. Brig Run, just to iterate one more time on this, I'm starting executing events manually and passing Brigade.js files. You don't have to do that. You can use a Git provider for that to store your Brigade.js files and have an inversion control. This is the easiest way to test your script without pushing the source control, right? You can also store them in Kubernetes config maps. If you don't have a GitHub repo and we've actually seen more and more people using Brigade without GitHub repos, so it doesn't have to be a Git enabled scenario. So we do a Brig Run for this file and essentially what we're gonna see. And if we do a Kube control, we see a persistent volume claim being created. And yeah, this is essentially what's happening right now. We created the worker pod and then we created the persistent volume that we're attaching to that. And then we're waiting for that to finish. And then we're gonna start each individual Kubernetes pod, attach it, use the persistent volume and then, and then detach the PVC from the pod and then add it to the other. There's a question in chat whether it is better to use a weight versus the run each construct. Essentially the run each just uses a weight. So it's a matter of what language feature you're most comfortable with. You see that job one is starting. We're gonna start job two and then job three. Waiting for Kubernetes to pull images and start containers. Let's try that again. It's a new cluster, so I don't really know what's happening here. So it scheduled the first job. Move on to the next one and get back to this. There might be an issue with my cluster. Two minutes is way too much to attach a persistent volume. I'll switch to a different cluster and we can see that. Let's see. Let's run the same Brigade script for a different cluster. Not sure exactly what's going on with this one. There's a couple of questions, Rado, if you wanna take a moment. Yeah. Is JavaScript the only or preferred language for event-driven scripting for Kubernetes? Brigade by default uses JavaScript to do this. That being said, we have seen at least three implementations of a declarative approach on top of Brigade. So you're not necessarily only restricted to JavaScript. You can have a YAML file that configures Brigade for your needs. But specifically by default, Brigade only uses JavaScript. And then the second question was, could you pass configuration or parameters to pod deployments like having a template and deploy it to Kubernetes? Yes, we actually see that doing, we've seen that done pretty regularly. Essentially you're keeping a bunch of Kubernetes config files or Helm charts into a repo and then as part of executing of a trigger, you're able to take that config file and then essentially deploy to Kubernetes or even better start Kubernetes cluster inside of Brigade using kind Kubernetes and Docker. I'm gonna point you to a resource for that. That's my job number five doesn't really work. So let's see, let's check on number six. Unfortunately, does Brigade need to run in the same cluster to interact with others? No, if you have a KubeConfig file for a different cluster stored as a secret, you can pass it to Brigade. It doesn't have to run. By default in the easiest way would be for Brigade to, essentially because Brigade runs in your Kubernetes cluster, it's able to start pods in the same namespace as it's configured into. But yeah, you can point to a different KubeConfig as well. So my cluster is acting up really weird. In a working scenario, essentially this would create a persistent volume and share it across all the jobs that are in the current build, right? In the current event. This is one persistent volume created for each event and then attached to each individual job. The second type of storage that we are able to use in Brigade is called a cache. And essentially, if it has the same job name and you have the cache enabled, this will attach the same persistent volume to your job across multiple event invocations. So think about it, if you've ever needed to use build caches for Java, for Maven, or for things like that, this is what's used for, right? Or just use the same storage across multiple invocations. Now, this is really interesting. I really don't know why the demo gods are not with us for the job storage, but we'll get back to that. Another thing that we're able to easily do in Brigade is essentially pass information, not using persistent volumes, but just return values from our containers. So think about it this way, we have two jobs. And the first one just prints something on the console, it can be a formatted JSON or plain text. And then we're starting job one, and then we're taking the output, the standard output of the results, which is the result of the execution of job one, and then using it as inputs to job two, right? So it's waiting to schedule the pod. We see job one, that outputs world. And then essentially what we're hoping to see is job two using the output of world, and then just using it in some way. So we can see it outputting hello world, right? So think about it in a more complex way. Think about it, job one, executing something, passing an idea of a job or an idea of something in your database, and then the second job, picking it up and using it. If you're only passing very simple information, like something that would be able to be pushed to standard output, feel free to use the job return values. If you have something more complex, more bigger object that you're trying to pass between jobs, you're probably gonna wanna use storage or caches or other storage in Kubernetes. And then finally let's have a look at how we would use more complex JavaScript features like think and await and then try catch, right? Think about it and you're trying to execute a job, and then you're preparing that something could fail in the job, right? In a normal Kubernetes scenario, if a pod fails, you can either choose to restart it or you can choose to back off and stop restarting it, right? We could give you another choice, which is catch exceptions, catch failures in your script, and then do something else, like do some cleanup. What the script is gonna do is gonna start job one, which will execute successfully, and then job two will exit with code one, which is a failure, right? And then because we are trying and expecting and accepting an error in either of these two jobs, we're able to catch the exception and do some cleanup, right? Think about it and if you ever need to stop some service from running or restart something or simply retry, right? You can do it right here. So we've caught the exception, right? And then we're able to do additional things, right? The caught exception error is coming from your actual code. So if you go back here, you can see that in this case, the job, the Vendix self-succeeded, but there's one job that failed. The Vendix self-succeeded because we chose not to fail it explicitly. Here you can just error out if you don't want to handle your exception or if you just leave it unhandled. But because we've been able to recover from that exception, even if job two failed, we can choose whether the build failed or succeeded. It's up to you, essentially. There is one question if any feature use case overlap with Kubernetes operator patterns and regate. This is a really interesting question, which is because we've been discussing that in the last couple of weeks and I can point you to a project that does just that, which is the Brigade Universal Kubernetes Controller, simple buck. I'll paste the building for that. Can you synchronize in a completion of a group? You can, essentially, you can wait, yes. Groups can be used if you put multiple jobs in a single group. You can wait for the entire group to finish before starting new jobs or before doing something else. Is the cache only runtime or does it persist across Brigade restarts? The cache is a Kubernetes persistent volume.  And by default, we don't delete the persistent volume. You have to do that manually.  There's a Kubernetes controller. There are worker pods which execute a script and schedule the jobs. And then there is the optional API that is used to interact with Brigade from web or CLI. And then gateways. Essentially, they map events from outside the cluster or outside of Brigade inside Brigade. Out of the box, Brigade comes where we can figure it with a cloud events gateway or one that supports arbitrary JSON, gateways for container registries, GitHub. They can be web hooks or a simple back script that create the Kubernetes secrets. Events in Brigade are simply Kubernetes secrets. And we have examples on how to build gateways for Go, Node.js, Bash, Python. We have community integrations with cloud events and CNTF integration with a GitHub checks API. And I can actually show you that. So this is the Brigade repo itself. And then for each pull request in the checks tab, we have jobs that are running inside of our Brigade cluster in the beginning installation and then logs pushed back to GitHub. So this is GitHub, this is just a GitHub app. And then these are two jobs in our Brigade JS script that we use to test the actual Brigade repo. So we can see them and interact with them. If you have access to the repo, you can rerun them, essentially interact them in the same way you would do with a GitHub checks API. We have integrations with Prometheus and Virtual Cubelets, essentially scale in with any provider at Virtual Cubelets supports. And if you wanna see a tutorial on how to do that on Azure container instances, I've written a couple of months ago a blog post on the Microsoft blog, essentially about how to schedule, how to burst out to Brigade jobs to Virtual Cubelets. So if you don't have enough capacity or don't want to schedule on your usual nodes, essentially you can set your host to be Virtual Cubelets and that's it, it's gonna, if you configure it, your jobs will start executing onto Virtual Cubelets and then you can use the Brig term to see them being started right there. And then soon we're gonna have documentation on how to integrate with Linkertly, the standard service mesh. And then for a full ecosystem, we can see the GitHub page for that. We really, really like contributors. If you wanna get started, there's a good first issue label in GitHub and I think most of our projects, you are more than welcome to start contributing. We're happy to help you get started. That's not what I was supposed to do. If you wanna get involved, you can find us in the Brigade channel in the Kubernetes Slack. We have a bi-weekly community meeting on Tuesday, which is at 5 p.m. Pacific. GitHub.com Brigade Core and then join us at KubeCon. We have an introduction to Brigade and a deep dive. The too long didn't read for Brigade is a, Brigade is an in cluster scripting environment that allows you to chain multiple containers. It is really lightweight and works on any Kubernetes cluster. You write scripts in basic JavaScript and then it's essentially the Kubernetes application. It's made of a couple of pods. You can manage it and monitor it in the same way as you would any other Kubernetes application. It's a CNCF sandbox project, stable version 1.2. We're getting prepared to release a 1.3. And if you wanna learn more about advanced language features to sync with more examples on Trycatch, we have advanced scripting guide on our documentation. I can learn more about gateways. If you wanna learn about how to secure Brigade, I really encourage you to check the security topic. If you wanna package up dependencies and use other NPM modules in your Brigade.js or write your own, we have an article on that. If you wanna test Brigade scripts, we have a topic for testing as well. Any other questions? If not, I can show you a couple of other examples such as, I was telling you about a couple of opinionated CICD frameworks built on top of Brigade. Here's one called Anya, which also integrates with the GitHub checks API and allows you to have trigger gates for different pull requests. So essentially you check out the checks tab and then it gives you a button on whether to promote the specific pull requests to production or rejected and perform deployments and things like that. So this is built on top of Brigade, for example, and there are a bunch of other projects built on top of Brigade as well. Another one that I'm really, really excited about is, we've kept seeing Brigade being used for end-to-end testing. So essentially you have your application and then you wanna deploy it on Kubernetes. You're using Kubernetes. There are two options. You can create a preview environment or a different namespace or you can start a Kubernetes cluster inside of Kubernetes itself using kind, which is Kubernetes in Docker, which is a Kubernetes 6 project. Essentially it uses Docker containers to start Kubernetes nodes. I really encourage you for a local environment is really, really easy to get started with Kubernetes. But here we're configuring a kind cluster inside of Kubernetes using Brigade and essentially this is all that we have to do. We have a kind job in a library and then basically we're adding our tasks and executing it. And what's gonna happen and when that Brigade is gonna get executed, we see the cluster getting started and we can interact in the same way as we would interact with any other cluster. Without interfering with our production workloads, right? So this is an interesting real big shout out to the kind team for this project. I really encourage you to get started with it. And if you wanna use JavaScript dependencies other than what Brigade comes with, essentially you can either have dependencies in your GitHub repo, in a local file and then import them or you can put them in a Brigade JSON file or similar to a Package JSON where you could just list your dependencies and use them from there. So you would just require it just like you would in a normal JavaScript project. Any other questions? I think that's it, Rado. Huh. Thank you very much for the great presentation, Rado. The webinar recording and slides will be online later today and we look forward to seeing you at a future CNCF webinar. Have a great day.


Well, we work as an artistic team, which is something that we think has also something to do with feminism, and how working collaboratively for us is a way of questioning authorship as something that has only to do with an individual. And we always work in collaboration. It's not something that we do for one piece, and then we leave it, but it's something that we always do. It's also a way to somehow not let people know exactly what our identity as individuals is. This is also why our names, we only use our surnames so that you don't really know what gender are the authors and who exactly they are. We decided to start with a film still from the work which is being shown here at Global Feminism. It's called A Kiss, Un beso. It's an old work for us, it's from 1996, but we want to contextualize it with a little bit of more recent works. In this video, you can see these things I was talking about, not knowing exactly the defined identity, who is kissing, is it to women, is it who are they. You can never see their faces completely, and also there's something disrupting the visual pleasure for the viewer. Some people might say, oh, two women kissing, that's so nice. So then we put a heavy argument on the background so that the viewer was not... The argument has no translation because it doesn't matter what it's about because an argument is always an argument. Around these years, 1996 and 1998, many of our works were dealing with, I mean, we were on our works. It's not only because we wanted to make a self-portrait, it has more to do with it just the easiest for us. It was us that we had, so it was us that we used. And also with something that has to do with representation of our community. We didn't really want to be... We knew there weren't many people in our country who were speaking openly about queerness or about lesbianism and showing themselves in an open way. So we knew that there could be a problem with people taking us as a representation for lesbian community or peers. And they would say, well, we have these two artists already, we don't need anybody else. And we don't feel... We don't want to be the quote of the exhibitions anyway. And we don't represent anybody else and ourselves. And so as I said, it's us most of the time during these works, self-portraits that... This is a portrait who played with Goya's work, because we use so many different artists in our work. Our work is dealing with politics of representation, not only with politics only. But we make the work in the... We live in the art world and we want to express ourselves inside that. So we quote this work from Goya's, which is a work who... The Goya's work is dealing with war issues in terms of violence.  Yeah, people would bury themselves up to their knees so that they couldn't move.  So it was a way of... Yeah, in this case we don't... We... It's not as violent, but anyway we can move, because it's not the Photoshop issue. Yeah, many of the pictures you don't really see who is on the picture. And we also use the double image most of the time, double pictures. You don't... Because for us, we said it's important to question authorship and also to question the original of the work. We don't know which photograph is the original one. This is a portrait, also a portrait that we quote in this case Dushan and Bruce Nauman. So we make... It's called Self Portrait as a Fountain. Yeah. And again, we are not looking towards the camera so that you can really define us and we are playing with gender... In this case, we want to use a queer environment.  You can see the image, the image is on a mirror, which is also with graphites over there. So we... We... Part of our work is also dealing with the places that we occupy in society. Yes. We have all these series of works that we made after living in San Francisco for a little bit more than a year. And feeling for us it was... We had this utopian idea about San Francisco as a beautiful place where you could live freely and we had this Hockney's image. So happy... With swimming pools. Swimming pools with bright colors. So we started to do a lot of work with swimming pools that were empty, that we would photograph them in the moments when they are not being used. And we have been doing different series around places that we analyze exactly when they are... They should not be analyzed. We look at them when you shouldn't look at them. We'll go to San Francisco, we went there because we want to live kind of paradise.  So what we find there is not exactly what we really call a paradise. And it was in 1997 when we were there and so the AIDS was destroyed the community also. So it was like completely the opposite from Hockney's experience. So we started to think about what kind of places there are in society for us and what kind of lands... What kind of... And these lands give us an identity too. So we start to think in the reason why in this society we are always associated with kind of a happiness like in discotheques or like in swimming pools. So we decided to choose to talk about these places when everything is closed but it's starting again. For example, these pictures are taken on a sand discotheque after the party but just in the same moment that the people leave the party. So there are only the rest. Yeah. So again we look at the spaces not when we should look at them but when you're not supposed to be there and you're not supposed to be enjoying the place. The images were taken in Madrid actually. Yeah. This is a more recent work from 2004. And here androgyny and playing with masculinity is another issue that is very present in our works from the beginning as you have seen in the pictures when we said the identity or the gender is not easy to grasp. And here we started to work with other people apart from us and also with cinematographic discourse, cinema because we thought we wanted to talk about the construction of gender and how so many people talk about how femininity is constructed. But not so many talk or analyze how masculinity is also a construction and can be made up of things that you add or things that you put on your behavior. So we decided to invite to an open casting a lot of women who would play James Dean in Rebel Without a Cause. And we just chose a scene from the film and showed it to all of them so that they would reenact this part of the film in their individual way, the way they wanted to. We take the screenplay so they need to say things that the scene that we chose was just after a car crash and one person died and James Dean survived.  For us it was also interesting that there were many different women playing this role in different ways and to see how, what kind of strategies they would use to look like a man. And it's important in this casting we don't give them any kind of makeup or no help to be masculine so they choose the way they present by themselves. And also the fact that we chose cinema is also, it has also to do with the idea that cinema is giving us the images of how to be a real man and it's also a real woman. So for us it was really important to quote this discourse from cinema. Yeah, for us at the beginning when we started to work with cinema it was difficult because we realized that men say nothing in the films. It's really difficult to find even a complete sentence because they always say nothing just women are talking and talking and talking and we looked for the scenes where they say something really interesting that we could get for the casting and then we went crazy because we realized that women are, it's true, women are talking all the time and men they just move. You know, they just say something like cool but short and then when you decontextualize it it's like nothing, nothing. But all of us feel like the opposite. In this particular work this is a short video and this is a guide instructions to be masculine. Like a manual. A video manual. It's important that we are not talking about drag queens issues, we asked women to play the role but play the role to pretend to be real but we saw health more than the clothes and the attitude. So in this video we just make a kind of manual. So it's under instructions manual. There's a discotech music and the woman who appeared here is playing different poses which help you to be masculine if you need to be masculine for example you need to learn in one hour it's completely possible. Yeah, it's like an ironic manual and the video is divided in sections like one how to drink, two how to sit down, how to move, how to wait and then the woman is performing all these different attitudes so that in the end if you watch this video all day long after as you said after a while you should be able to perform. This is a video called exercise of power body space. We mixed two films here, one was Schindler List and the other was The Apartment. So there's a woman playing the role of the chief in both films. The boss. The boss. Yeah, sorry. You're better. Yeah and well here we wanted to analyze how power is dealt with in cinema and so we were invited to do a job in our work in an old factory and old tobacco factory and we could choose to do anything we wanted it was an abandoned tobacco factory. So we thought of films that could have been shooted in similar environments or that had to do with the idea of how the structures of powers could function in an environment like this and we chose these two films Schindler List and we chose some scenes that we thought were interesting on the poses of the boss of the powerful man and how he acts and he moves to say the things he wants to say and then The Apartment where there's also this the boss acting like a boss really and we did we had this woman to perform everything but here we really we characterized her a little bit yes a little bit her and this is just the last project we are it's not finished yet and it's something that we have been doing in the Philippines yes because we were there so we decided to work with Apocalypse now Apocalypse now is a film shoot completely in the Philippines but represented by Vietnam so all the people think that they are in Vietnam but they are in Philippines something happens the same with the gender that you don't really realize what this is so we decided we choose this woman so she's playing the role in the film of Martin seen in Apocalypse now playing that the same issues and I think that we ran out of time thank you


This is a brief video abstract for the crypto 2022 paper, Succinct Classical Verification of Quantum Computation. This is joint work with James Bartusek, Ya'el Calay, Fermi Ma, Giulio Malavolta, Vinod Vaikunthenathan, Tomaviric, and Lisa Yang. The setting for this work is that of verifiable computation. In this setting, we have some computation represented by deciding membership of a string X in some language L, and this computation is delegated from some verifier to a prover. So the prover and verifier exchange messages in an interactive protocol, and at the end of the protocol, the verifier is supposed to decide whether or not X is in L. And the goal for such a proof system is to have verification be simpler or easier in some sense than deciding whether or not X is in L on your own. So in the classical setting, we have such argument systems, and they're called succinct arguments for NP. And what's known is that for any NP language L, say an n time T, there is an interactive argument system for deciding L where the communication in the protocol is polylog T, so very short, and the verification time is polylog T and some fixed polynomial in the input length. In our setting, we are studying classical verification of quantum computation. And so the primary goal in this setting is to make sure that even though the computation itself requires running a quantum computer, the verifier in such an argument system should still be classical. So the communication should be classical and the verification algorithm should be classical. So with this consideration alone, the breakthrough through work of Mahadev in 2018 showed that assuming the hardness of the learning with errors problem, there are interactive argument systems for every efficient quantum computation where the verifier is classical. So in this work, we managed to construct verifiable computation with both of the efficiency guarantees that we just described. So it is both the case that the verifier is classical even though it is verifying a quantum computation. And moreover, the communication in the protocol is short and the verification is extremely fast. So our formal result is that assuming the hardness of LWE and additionally assuming the existence of indistinguishability obfuscation, we construct succinct arguments for all BQP or even QMA languages where the communication is polylog T where T is the QMA verification time and the verification time of the protocol is polylog T and a fixed polynomial in the instance length. Here are a few highlights of what we do in this work. The succinct argument system is constructed in two parts. The main contribution of this paper is to build a protocol which has a laconic verifier meaning that the verifier to prove a communication is short. This protocol was built assuming IO and LWE. The reason that IO is used is that IO allows us to build a tool that we call a succinct key sampler which gives us a way to have a compressed representation of a large number of essentially independent public keys that we define formally in the paper. This IO based tool is then plugged into a generic template for building classically verifiable quantum computation and then we give a new security proof of this generic type of protocol that is modular and generalizable. In particular, it applies to the protocol with succinct public keys which is what we use in our main result. Then given this laconic verifier protocol we also write down a generic compiler that converts it into a fully succinct argument system and this uses as its main tool a post-quantum succinct argument for classical computation that is sufficiently composable. Then finally, we also write down some extensions of our results that allow us to achieve zero knowledge and also build protocols that are non-interactive given a post-quantum random oracle. This concludes our video abstract. Thanks for listening.