Okay, so, welcome to the Drupal CI initiative talk, or I guess to keep in alignment the context of this conference, the future of Drupal.org, continuous integration. I just wanna do a bit of a quick overview so everyone knows what they're getting themselves into. So first I'll kinda do a bit of a blanket like what is CI, why do we need continuous integration? The origin story of Drupal and continuous integration, the state of Drupal, NCI. I'll start to get into the project itself, the components, I've got three recorded demos, from there we're just down to questions and demands because at the end of the day this project is the stakeholders are the community, so any feedback from anyone is welcome and we'll go on the roadmap if it's good. Cool, so I don't really like having a me slide but at the end of the day I just wanted to say why I'm a part of the Drupal CI and what value do I add? So my name is Nick Xu, I work at Previous Next. I'm a developer and a sysadmin so it means I get to make the tools and use them at the same time, which is awesome. I also dabble in a bit of everything, so PHP, Golang and Docker are like my latest obsession, so very, very cool, and then I do a lot of puppet. I'm the maintainer of tour module in Drupal 8 and I also maintain three or maybe more, but definitely three components in Drupal CI, so yeah. Yeah, and stop me if I go too fast because there's a few components and there's a lot of technology to this stack, so at the end of the day, if I'm rambling or you want a bit more clarification, just put your hand in the air and I'll answer it.  So I wanted to cover continuous integration and just blanket statement it, so guess what I did? I typed continuous integration into Google and this is what it gave me back, but at the end of the day, this is continuous integration to me, so continuous integration CI is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build allowing teams to detect problems early and I swear I will not read a slide like that ever again in this talk anyway. So, but as you can see, we already do CI in Drupal. We generate a patch, generally that patch is like, for me it's like a one-line fix and then you submit it and then it goes through a build system and then it gets committed and then I pull down master and I keep going, I'm frequently pulling down head and then merging features into it and then getting feedback through the automation. So, as you can see, this is something that we already do, but we want to unlock a little bit more, right? So, let's just sort of talk about the current. So, as I stated, we have a patch workflow and I'm not gonna get into that at all, but that's the workflow that we have and that's fine, that's completely fine by me. It's, you know, you submit it, it goes through a build system and then we get a response. That build system itself is called Piffer, that PIFR bit there. So, when you do a build, it fails, you go to that site, see your build, see where it failed and why and then you get back into, you know, replicating those files locally. But that site is a Drupal site. That's a Drupal site that manages nodes and compute to run the patches. So, and this was built quite a while ago and at that stage, they weren't really CI best practices, like there wasn't like best of breed CI systems. So, I completely agree with this approach. I think this is completely fine, like you build what you know and building it in Drupal makes total sense in this case. But, you know, like it was testing one version of PHP and back in that day, that's legit, that's fine. Probably wasn't as much of a big deal at the time to just test one version of PHP. The kickoff is to have tests first, right? If you don't have tests, then have tests. There's also no testing for the infrastructure itself. So, talking with the DA staff, they're still pushing changes and they'll push a change to production and there's no test suite for the current infrastructure.  So, we need tests for our testing infrastructure to make sure that we don't break anything. And the final one is it's locked into simple test as well. So, we have that run test.sh script in core and the infrastructure is tightly bound to that script itself. Sorry, and I missed one too, the nodes themselves. I recently went to DrupalCon Amsterdam and I was walking around the sprint rooms and I noticed in the Drupal Association Room that they had about two or three staff members who sold job for the entire sprint was to spin up test bots. So, they'd spin up compute, they'd provision it with Puppet, which is completely fine, but the time that it took to get those bots going feels like wasted time. We can make it easier on them. It should just be like, spin me up an instance in like two minutes and then go, right? But these guys were spending the entire days bringing up instances and diagnosing and when they could be doing something else, right? Cool, so that's the current. So, now onto some goals of Drupal CI. So, based on that, we now formulated some goals for the new system. So, first one, unlocking better testing. So, that means things like coding standards, PHPCS. Like, we desperately want that in Drupal 8. To be honest, like, in my mind, if you fail PHPCS, the rest of the build shouldn't really go through. Like, you shouldn't test code that you're just gonna quickly change and then push back up and then run your build, right? So, fail fast, but right now we run simple test and then that's, you know, we want PHPCS be hot, any other crazy thing that comes out for testing into the future, but we wanna be agnostic to that. We wanna leverage industry standards. So, things like Jenkins, like since, like I mentioned before, since building our CI infrastructure, a lot of standard software has come out since then. So, Jenkins being the big one, right? You talk to anyone about CI, like continuous integration or continuous delivery and they pretty much say Jenkins all the way through. So, hmm, it's there for you. Yeah, yeah, come to his session tomorrow. ThoughtWorks have a product, well, an open source project now called Go, right? Go, yep.  Um, so, you know, Jenkins, right? Um, less, and that equals less custom code, right? Because we've built our CI infrastructure all bespoke for the most part. Like we are leveraging Drupal, but the actual workflow of communicating with nodes, people have solved that since then and that's a burden that we shouldn't really have to bear. More versions. So, PHP 5.3, 5.4, 5.5, 5.6, 7. Yeah, PHP 7 when it comes out, so head maybe. But you kind of get the drift. But outside of PHP, like what about like Postgres? We don't test Postgres right now in our bot infrastructure. MongoDB, CHX is working on MongoDB right now support and it looks really good, but it's really hard for him to prove to someone that, hey, you know, I've got really awesome MongoDB support rocking right now because it's all like on his laptop, basically. So it'll be really good for everyone to see how that's progressing. Automate everything. So like I mentioned, the DA stuff, how they were at the sprints, like doing all the manual puppet provisioning, all that should be automated. You should have a pre-built image from the get go. You can just go spin me up another one of those and away we go. Tools for better testing, I actually covered that. So that was unlocked better testing. Test our own code. So actually write tests for our components, right? So if we push a Jenkins change or like a change to the workflow on Jenkins, we should have tests around that, but actually make sure that things are working correctly. If we push a change to the actual build workflow, we should have tests around that as well. Every component should be testable. So then we know that we're not gonna break our CI system and then everything that runs under drupal.org infrastructure for testing will be broken. So let's avoid that. And the final one for the goals is I kind of mentioned about packing images away, but the goal is to pack these away into multiple sources, right? So Vega and AWS and Docker. That's not like, there could be more, but those are kind of the three that we're targeting right now with the meaning that myself, I could just pull down a Docker image of a result site or something and I'll get more into that, but I could pull down a component and run it internally at my work. And then there's multiple ways to do it, right? Locally on Vega and AWS, spin up some compute up there or leverage it in a Docker infrastructure. But like I said, build for the community. That's the main goal. All these components should be focused on the community because at the end of the day, someone writing a patch for drupal.org infrastructure is fine, that's awesome. But at the end of the day, if you can get your business to use one of these components in this infrastructure and then say, hey, we want this feature, send a pull request or a patch and let's start talking about it and get it integrated into the main component itself and then everyone wins. Okay, so now I'm gonna start talking about some technologies. I'm gonna get this kind of bootstrapped into a few of these texts before I get into Drupal CI itself. So the first one's Vagrant. Who's heard of Vagrant and who uses Vagrant? Cool, cool. My slides are actually running on a Vagrant VM because I'm too lazy to install a web server on my Mac, so that's Vagrant, all of that's Vagrant. But basically what that gives you is reproducible environments for local development. And why is that awesome? Well, that's awesome because I can spin up a VM locally, start hacking on the project and start developing a new feature and that's the approach that we've taken with Drupal CI from the beginning. So every component we start with local. It's local first because at the end of the day, if you can't run it on your local, no one's gonna contribute back. That's just plain and simple. If no one can replicate the environment, it's really hard for someone to actually write features. So Vagrant's very important. The next one's Packer. This is written by the same guys as Vagrant. They have a whole suite of tools, go check them out. But Packer's the one that we use for packaging our apps. So this can do a lot of things. So it'll package the Vagrant VMs, it'll do AWS, I think it does some digital ocean and then Docker containers. It's basically like takes your manifest or your scripts or whatever you have and then it'll create an image, a reproducible image for repetitive builds. So you can kinda see why this is really important in a continuous integration environment because you wanna spin up the exact same environment every time and then you wanna roll back to a previous image if something happens. Docker, same thing. Who's heard of Docker? Yeah, everyone's heard of Docker, right? It's yeah, build, ship, run. But this is kinda the core of the CI infrastructure given the fact that it's, to run a Docker container is as easy as me going to one of my apps on my Mac and just going like Firefox. Like that's how it's built. So what, so Docker's really important because that's how we get our PHP 5.3, 5.4, 5.5, our Postgres, our Mongo. We get all these components and we mash them together into a test scenario. So very, very important. Jenkins, so I'm sure everyone's heard of Jenkins. Very industry standard, no? I'm sure MIG hasn't heard of Jenkins. Go learn Jenkins. Yeah, so Jenkins is very important. This is the thing that we're gonna use to basically queue up all our jobs. I'll get more into that later on, but it's basically at the heart of your CI, right? Like this is the thing that takes the builds and then does stuff with them. So more on that shortly. So components. Let's get talking about the components. I keep talking about components. So now you will all know what the components are. So this is a little diagram of it. Don't be too scared. It's not that too tricky. But essentially, let's talk about this from a patch workflow, right? Or like I've submitted my patch, right? So I've submitted my patch on Drupal.org. Next step is Drupal.org goes, hey, API endpoint, I have a new patch for you to test. And API goes, oh, sweet, sounds good to me. Let's tell the results site. So we actually have a new page, a new page to send results to. And then let's queue it up on Jenkins to start the build or just the build server, right? Next, spin up some compute and then submit that back to the results site at the very end. And then Drupal.org is kind of sitting there going, hey, guys, hey, API, how's my build going? And then once it's ready, you can submit a link to the results site, right? And I'll get more into these components. Oh, and there's also monitoring and logging. I won't get too much into that because that's kind of a solved problem for Drupal.org. We run that, like that's actually run on Drupal.org infrastructure already. So it's pretty much like talking to those guys and just collaborating and implementing it here as well into the same system. So, but monitoring and logging will be really, really cool because you could start to get some really easy metrics. So if you're collecting those logs, you can be like, hey, you can graph how many patches have we run, how many fails, you can start to get some really, really cool information around that. So, yeah, I don't, monitoring and logging is really, really important, but at the end of the day it's a solved problem so I don't need to talk about it here. Yeah, so that's kind of the overview. I thought I'd start there. So then when I start talking about individual components, you'll know sort of how they all interact with each other. You kind of, dare I say it, it's a bit of a microservices architecture maybe, a little bit maybe. Sorry, Meg, where you putting your hand up? Yep, yep, so spinning up, yeah, spinning up compute. Yeah, or dispatcher slaves, like the more technical term, or the better term for blanket statement for that is more like just that interaction is dispatcher and then node really, because at the end of the day, doesn't have to be Jenkins, could be anything. But I'm getting ahead of myself. So let's start at that API, right? So it's written in Sylex, which is a symphony micro framework, you can probably read that on the thing anyway. But what that means is there's a good transference of knowledge between people working on Drupal 8 and then they can jump in and start helping with the API as well. And it kind of means that we align our best practices at the same time. So and there might be things that we learn in here that we can bring into Drupal 8 or vice versa maybe, but at the end of the day it's all about trying to bring in more of, because we have a lot of developers working on Drupal 8 or Drupal in general, why not try and bring those guys into here and let them work on an API, just the API component, right? And all in all it's an abstraction layer to the infrastructure itself, because at the end of the day we can swap out any one of these components and then just update it in the API itself. So we can swap out Jenkins if we wanted to and then just update our API. But not actually the API endpoint, just the backend, right? So the interactions are all the same between the APIs, just what's going on in the background will change. Yeah, it's a Drupal.org CLI integration endpoint. So Drupal.org right now handles the queue, I'm pretty sure. I'll have to check up on that. But at the end of the day it means that Drupal.org won't be doing as much, right?  There's a lot less responsibility for Drupal.org, which couldn't help them when migrating to Drupal.8 in the future or whatever it's less code to port and less responsibilities. It could also be a command line integration point. So you could write like a little bit of Drush plugin action. You could also maybe write a bot or something like that that integrates with the API itself, but at least that way then, we kind of have that on Drupal.org right now, but if we can point it at the API for those kinds of checks, I think that'll work out a lot better for Drupal.org itself. Because it means we can just scale out the API instead of scaling out Drupal.org itself, because that's pretty taxing. What's less, like scaling out a little Silux app or a big Drupal.org site with lots of modules? And those are the URLs. So those are the projects. And we're trying to keep it like on Drupal.org as well as on GitHub. So that way, if people want the pull request workflow, that's fine, submit a pull request and then we'll sync it up. We'll keep the two in sync, that's fine. And then if you like the patch workflow and do it there, that's fine, two points. Mm, demo time. See if I got this right. So this is a recording, sorry guys, I don't trust the internet. So you could probably see the code already, but it's nothing too crazy. At the end of the day, this is an early prototype of the API, but essentially all you want to, what's a minimum viable product for the API? It's essentially curl the endpoint from your local, say this is my patch, this is the repo, and then it goes, hey, I got that data, now let's curl Jenkins and pass it on, so it's a proxy basically. So as you can see, not too much code, I won't really go into it too much, but not many lines, but I just paste in this string here. I wish I could increase that, but I'm basically just saying repository, patch, and I don't even know that. Oh, sorry, patch branch, yeah, patch, nah, yep. And then I curl that, and then I'm actually telling people in this thing. So, sorry, this is actually from a blog post. So you can see this here, like we have sent you a build, it's just a little, but we'll change that to like a JSON return, send drupal.org likes it, like we'll do best practice API basically, but this is just, this is from a little while ago, but this is just MVP, and then you can see like a build kicked off, and then it's going through all the stages, and don't worry about that stuff, but that's actually just a little build project, but you can kind of see like you curl the API, it goes to Jenkins, which could be anything, and then it takes the data and then it runs a build, and the demos will be better from here by the way, so. Okay, so next is the dispatcher, right? So that's that Jenkins box that we had, but we're calling it the dispatcher because we can swap it out at any time, I don't mind Jenkins, but if something else came along and we could always swap it out, so, but essentially it just queues up builds, it starts the job runner component, which is where all our logic is, so the Jenkins CI is dumb, like it doesn't have really any plugins installed, it's just core Jenkins, and it just knows, hey, I got this, queue it up, spin up some compute, run the logic, or run the project that has the logic, and that's it, right? It's packaging status is we've got vagrant images for local, like I said, and there's an AWS AMI that we'll be publishing soon, so we have the AWS AMI and we're currently testing it on an AWS account and getting all the components together, so, but the goal is someone will just be able to go point click Jenkins, fill out some credentials for AWS, and then you'll have bots as well if you really want something internally, and those are the URLs there. Job runner, sorry, and I maintain those by the way, so API and the dispatcher, so I maintain those bits. The next one is the job runner, which this is where a lot of the build logic is right, so Jenkins has taken the details, it said, let's run it, let's run this script that has all the logic in it, and this is what the job runner does. So it's, in essence, it is the Drupal CI workflow, it's the testing workflow, it encapsulates Drupal.org testing into a single project, like a single symphony console app, so, and the reason why we chose symphony console is exactly the same reason why we chose Sylex, it's to try and get the developers in and working on it as well, so then we're not bringing in some kind of crazy, like we're not writing it in, I don't know, like Python or something like that, where someone from the Drupal community is gonna come in and go, oh, I ain't touching that, like they'll be able to jump into this and get going and pretty much know what they're doing. It's responsible, whoop, sorry. Just a question, so is the reason you chose it basically? Yeah, so then we can iterate on both components, like Sylex does API endpoints really well, so that's kind of why we chose that approach there, instead of a full Drupal site in that case. Yeah, it means we can swap the API out with whatever technology we want, and same for this, like this job runner doesn't have to be Symphony Console moving forward, you could swap it out with whatever you want, but yeah, that's kind of where we're trying to keep in the PHP ecosystem and saying, hey, like Sylex does APIs, Symphony Console does command line apps and Drupal uses like Symphony, so that was kind of the fit there, but there's no reason why these can't be swapped out for anything else, so. If there's like a ton of infrastructure folk that are like, hey, we should write it in this instead, then that's fine. I guess it just depends on the type of people that we attract moving forward, as to what technology we use. So yeah, thank you for sticking with PHP and not doing Ruby or Python. I was very... It's because of the functionality for the people you work with, that's a nice trick. Yeah, yeah, yeah, sticking to the ecosystem. Oh, well, yeah, could have written it and go, but you know, never know. No, no, I believe in writing in this, and sorry, and the benefit for something like this is we can also write a PHP library that two components can use, which I'll kind of touch on very shortly, but that's kind of the thing, we're not writing multiple libraries to interact together, so write for one, write for all. Yeah, Postgres Mongo is just pointing out, someone's actually, we've got people using this job runner right now, and they're doing Postgres testing, because like Angie said, it's in a situation where it's like, get it going or we'll drop it. So yeah, so these people are like, oh, we need a runner, we need something to test this with, so that's why they've jumped onto a very early build of the runner and they're running that. We've moved on from there, but they're still running that right now to keep things moving along. As I mentioned before, CHX is doing MongoDB, so and he's slowly using a few more of the components as well, so I'll touch on one of the other ones and show you a bit about that, but yeah, the maintainer for this component is Jeremy Thorson, and he's the lead of the Drupal CI project, and it seems fitting that he would be looking after the biggest component of the infrastructure, the actual build process, so yeah, I think it's cool that he's getting his hands dirty into it, yeah, thanks, too, Brian. And I asked him to do a little bit of a demo, and by little, he interpreted that as 15 minutes worth of demo, so I've just sort of subsetted it to like a minute or 30 seconds of just like he hit build, and then it ran through, just then you get a quick idea, but I won't steal his thunder because he's gonna release a whole blog series, that's kind of what this is coming from, he's gonna push out a blog series. So if you're keen to learn more about this runner, then definitely check that out, and I'll tweet it out with like hashtag Drupal CI, so. One else, there's probably some more with the runner, but I guess that's kind of it, the other thing is the fact that this process can be unit tested now, where we can't really do that with what we've got. The other big change, sorry, is it's also moving to be not tied or hard coded to run test.sh as well, so then as we change stuff in core, we can basically let the repo dictate, so some of the stuff that's coming through is like a Drupal CI.yaml file. If you wanna do that, you'll basically have two options that are very Drupal, which is it'll just run simple tests for you, or it'll run this custom file with whatever you want, so then we can start to transition from run test.sh to something else like PHP unit if we wanted to, and there is an issue on Drupal.org that myself and Cameron and a whole bunch of other people are working on, so I'll tweet that out later on. That's worth checking out as well, that's the other side of the coin. And Lee, and you reviewed it. Thank you, Jibran. Okay, so I mentioned this demo, right? So, there we go. So I'll kind of kick, I'll kind of set the scene, right? So the Drupal runner, sorry, the Drupal CI runner sort of manages all the containers, right? And this is the suite of containers that we have now, so as you can see, there's a lot of versions. And we're actively working on these as well, so you'll see like, oh, where are they? Oh, these are all just the services. So it's actually like, oh no, PHP. So we're actually working on making these like PHP 5.3, 5.4, 5.5, 5.6, and then Postgres. So you won't actually see this like, this PHP 5.5 Postgres, you won't see that. It'll be like, spin up a 5.3, and then spin me up a Postgres as well, and then let's test against that. But that's the current state that we have right now. So we have a suite of containers. Jeremy's primed his environment, so he's run a bit of configuration and sort of set up like, this is what I want to run. So I want to run like PHP 5.5 with MariahDB, and then he's going to run it. Hope he runs it soon. Oh, and everyone knows that he runs Debbie in number two. So he's run simple test, but almost nailed it, 5.4 container with MySQL. And let me just stop that there. You'll notice the prefix and then the container name. So that Drupal CI actually means like hub.docker.com slash Drupal CI, that container. So these containers are very visible in the Docker ecosystem themselves. So, and I think that's pretty cool. Like we're branching out into other ecosystems besides just Drupal. So we're contributing these back for anyone else that wants to use them. So, and we'll provide more links to that. But yeah, Drupal CI, we have a Drupal CI account and we have a suite of containers under that as well. Yeah, I love that sleeping 10 seconds business. I might have to work on that. And you can see it's checking out the code base and I'll pause that. And then I think I just, yes.  You'll hit send and then it'll build for you, but there's a lot of sort of integration points in the runner itself. There's a lot of ways to interact with it. It's a mixture of environment variables or flags or a config file. So there's a few ways to do it and that's all documented.   And that's kind of the demo. It's 15 minutes long, so I'll make sure I send out a link once he's ready to publish it. But it takes you through the entire workflow. But as you can see, we've got spinning up containers and running through working. The other side of this is private Travis. So you've probably noticed that there's quite a few people hacking on Drupal 8 modules and then they're moving to GitHub and running like a trap, having a Travis.yaml file to run their builds. Well, I started hacking on something a while ago as a bit of a test and just loading up that file and then spinning up a container suite to run those tests based on what was in that file. And we're starting to work to integrate that library into the runner as well. So it's a compatibility layer for Travis, which basically means anyone that's using GitHub and Travis can move back into the Drupal.org infrastructure and not change their test suite. So the goal of this is all about compatibility and bringing everyone back under the Drupal.org banner that may have moved off to use Travis. It's also a symphony console. That was a bit of a plan around, but at least it sort of lines up well. And it's going to be a symphony console, but we're moving to make it more like an API that anyone in PHP can use. Results. So this is the bit that, this is, I guess this is the bit that I want to see iterate on the most because at the end of the day, if you submit a patch and then it fails and it's passing locally, you're pretty ticked off, right? You're like, why did my patch fail?  So to me, this is kind of like the face of Drupal CI and it's the first thing besides that one past one million failed message. So, and it's built on Drupal 8. So I think is pretty freaking awesome. So, yeah, and it means anyone can have a hack on it too. It's an install profile, it's a Drushmake. Anyone can just pull it down and spin it up and give it a test. A little bit of feedback from me building this in Drupal 8 is it was pretty damn smooth all in all. Yeah, there was one issue in Twig and then I jumped into Drupal Contribute and I said, oh, this thing's not working and they said there's a patch for it and it's already RTBC. So people were already on it. It was just, you know, so added the patch into the make file, rebuilt, worked. So I'm pretty happy about that. Yeah, it was pretty smooth. The patch, I believe it is, yeah. I'll check it out. I'll bump up the D8 version and make sure it still runs. But that's kind of the flow that we're taking with this too. So each release will just bump up the Drushmake file, run the test suite, river passes suite. If it doesn't, then we'll see where it failed and I think that will provide some good information back to Drupal 8 and if we deploy this in a scalable way, I think that will also provide a lot of good information back to Drupal 8 development because we'll have something running in a production environment that we can get a lot of performance metrics on and where things worked and where things didn't work. So making this Drupal 8, to me, makes a lot of sense. It also exposes a endpoint, a REST endpoint that we interact with, which I'll show you a bit more about that later on. But with those requirements in mind, like a Drupal 8 site and REST, we just went, yeah, Drupal 8 might as well do it in D8. We're not gonna do it in D7 and then redo the work moving forward. So let's go with D8. This is the site, themed it myself, Twitter Bootstrap. So if anyone wants to help me and by no means is this the finished product, it was seriously just MVP. So it was me, I'd built it and I said, oh, it should probably get themed and I was chatting to everyone and no one could really come to a consensus on what it should look like. So I just drew up some mockups and just looked at Travis, looked at this and went like, list page, node page and that was kind of it. And then I kind of let the Twitter Bootstrap components do the talking from there. As you'll probably see, like that's a Twitter Bootstrap component, like the menu, it's all there. So that's the result and this is the build itself. That actually progresses as it goes through and that's a taxonomy, by the way. So you can add your own states. So it can be like new, building, pass, fail. Like you can add as many as you want and interact that through the command line. That's just the standard message, but it could be anything. And then we've also got a list of artifacts. So now we can upload Apache logs and MySQL logs and you can get a bit more information back on why things failed. So, and just a point to mention, we're actually using, right now we're using S3 for those files. So we upload them to a remote file storage. And yep, yeah, yep, definitely, absolutely. Yeah, without a doubt. So yeah, Nginx and FPM. So, yeah, cool. But yeah, we're pushing up to S3 because at the end of the day, it could be any provider, but we're pushing to remote file storage.  You don't really even have to deal with files anymore with this. So it's nice and scalable and simple. Yeah, might be demo time. Cool, so, I hope everyone can see that. But I just, and I'll pause it on the way through. So the result side has a command line component to it. So that's what drives this whole thing, right? The command line component will live on the bots, but it could also be on your local development environment if you want to interact through it, wherever it is. Wherever your point is that does all the work, that's where your command line client can be and then interact with the result side. There's just a little basic configuration file, just admin password for the spin up, the URL of the site, S3 bucket. Oh, nope, sorry, no S3 key or secret for you today. And let's get it started, shall we? So command line client, create, made a title, just a random title, nothing too serious, right? But that could be anything, right? That's not locked in in any way. It could just be my awesome patch or whatever it is. We can make that sort of conform to Drupal.org standards. Like we can make that whatever we want, really. Completely open. So you'll see that it built, oh, sorry, created a node. Yeah, created a node on the site. I'd actually already run this demo once. Let me pause it there for a sec. So created a node, got a list of states so I can actually go result CLI states and that's just taxonomy. I'm just getting a taxonomy back that says the name and the percentage and that can be whatever you want. So you can have whatever crazy states you want. It could be something like building, running PHP CS, running simple tests, running the hat, pass failed. It's a per site basis in this case. So it's a taxonomy on that site. But yeah, it could be, it's kind of. All of Drupal.org is getting to the same test, aren't they? Yes, yep. But we could split out the sites into like a DA, D7. You could split them out into separate apps in that case. But that's completely like open to people's demands. If we have a need for more taxonomies and more, absolutely. Could even make the CLI drive the states instead of the Drupal site having the states available so we could just create them on the fly if they don't exist. So that could be another thing. So that's just listing the states. So you know what's going on? Yeah, I was using my examples, so I kept having build 13. And this is just me changing the state, and now I'm gonna prove that the state changed. So that was my build from before, so don't worry about that. So my project's now building. I'm proving that I have a set of files, so these are derived from runtest.sh, but they are in JUnit format, which is awesome. And let's hold the phone right there. So artifacts, results, and we have our result CLI generating that string message that we all love that says one pass and a million failed. So this way we're not generating, we're not making the result side itself do the heavy lifting, and because if you wanted to do something like this on the Drupal site, it'd get pretty complicated. Like you would either upload the files and then do the calculation right then and there, which would slow down your push, or you would push the files and then you would have like a cron batch process running in the background, generating those. So this right here means that our nodes, our things running the build, also compute the result. It also means that if you already had those artifacts locally from a local build, you could use this little client here to generate a message without having to go through everything. And that could be expanded, right? That just says like assertion values and errors, right? But that could be expanded to like a summary message and then all the things that passed and failed and everything, that's just sort of like a minimal viable product thing right there that we could absolutely expand on. So here I am. So I've built that message, but now I'm actually gonna push my artifact. Oh, sorry, I pushed the message.  And then I provided a build number to send the message up and now I'm sending my artifacts. So that's going up to a remote store and then it's sending all the URLs to the result site. There we go. Got all our files and you can pull them down and download them and do whatever you want with them. And I might as well mark the build as passed, even though it didn't pass technically, but that's okay. So I'm just marking in state four, which is passed and I had a network issue at that stage. So let's try that again, shall we? So, and then, hey, it passed. So that's the results component. Actually, I'll go back to that. So sprints on Saturday. Here's my one goal for the result site. So as you know, that's built on Twitter Bootstrap, but we want it to look like triple.org at the end of the day. Like it shouldn't be like this for everyone in the triple.org ecosystem. We'll most definitely keep a theme like this for people who want to use the result site outside of the triple.org ecosystem, but we definitely want it to look like triple.org. So I'm calling for help to port the blue cheese theme to Drupal 8. That's the base theme that's used for all the Drupal.org sites. So if we can port that over, everyone else can use the blue cheese theme, but we can also benefit from it here. And I had a bit of a chat with John Albin and he's running the CSS, sorry, the theming portion of the, I think I shouldn't say CSS. The theme, that's very mean. The theming portion of the sprint. So that's my one goal for the result site. Let's make it look like triple.org. And I just had a few little project ideas that you could use this for, right? You could create a gist.github.com kind of clone, right?  And then my build failed and I'm like, why did my build fail? So I send all my artifacts up there and then I can hand the URL off to someone else. It's just a crazy idea. Someone could do it if they want to. But you know, it's just proving that we can use it for more than what we're using it for. And the other thing is a Drush command, trying to think, oh yeah, like a Drush command to check what your builds are doing. So like you do a Drush something and then it'll give you a state of what's running, what's not, what's past, you know? So just like a little command line client for the result site. Could even be baked into the actual CLI itself, but you know, maybe Drush could leverage it. So yeah, call to arms. So I mentioned the blue cheese theme, but the other one that I want to work on that I will be personally sprinting on and would love a lot of help with is the API. After Saturday, I want to have a mock interface generated for the API, which is kind of like our contracts to Drupal.org to say this is what we'll be. Like when you send a request, this is what we will return because that means that Neil Drum from the DA can go off and builds the Drupal.org module. So if anyone wants to work on a Sylex API with me, please come say hi. And the other sprint that's going on is the Drupal Accelerate Sprints.  And I would love it if more people came online and helped out as well if they had time. But, and there'll be blog posts around this as well. I'll be recording each day basically via Twitter and blog. So, and I also want to thank Angie for supporting the Drupal CI with the DA Accelerate Fund. So she just contacted me on IRC one day out of the blue and said, hey, we need to talk about this, and we did, and I think it's great. So thank you for the support.


Najdwyr's chief of army staff, Ibrahim Atahiru, died in a plane crash in Kaduna State. He died alongside his ADC and a major general in a plane crash in Kaduna. He was on his way to Kaduna ahead of Saturday's passing up parade of soldiers from the Nigerian army depot, Zaria. The Nigerian Air Force confirmed the incident via a statement issued shortly after the crash. The NAF director of public relations and information at Commodore Edward Gapquit said the incident occurred near the Kaduna International Airport.


What's up, everyone? So today is Monday today's YouTube live day. It is March 29th I think the end of the month is coming soon Just a reminder Friday this Friday is good Friday. So the stock market is closed in Observance of good Friday. So it is going to be a shortened week this week. I totally forgot about it until today So just remember that Friday is no trading so What happened to me last Friday? So? Couple things that I want to talk about is I pretty much deviated from the process last week I've been on a very very big green streak For that loss I was up about 1.5 million dollars in about three months and It was just left and right.  You start to be a little bit more loose You start to not manage your risk. You start to not Respect your stops. You start to trade based on emotion rather than based on process.  It's not like I'm bankrupt.  I'm doing to kind of learn from it, right? So on Friday, we had two Chinese names wafu and EIQ These stocks were at like $70 pre-market EIQ hit $70 pre-market and wafu hit like $35 pre-market And what ended up happening on wafu is went all the way down from $35 to $7 and to me that's broken To me that says every single buyer above pretty much $7 is underwater and if there is any type of pop They want to be able to sell into it So what ended up happening on that is You know right at the market open the stock went from seven to eight to nine dollars And I'm over here getting really excited.  This thing should tank right it should tank So I started shorting it at 10 50 like around 10 10 50 because that was my plan My plan was if it gets worth $10 if it bounces like that It should be a short that set up works nine times out of 10 right nine times out of 10 that is going to pay me out so stuck to my process I did what I Normally do but what I fail to do is I fail to do my research ahead of time I fail to realize that the stock was a one million share float Which means that if I wanted if bow wanted we could buy the company ourselves And we have a rule if someone could buy the company if bow can buy the company We are not allowed to short it but Because I was on such a hot streak because I've been doing so well because I have been In the matrix I fail to do my research I was using my ego to trade the stock rather than my process to trade the stock and what ended up happening is A chat room pumper came in and started buying it at 10 11 12 at this point I'm already at my max loss and I need to get out right I need to get out and What ends up happening on these halts when the stocks are halting up There is no liquidity to exit because it is a panic people are panicking to get out So when the stock is at 13, I'm trying to cover at 14 it jumps to 15 I'm trying to cover at 15. It jumps to 16 And all of a sudden it's just jumping dollars jumping dollars and before I know it You know, I'm out of six figure loss and I'm so pissed and I'm revenge trading, right? I'm I'm doing everything that I shouldn't be doing and that is because I have been on such a hot streak That I felt like I could not lose, right?   We all go through these losses Trading is like a chart, right? Think about it. Your chart is just not going to go parabolic forever It has to pull back consolidate before it makes its way back higher I was going parabolic without a single pullback and I needed this pullback to get back to Uh, the next high, right?   So I need to be more self-aware of this stuff. So that's number one That's how I fucked up and I know what I'm going to do to fix it Now number two is what do I do in terms of trading to make this thing better, right? So When you lose no matter what type of level you're on, let's say you make $10,000 a year. Let's say you make a hundred thousand dollars a year. Let's say you make a million dollars a year It does not matter what level you are When you lose money in the markets, you lose your confidence in the markets You lose your confidence in your abilities and I lost my confidence in my abilities Still up over a million dollars this year. Why should I not be confident?  We could teach you guys the technicals We could teach you guys the process But unless you have like a community unless you have people to kind of help uplift you when you are down You are doomed cannot talk to your friends about losing a thousand dollars ten thousand dollars a hundred thousand dollars I'm gonna think you're fucking crazy. You need to be talking to other traders. So the value That I found myself in our community of misc's I got 50 dm's from people.  To be honest guys, all you have to do as minor as it sounds as simple as it sounds is you need to show up the next day Stick to your process that gave you those profits in the first place and walk away green If you make a thousand dollars normally a day Make a hundred dollars just prove to yourself Get your confidence back Prove to yourself that you can do this long term prove to yourself Right because in trading nothing is ever 100 percent that setup that I traded on friday Works 90 of the time and that 10 percent of the time it loses I need to make sure that my losses are capped and my losses are under control better This was a special case scenario because the stock was just halting up and halting up and halting up There was no liquidity exit.   You know trading is not easy guys. It is not easy But if done right you could make so much money.  I got too confident.  I walked away green at thousand dollars I gotta do this A hundred more times to make back the loss, but the point is that right now in this very moment I am not thinking about the loss. I am thinking about how can I show up today? How can I show up tomorrow? Be green stick to my process and walk away a winner Okay That's what I want to talk about today. So do you guys have any questions for me? We could open this up to a brief q&a guys So if you guys have any questions, we could talk about it now and we'll go through everything right now together No, I didn't paint that picture. I got it on the instagram ad So any questions guys?  I will be fine.  I mean if the edge is there I'll trade it but right now there's not really much edge I traded w ke y today Short of the 18 line Yeah, I just got lazy guys. I was so confident. I was doing so well for so long that I Really just got lazy and now I know What my when you get to this level, you know what you did, right? And you know what you did wrong and you know how to fix it as a beginning trader You don't really know what you're doing wrong yet And that's why you kind of need a mentor but to be honest guys if I didn't have m. I see and if I didn't have this community Maybe I would have taken a month off from trading Maybe I would just given up completely right and the power of having a community and the power of having people to Lift you up when you are down is very important because not many people understand The mental aspect of trading unless you're a trader yourself And you know in m. I see we have a community of Thousands of traders that have gone through this before that understand it that could help you And if they're able to help me They'll be able to help you too. So any questions guys What will I change in my process to avoid this kind of loss in the future is to do more research before the stock is to Be more strict with my 30% rule I was oversized on the stock on front side because of my ego So if I just stick to my process, which is the 30% rule Which means I am not allowed to use more than 30 size above vwap.  It's a disappointment in myself that I let it get to that point, right? so You know when I lost on friday, I didn't want to work out I didn't want to eat. I didn't want to leave the house. I didn't want to drive my car I didn't want to work it poured into my real life so hard, right? So hard that I hate the fact that it does that but We need to be able to have these losses To really appreciate the good things, right? You know, what is the point of having good things or doing nice things or whatever it is If you don't understand the pain of what it's like to possibly lose those things, right?   Let me stick to the process and before I know it it'll forget Someone asked what is the difference between front side and back side? You could look up all of our videos on that. We have free videos on that and You know another thing that it's very key to talk about is what happens after a loss Do you revenge trade or do you walk away? And most of the times what happens is let's say you lose $1,000 trading You start to revenge trade a random stock and you end up doubling or tripling your loss too And that is where a tab A trading accountability buddy comes in so You know the power of m i c is right now. We've matched up a thousand traders with other traders, right? So when you join m i c we find out your long buy short bias years of trading You know what you're trying to improve on what are you trying to do? And we match you up with a trader of similar skill levels in m i c to help you not only watch the videos Do the content together But someone that you could run your ideas past someone that you could share and someone to talk to when things go good and things go bad and You know A trading accountability buddy is what kind of keeps me safe from revenge trading and keeps me safe from kind of screwing up more guys So, you know, we have all these tools We have all these resources and sometimes we just need one of us or a friend Just slap us in the face and get away from this stuff because The best thing you could do after a loss is close the screens Walk away and come back the next day If your tabs are always away get new tabs, you don't need one tab There's tab groups you could be selected with five or ten other traders Just join m i c go to the trading accountability buddy channel and say hey, I need a tab Someone will DM you you'll fill out the information and probably the next day You'll be matched up with a trader of similar skill level and you know We're very proud to say that we've matched over a thousand traders in our tab program so far So I think that's it guys. I think I'm going to wrap up here. I want to kind of keep these videos short and sweet Um, I know we have the texting hotline of tosh two one three four five eight five nine nine seven If you have any questions about trading, you know If you want to talk to someone if you want to vent to someone if you just want to see if m i c is the right fit for you or You don't really know if trading is something that you'd be interested in text tosh He'll call you guys can get on the phone And he'll basically just explain to you if this is the right fit for you. So text him at two on three four five eight five nine nine seven Also guys leave a comment on this video and what i'm going to do is i'm going to pick one person That leaves a comment on this video with one lesson that you learned from this video to win a free month of m i c I've been doing this in the past in the other videos and we've seen a lot of traction from it You guys really like that So let's do it again. So comment one lesson that you learned from the video today um And yeah, i'll pick a winner in Probably the next day or the day after so thank you everyone for attending I appreciate everyone's kind words on friday, but right now now that i'm green I need to get back to my process. I need to get back to exercising I need to get back to driving my car to de-stress And I need to get back to kind of being excited to wake up the trade again Because this morning.  It's going to take time So appreciate everyone joining and I hope to have a better update either the end of this week or next week So i'll see you guys later


Good afternoon, morning, day. Hello, good, good, everything as well. Good evening. Hi, Emily. So I think Mathew is our facilitator today, but I do not see him dialed in. That's Mathew. Good day. Hi, Mathew. Farne for my delay started up my Windows virtual machine and it decided to do a couple rounds of reboots and updates without being told. So, and people wonder why I am such a Linux promoter. Should we give a couple more minutes for everyone to be on the call? I think there's gonna be a couple of people attending Brandon's presentation, so we may not have everybody today. Okay, I'll hold back for one more minute while I get my camera going and then I'm all good to go. Is there anyone that wants to take care of Scribe slash minutes today? I've already got Scribe on. Thank you, Emily. Fill in the blanks of Scribe too, share. Okay, so all good to go. I don't see any updates from the attendees jotted down this far and there was already a planned discussion slash presentation by Vinay, so Vinay, floor is yours. Great, thanks Mathew, thanks everyone. I wanted to share some ideas that I put down in issue 405. I have posted a link on the CNCF meeting document as well and without further ado, I'll get started with sharing my screen. So the idea that I've been working on for a little while as I've been scouting and scouting the security landscape is one thing that's missing is a security reference architecture for cloud native applications and the CI CD pipeline. And as many of us would agree, I mean, it's a very, very common theme that a lot of operators are struggling with. And so what I wanted to do was to actually propose this kind of a security reference architecture for cloud native applications as well as the CI CD pipeline with the goal of providing operators and DevOps architects a holistic view and an approach for cloud native security for them to actually understand what are all the different parts of the puzzle that go to actually injecting security and how do you think about security as you're building out large scale, horizontally scaled applications, microservices. And as we know that these are highly ephemeral so how do they need to think about the security landscape and how do they appropriately inject security throughout the entire lifecycle, from build deploy to run. And one of the other goals is also to provide operators with a blueprint in order to operationalize security. How do they think about it? What are the missing pieces? What should they be aware of? What are they missing? So the goal here is rather than for everyone to continue to reinvent the wheel. I think there is an opportunity for us as the potentially the six security group to actually say, here's how we index security, here's how you should be thinking about security, here's how you should be incorporating security for all your cloud native applications and provide a bird's eye view into what that looks like and also how do you build out like a entire process and a pipeline to match that blueprint and demonstrate and another goal that I thought would be really good was to actually demonstrate the mapping of all the CNCF projects in terms of the blueprint. That's a work in progress and I'll also talk a little bit more about that. And the other objective is also to figure out how we can actually make it available via the six security as a reference for, as we publicize this, as operators are thinking about, hey, what are all the different mechanisms and approaches that I need to be adopting and enforcing in order to inject security? And I use the word inject because traditionally we all have been in that world where security has always been bolted on but how do you now inject and incorporate security right through the development and the deployment phases and to actually provide this as a reference to the community for security for cloud native workloads? So that's the objective and the benefit. I don't have too many slides so feel free to interject if you have any questions, comments, suggestions as we go through this. May I throw in your way now, Vinay? Sure. So I guess you already answered a question. I always forget to ask at the beginning questions in the middle or same for the end. In terms of actually, I guess, encouraging people to adopt it, what would you say is I guess the most practical or pragmatic element that gets people to treat it as this is something we can integrate as we go without really many pain points or loss of project velocity versus, as you said, bolted on at the end sort of thing as an afterthought because there isn't time for it. What do you think is the key parts of what you're describing here that encourages voluntary adoption? So obviously it's, I mean, obviously the current problem is the, we'd always talk about it where security and DevOps are not meeting I do I, right? And I think that's firstly, that's the end just we're recognizing that's the fundamental problem. And that's also because security teams are so often brought in at the flag end of projects or, you know, so once all the development, all the everything is done and then security teams are made aware of it and saying, hey, now you can maybe just give me a stamp of approval as I really, really need to deploy this application into production. And that's obviously the reason for a lot of this friction. And then there is this concept that security needs to be embedded but then DevOps teams don't think that you have the right tools and the capabilities for them to really adopt with their need for agility. And then security doesn't think that DevOps knows how to get security, right? As a developer and as a security person myself, you know, I built large scale applications but I'll be honest, security was the last paradigm, right? That I think about, you know, because I need to develop this application. I need to make sure that it's highly available. I need to make sure that it's reliable. I need to go through all of that. So security is the last thing on my mind and we've always thought about it as someone else's responsibility. And to answer your question, maybe to say how can we change that perception is to provide DevOps teams with the right tools and the capabilities so that they can actually adopt it. And more and more, as I think about this, I feel like the key concept there is also developers are far more willing to make changes and fixes and address issues and bugs, if you will, when they're developing a new feature, when it's brand spanking you in front of our eyes, then maybe two weeks later or three weeks later when we've already moved on to the next feature or capability that we want to develop. So this actually fosters, meets the DevOps and the developers where they are. So providing them the right tools and the visibility and I'll talk about what that really, really means in the next slide. But, you know, when you're making a pull request, you know, make sure that your security debt is not continuously increasing. Unit testing, system testing, integration texting is fundamental. Let's make security testing fundamental. So putting in together these processes and showcasing the ideal state and empowering DevOps with the right tools really, really, really goes a long way in ensuring that they adopt those capabilities and incorporate security throughout the process. Is that, did that answer your question a little bit? Yeah, that's all the money. Thank you Vinay. Sounds good, sure thing. So what I, you know, put together is this concept of, the life cycle is so important when you talk about cloud native applications and deployments, right? Which is, you have the development phase. Once your artifacts have been developed, you know, you go through the build phase, these artifacts now are built in, you know, for our purposes, for example, the form factor is container images. You go through building all the different layers, pulling all your dependencies. You build your container image, push it into a container registry and then go through a whole bunch of testing. So I've identified four distinct phases, which I think we'll all agree with, which is develop, build, deploy, and then obviously the run phase. And what I've tried to do is in this particular view, I think this is the best practices view and then the next slide talks about an operationalizing view to say that, you know, here's how your code is being developed. You have different types of code, custom code, your dependencies that you're pulling in. You also have infrastructure as code, which is your Terraform templates, your CloudFormation templates, ARM templates, what have you, as well as you're now representing all aspects of your application as Kubernetes manifests, for example, right? And all of these is now going part as your code, if you will, including your infrastructure and all of these application definitions and you push them and you make a pull request, right? And then as part of this pull request, the point is to say that in your development phase, you have the ability to do various security scans. So for example, you know, we've seen even in my day-to-day that, you know, as we are developing so many new automation templates and capabilities, you know, once again, there are so many new services that we're leveraging, we don't really, really know all the high value security controls that you need to be enforcing and applying, right? So that's the point here. And if we could actually scan these templates, scan your Kubernetes manifest, make sure that you don't have insecure defaults and actually fail a commit, if you will, and provide that feedback to the developer, right at the commit phase, it's very, very powerful, right? So that's the point that you can do. So once those things are validated and if you, let's say for example, it goes through your validation and your policies process and the develop in the pull request phase, your code gets checked into your source code management and then in the build phase is when you apply the next set of capabilities. And I'm gonna talk about this more from an operationalization aspect in the next slide, but the point of this slide is to say, for example, in the build phase, and I also want to highlight the fact, hopefully it's evident by now, the light blue boxes are all the security capabilities, right? That you can enforce at all the different phases of the development and the deployment pipeline. So in the light blue is, once your code has been checked, you'll obviously want to run it through your static checkers. You want to be able to perform the vulnerability scans. You want to be able to do the image scanning, infrastructure as code scanning, as well as your Kubernetes. And then also the notion here also encompasses that, developers need to move fast.  But then when you go into the build phase, it's maybe it's now you're going from the dev environment to your test environment. In your test environment, you have stricter policies that you want to apply. So you have the capability of applying a different set of stricter, potentially stricter policies at the build phase, but then you apply all of these security capabilities and actions.  And then the, and then straddling the build and the deploy phase is the phase of testing, which I talked about. No code goes into production without going through significant unit system integration tests. And the point theme also here is that, we want security testing to be a mainstay as part of that process as well. So once you've done your application testing, so if you have failures, what happens is it gets pushed back, developers look into it, fix your bugs, fix your issues and it goes back through the process. Similarly, we want to apply the same rigor to security testing, where you want to scan your AMIs, your container images, your manifests, and your infrastructure as code templates based on vulnerabilities, config and compliance, scanning capabilities. A simple example, just to maybe I shouldn't make any assumptions, just to give you context as to what the compliance scanning for example is, right? When we want to deploy a cluster, for example, in GKE, for example, just making sure that your Kubernetes API server, for example, is not exposed to the world. Stuff like that. If you're having a database, make sure that your database is encrypted. You're ensuring that your keys are secured properly. Make sure that the database is not exposed to the internet. All those kinds of checks, and with this new cloud native pattern and paradigm, we have an unprecedented ability to catch it even before all of these assets are deployed into the runtime. And that's the point, right? And we can fix it. So it tremendously improves the security posture of applications that get deployed in production, if you will, right? So in the deploy phase, you have the ability to actually apply a lot of these security rigor testing and approaches. And then obviously in the run phase, which is either in your cloud or your on-prem across different asset classes, if you will, which is serverless containers, host VMs, you need network security, you need runtime security, you need the capabilities for micro segmentation, visibility, monitoring, logging, tracing. So all of these are fundamental infrastructural components that are absolutely necessary in order to run cloud native applications, which are once again characterized by scale and numbers and highly ephemeral characteristics. But this architecture and the representation is to help a lot of operators who are not as familiar as us who live this, have read this day in and day out to get a bird's eye view onto the concepts that they need to be aware of and thinking about as they are deploying cloud native applications. So on the far left, you have the different phases. And then on the second to last bar, I tried to kind of represent the applicability. So for example, the code commit is pretty much your develop phase.  And then of course, the run phase is pretty much your infrastructure, IAS, PAS and CAS capabilities. And the fact that you also want to have operate your policies across all these three or four different phases of the application deployment lifecycle. So, and then I'd love to have a discussion. I mean, this is just a preliminary. I wanted to put this out there, but I'll talk about that more. And once again, if you have any questions, please feel free to stop me. But the next slide that I wanted to talk about is, now how does, how do operators actually think about operationalizing? So this is more of the operational view if you will, to take a lot of those components that we talked about, but then how do you build and integrate and incorporate all of these different concepts and capabilities and tools into your entire development process, right? So once again, it starts with your DevOps, your users, your developers, your operations folks and others who are developing these capabilities such as custom code, your Docker files, Kubernetes manifest, infrastructure as code capabilities. And then we talked about being checked into your source code management system. Now you have the ability to actually have a commit pre hooks where you can actually check. And we talked about all the different types of scans that are possible to ensure that these are best practices, security controls that now you can apply even before your infrastructure is running. So you can catch all of these capabilities and flag it and make the appropriate changes. And then I also wanted to highlight the fact that there are so many different capabilities, right? So for example, with the advent of open source tooling, there's so much of open source. I've never worked at a place where everyone actually had a perfect visibility into all the open source tooling, the libraries that they have, all the licensing implications there are for both the library as well as ultimately their own application. So the source code composition analysis capabilities play a very important role. And then you actually now run through all your security capabilities, which is defined and then with the development environment policies, right? As I talked about it.  And then, so security is a first class citizen. You wanna be able, these are the best practices. I mean, these are the best practice steps that you need to execute. If they're evaluated, if any failure, if it results in a failure, you go back to the drawing board, go back. And then, so those things, there's a constant feedback loop for the developer. They're able to fix what issues they're now. Once again, I think the underlying theme also is we can't expect developers and DevOps folks to be security experts. But now with the right tooling and the capabilities, you have contextualized information on for them to actually take remedial action. And if everything is checks out, it passes, it gets checked into your source code management system. And then it goes into your build. So let's go ahead and build all these different artifacts. It goes and fetches all the dependencies. It goes through and builds your container images or AMIs or serverless images. And then your build artifacts are now checked in, for example, into your virtual machine catalogs, container registries, server registries. And then the next step is now, this is where I would love input from the folks in our group here, where now I wanna showcase how we wanna incorporate best practices in terms of signing images. We wanna make sure all your images are signed.  If there's a failure, go back to the drawing board. And then the next step is to perform your scans with your test environment policies. These are potentially stricter policies, right? So you make sure that your images are always scanned based on policies. Make sure that all your security controls are being applied accurately. For example, the NIST 800-190, there's an opportunity to actually bring that in into your build pipeline and validate that your Kubernetes or your container orchestration platform is appropriately secured. For example, you're not running your applications. That's a root user. You're not running as a privileged container. It's just so many different things that now we can actually catch and actually test for in your build pipeline. And then once this is passed through, then we wanna actually now, for example, this is where I want to bring it back to the vision that I have in terms of, let's talk about the in-total project, right? Where you're talking about software supply chain security. So this concept of this controller and how it can actually validate that your images have been signed. There has not been any kind of modification or changing of your binaries and your images, et cetera. But you have the opportunity to inject these policies and these capabilities at different parts of the deployment pipeline. And then you go into the deployment phase where now you can actually incorporate these steps to validate the image, the hash, the signatures, et cetera. And for certain kinds of using admission controllers, potentially runtime image policies and then your runtime compliance policies. And then there are three different capabilities yet again. And as you can see, which is the configuration, the appropriate security of the container orchestration platform, then the appropriate configuration for the host as well as the pods, right? So that's the kind of representation that I've tried to afford here. And you wanna make sure that you have the right policies. There are so many best practices and this goes back to now the platforms that we work in, whether it's Kubernetes or OpenShift or one of the cloud vendor managed platforms, it's still a shared responsibility model. So you have to, they give you the capabilities. So you have to make sure that they are enforcing the right capabilities. So for example, the NIST 800-190 is a special publication that talks about container and security for container and application containers. So there is a whole bunch of security controls. So you need to make sure that you are applying those best practices in your for your container orchestration platform. And there's so many different as I talked about, give you examples about privilege containers, et cetera. So, and we need to make sure that our operators are aware of them and then make sure that they need to take steps to actually enforce that. So here's how, here's providing an ability to showcase how they can think about enforcing those kinds of best practices. And then you talk about the hosts, make sure that the hosts are appropriately secured and configured based on your compliance controls. And then you also need to make sure that those hosts are appropriately locked down in terms of either network policies or network security, make sure that they're not making unsanctioned access to malicious domains, et cetera. And then we talk about pods, right? So you have to think about container and pod securities. Yes. Quick question, Vinay. I was wondering with respect to I guess one of the final deliverables, like if this was to be seen through to fruition, what do you see as the ultimate deliverable? Like is it a large, heavily documented slash well designed documentation wiki? Kind of like say, the Kubernetes documentation, does it have specific examples without necessarily advertising or advocating a specific implementation? Like here's how you do future XYZ with GitLab, with Jenkins or some other pieces like that. Is it meant to be a broad documentation project? And B, is it something, for lack of a better term, somewhat democratized in the sense that the request is that once it's in the right direction and it has enough maturity, CNCF officially adopts it and endorses it, for example. So I guess what are the desired implementation outcomes? Rough ballpark, I know that's always down the road and B, what's the intent in terms of, I guess audience and promoting it? Yeah, all great questions. So initially, I think the premise is that, these are very, very complex systems. As we can imagine, each of these is a big project in itself. Like for example, if you're taking into consideration hardware. No argument for me there. So I beg your pardon? Oh, sorry, I'll mute myself. I was just saying, no argument for me on there, I concur. Yeah, so, and that's the sense, right? So these are very, very complex projects. So we wanna actually help our operators and our users, ultimate users along the way in helping them understand how they can wrap their heads around it, how they can approach it, how they should be thinking about it, how they can adopt it, right? So the first goal is to give them some kind of a sense as to how they can, what are all the different components that they need to be indexing as they're putting together a plan for, fundamentally their CI CD pipelines for cloud native applications. But then I think we would all agree that we don't want to be, let security be a bolted on capability, right? So we want to constantly advocate that security needs to be built in. So we want to highlight all the different, psychogenetically speaking, the security capabilities that needs to be incorporated into this entire DevOps and DevOps process, right? So some kind of a consumable document that gives them a bird's eye view in terms of what are all the different components and then how can you operationalize? And then if this group feels like we can take it a step further, which I think we could in one example of that is to actually say, how do we take harbor? How do we take in total? How do we take tough? How do we take, I don't know, certain other capabilities, binary authorization, all those different capabilities and then take a generic framework and make it a specific use case, right? So I think there's potential to take it further and make it a little bit more specific. But the initial goal is to provide like a totally generic agnostic platform and potentially portraying the ideal state. I think that's my initial goal. But I think, and that's where I'd love to hear feedback and comments from the community here on how we could take it forward and elaborate and really make it useful for our users. I think, first of all, I just wanna say, I think this is great. I think one thing that has struck both me and I think probably is striking others is that this is actually very similar in many ways to the goals of both the white paper that we were planning to do as a group and the landscape. And I think, in fact, we, some folks who've been working on those two efforts have had met a week or so ago and came to the conclusion that we actually have a lot more overlap with what we're doing than what we were thinking, perhaps from the outset we might have. And I just wanna say that I think it would be good for us to all, like for you to join those conversations along with others that are interested in this because I think now that we're sort of three times independently seeing the need for the same thing and taking what on the surface looks like it has some very mild differences. But I think underneath really doesn't, is mostly the same way of presenting the same information. It would just be, I think, better for us to kind of converge on something rather than having three different almost identical perspectives on basically the same topic. Is there a specific conversation or a thread that I could copy paste a link to in Slack? Justin, just so we could say, hey, here's this presentation, here's the link to the YouTube recording when it goes up, let's converge these discussion threads. I'll have to look on that. Because what's largely happened at this point has been the landscape work has mostly been, Brandon and myself, although we have had a bit of feedback also from Yeeling and I think the write up has mostly been Emily and JJ. I think we've been sort of reusing the six security chairs and tech leads channel that we talk on sometimes for some of that discussion especially since we've really only had one initial meeting. So maybe this is something where we need to create a new channel and open it and let people come in and discuss or open the existing tech landscape channel and do that. Let me follow up with others and we'll figure out something to do this and we'll have that like making this a public thing that we'll mention how to get to from six security before the next meeting. Hey, Justin, could you remind everybody what the landscape is and then I'll follow up with a little bit about what the white paper is? So everybody has a understanding because I don't think we've discussed it often enough across several of these meetings. Got it, okay. The landscape, I think actually this diagram that's up is an ideal way to talk about what the landscape isn't supposed to be. It's basically supposed to be the flow of how... Sorry, so it's supposed to be a way for you to figure out what tools and processes and things exist to add security throughout the way in which you're making, deploying, maintaining, so on, your cloud-native application. And so the idea would be is that you could go into something like the picture that you have here, which we have a picture that's a little different in some ways but is kind of in spirit, fairly similar here. And then you can go and click on things and you can see like these are the concerns that you should have at this level. Like these are the types of attacks that have historically happened. These are the types of protections that are available and these are what will happen if you apply these protections. Like this protection here will make it so that it doesn't stop somebody from breaking in but it allows you to detect it very quickly and mitigate it. Or this right here makes it so that even if they break in the damage they cause is very limited in this way or whatever else. And the white paper is meant to be, well, actually Emily, maybe I should let you talk about that because you've been more involved in it. So the white paper is intended to be that, think of it as the landscape and the items that Vinay has been presented more at a high level C3 executive overview. A better understanding for a technology officer or a CISO to get a more clear insight into what cognitive and cognitive security is and how that intersects with their development life cycle. How does that affect their organization's ability to adopt specific products? Where should they be focusing some of their resources and some of the conversations that we've been having around that in the landscape is there's overlapped audiences are slightly different, but a lot of the information can be used across them. So with the white paper coming at it from the perspective of we have all of these stacks or ecosystems associated with cognitive practices, there's DevOps, there's the Buffer Development Life Cycle, there's your core stack, whether or not you're using platform as a service or functions as a service, whatever it is that you're deploying on or if you're bringing your own case and communication, what does that stack actually look like? And then there's just the general application development that goes into all of that. What is your application definition look like and everything that goes into it? So these are all, it's essentially the culmination of the problem that anybody in security or anybody moving into cognitive is having and we're coming at it from a bunch of different angles either from the top down or from the bottom up. Because we've realized that there are people across all sections of the community that don't have access to this information. You have to have been in for a long period of time to be able to fit all of this together. I have a question of the, oh, sorry, good evening. No, I'm sorry. So, Matthew, Michelle's had her hand up for a bit and the back of the other could have been. Yeah, I have a couple of questions. One, how would you like the feedback on this? Would you like comments on the document? Or do you want, I see you have it in GitHub. How would you prefer? Because I have specific comments about the order of eight and 10. I don't know why you would sign. If signing is intended as a symbol of immutability, why would you have eight before 10 and why is there no distribution mechanism in place to maintain integrity of the supply chain better? So I'd like to add that to the, however you'd like written feedback, but just let me know. Sure, thank you for that. I think you can, the commenting on the ticket would be fantastic. On the ticket or the document itself? Either, either. Okay, great, great. And I'm happy to contribute to this. I've worked on an attestation process before because I really think that it's more, it's about validation and attestation and it's, but I have some concern in that like the reference architecture that you're prescribing is, it could also be called the DevSecOps reference architecture, right? So, where's the value add? And there are millions of those out there, right? So where's the value add in specifically, like where are the differentiation points for cloud native, right? I think that's going to be important to note because this, a lot of people see similar things out there. Is that, sorry, I'm not trying to be... No, that's a good question. That's a great point. Maybe if I could quickly just sound out on that and I think some, I just opened the floor up and I know others wanted to have input. I think the value add for this group to be able to advocate for one of these kinds of reference architecture is they have a lot of thought leaders and subject matter experts and then putting our heads together if we come up with some kind of an accepted, validated paradigm that goes a long way in helping operators and adopters have confidence that they can adopt this kind of a paradigm which gives some kind of weight given the fact that it's been coming from this particular group, right? So I think that's the value I see in collaborating here and putting something out to answer that question. And Chase, I believe you wanted to say something. Yeah, I had a question or maybe it's a comment there. I don't know. Funny enough, I made this similar diagram just in the last few months for similar reasons, right? And basically this is very difficult to conceptualize and then without some kind of table conversation piece in the meeting with developers and other stakeholders just within my organization, right? You just need a thing to where everybody knows that you're talking about number seven or everybody knows you're talking about number six. And without having some kind of infographic, it's virtually impossible. So that's my experience. And it's interesting. I think it was Justin that there were kind of have been three variants of recognizing that all of the lego pieces are dumped on the table but nobody's really laid out like, well, if you wanna build a monster track, right? It has wheels, it has an undercarriage, whatever if you wanna build a pirate ship, et cetera, et cetera. But where I'm wondering if this is a gap and maybe it's an intentional honor. Maybe I'm way off on an island. But if I'm looking at this and I'm thinking about it in terms of just the CMCF in general, I wanna be able to go to four or five or 12 or wherever. And I wanna see what components of the CMCF ecosystem play here, right? If I go to the landscape, you know, when I was looking at this, I think I put in the notes that like if CMCF were a company, right? And was trying to sell all this stuff, you're talking about like a, not even quite a product roadmap, but like a portfolio view of like how all the components could fit together into a cohesive whole. But whereas this is generalized, right? Which is cool and maybe that's the thought. I don't know if any, I wonder if any of the three variants have a goal of saying, hey, this is where Harbor fits in. It covers some items of seven. You know, these points that cover some items of, I don't know what seven is here, I can't read it. But my point is just like, if I'm looking at, if I go and look at the landscape page for CMCF, all I see are 150 boxes. And they're grouped, but not, and they're sort of functionally grouped, but they're not process or workflow oriented in that way. Right? So for me, like if I'm looking at this, I want to use it as a translation mechanism for like, you know, I need one thing out of this bucket to fit in here, you know, but it's not clear at least to me how the buckets translate for say, okay, you know, service providers, I remember as a category on the landscape pictorial, but like, you know, where does that, some of them are pass providers only, some of them are whatever, that would be an easy one to sort of draw straight lines to, but if that existed, boy, I would be overjoyed and I would use it all the time. So I'd be interested in contributing. And again, I don't know if that was on your mind or if that's appropriate, but that's the piece of this where, from what I've understood of the descriptions of the three initiatives, that may still be missing at the end of the rainbow. Yeah, I think just quickly to highlight that, I think that, I think bullet number four, so that was one of the potentially the next steps where we could demonstrate the mapping of all the CNC, not all, but let's say as appropriate, you know, based on industry, I like what you said, you know, building this monster truck or I don't know what you said the other one was, some other maybe a spaceship or whatever, for all these different, I think that as we mature through these things, and I think it's applicable across all of them, and to actually showcase that, you know, here are ways in which you can put these Lego pieces together to your point. I love the analogy to build what, ultimately this is what you wanna build, but here are the pieces that you need and here's how you can put those pieces together to potentially build the Millennium Falcon, for example. So I said, but Millennium Falcon is also accepted. And Justin, correct me if I'm wrong, but the intent with the landscape is to provide that level case that you're looking for. Yes. Yeah, no, absolutely thanks for that, Justin. So I, because when I was on a call where I think you and Brandon talked about the landscape, and I think maybe I got something a little different out of it, because maybe the granularity with which that presentation was done, I think I was trying to provide a little bit more of an abstract view, but I think it could be highly complimentary, and I'd love to discuss that a little bit more. Yeah, so that's where the overlap between the landscape and the white paper comes in. The landscape is to provide that level of granularity with the explanations and the appropriate context for somebody doing that level of shopping, so to speak, where the white paper provides that higher level of extraction and the generalized concepts associated with it. Steve, what you presented kind of bridges that a little bit more between the two of them. That's something that the tech ways and the chairs have discussed last week. I see. Yeah, I mean, too much. I just want to jump in for a quick second. I just want to jump in for a very quick second to ask if Justin Cormack had an update or something you want to present. I don't see any specific issues or PRs, so just want to make sure you have a window of opportunity if there's anything you need to bring up. If not, we can leave the remaining 15 minutes for today's meeting with Vinay and everyone else. Yeah, no, I actually, I just wanted to conclude with one last few comments. You know, I'd love to collaboration and pick it out there. So if we can collapse all these into some other ticket that makes more sense, happy to do that. But, and Justin, if you could please just let us know where we could have the further conversations and how we could collapse these efforts, that'll be great. Awesome. So Vinay, this is great. You know, your input and the goals here, you know, align very much with something that we've been trying to tease out and everyone who's sort of approached how we lead and align everyone together has struggled with. Now, since I've been grinding on this particular problem for at this point, better part of two years, I want to level set a little bit on how we got here and make sure you sort of manage expectations in line with that. So, you know, the founding premise of, you know, the safe working group, secure access for everyone that eventually became a security was, you know, really to, you know, bring together the points of view around security that were underrepresented in the constellation of projects that, you know, the Cloud Native Computing Foundation brings together and the Federation of Corporate Interest that the CNCF represents. For better or for worse, we start, you know, this journey with a lot of these projects and they're contributed, you know, from a lot of different organizations.    We've ripped out a lot of the lower level components in our architecture that, you know, for the last 20 years, we've been able to make security assumptions on and those things are no longer valid. And then as we look at the components that we have in our system and, you know, how we pull them together, you know, that those things are all operating on a complex set of assumptions that, you know, many folks actually haven't aligned on or, you know, didn't have the context of what the underlying, you know, things were or how those things have actually changed. And, you know, all of those things need to actually be articulated so we can have aligned upon frames of reference that we can draw forward. You know, I think there's a great opportunity to establish robust consensus about what those pillars are, you know, just in sort of assessing, you know, where, you know, things might be heading in this articulation. The one thing that I can sort of get you an easy no on is I think that SIG Security, you know, defining a comprehensive representation of how this is all implemented for all the use cases is probably outside of our purview. You know, that is something that, you know, I've leaned on corporate interest in the past.  That is in my mind, you know, when you complete this journey, what success looks like is that we have, you know, organizations that are actively interested in pursuing the needs of those end users, aligning to the consensus work that we've, you know, built out or contesting those pillars and, you know, producing artifacts that, you know, that articulate the specifics of, you know, a reference implementation in line with the work that we can do here in SIG Security. Yeah, no, it totally makes sense then. I mean, just to summarize, I think my goal was just that I see this and I think we would all agree to this, that these are some common issues that we see on a day-to-day basis. And then just to, I thought there was an opportunity just to put out like a very, very generic framework. I mean, it's not, and I'm being totally vendor agnostic, right, which is, so just, this is kind of the, what operator should be thinking about as you think about these things because security has, for cloud native has always been, it's been problematic. And here's how a lot of the initiatives of the CNCF and a lot of those projects, especially, right, which I like, which is Harbor and Intoto and Tough and so many other mechanisms really, really go a very long way in helping getting better security posture. And now just to, here's how you could potentially operationalize it because I think, and I'm a bit, maybe I've gone skewed a little bit more towards that the maturity scale is all over the place, right, from an operator, so just to give them that context. And I think that's why, and not make any assumptions. And that journey is hard and it'll take a lot. And there are all kinds of ways in which folks kind of give themselves out, either they're too big or they're too large.  And expressing the needs that need to be addressed will help folks see, oh, okay, that's a consideration I haven't addressed and I can move on rather than, oh, this isn't valid. I need to think of DevSecOps reference rather than this. I think both can be valid, but if we're starting from that quote unquote pure cognitive perspective and articulating the key components that we see there, that's a defensible position. Right, awesome, totally makes sense. Thank you. So I think from what I can take away as a next step is to maybe have a few more discussions with maybe Emily and Justin and see how we can collapse these efforts and contribute to the existing work items and artifacts. That's good. And a lot of great points in the chat, by the way. Thank you all for the inputs. I mean, that's been great. And would love to see, do we get to save this chat somewhere somehow from this meeting? They are recorded and automatically uploaded to YouTube a couple of hours after. Even the chat on the Zoom chat. It is. I don't know, but I'll just copy paste it right now. Oh, that's included, Tim? Okay. It is included in the archive. We currently don't do anything with that or make that generally available. So it is, but kind of it isn't. So if we want to log this as part of the issue, what is it, 405? Then what Matthew's done of just grabbing the chat and dropping in that issue, probably the easiest way to make sure we close that loop. Just revisiting one thing. I'm just gonna call it one more time to Justin Cormack. Did you have an update? I didn't see the no update brackets beside your name. Sorry, no, I don't have anything this way. There's a couple of things I think we can wait till next week. How's this? Okay. Sorry, back to you, Vinay. And Dan. No, that's all I had, everyone. Thank you so much for your time. I really appreciate it. It's to my understanding, Justin Kappos will be picking up on the alignment of the, or at least bring up the discussion of the alignment of white paper and the communication channels used for that. And what Vinay has put together today, as well as the landscape. Is that something that'll be posted in the security Slack or a new ticket on the GitHub page? Yeah, I'll put this in the scheme in the Slack channel. I'll just put a link to this. I think what we'll do is just create a separate channel because we're gonna have a lot of conversation in here. And I wanted to talk with Brandon first to figure out if we wanna reuse the existing landscape channel that we have or abandon that and make a new one. And one additional question on the landscape. Does it, is it a landscape in the generic sense or does it literally use the CNCF interactive landscape like we do? No, it's generic sense. It does not use the CNCF landscape. And the few minutes we have left, does anyone else have any questions, comments, concerns? All right, so that wraps up for today, everyone. Thanks everyone for joining and hope everyone stays in good health and good spirits. Thanks, be well. Thank you. Thank you very much, thank you. Oh, I think you've got to ask it as a meeting. I'm still on, okay, thanks. Yeah, I miss the loss of chunk of the meeting. So, because I have other things to do. So I joined back, but like, No, well, thanks for reminding me. Now I think the recording will end. Nice to meet you. Cheers. See you.