Folks have filtered into the intimate room here that we'll go ahead and get started. And so I'm Robert Asker, I'm the product manager for OpenSecondNap. I probably should have asked if everyone here probably vous anglais, but you probably respond in French. I want to understand what you're saying, so I'm apologize to have to speak in English. Je ne comprends pas, francais. So I wanted to talk to you a little bit about OpenSec and NetApp, and what we're up to, the way we look at it, some of our development effort, more or less the state of the Union, the state of the art rather, with OpenSec and NetApp. So we're part of a, our OpenSec development is part of a group, a NetApp called Cloud Solutions Group, where we're looking at enabling a common data fabric across multiple different endpoints, to try and solve one of the, as of yet not fully solved problems of hybrid cloud, which is fundamentally the movement of data. It's the thing that's least like a power utility. It's, you've probably heard the metaphor several times, data has gravity, data has inertia, it's hard to move data comparatively, whereas compute turn on a light switch, network turn on a light switch. And so in starting down this path, we looked at what's within NetApp's portfolio of products. Fundamentally, there's a thing that most folks associate with NetApp called data on tap. It's the storage operating system that has been classically associated with the hardware that we produce. And that is the same operating system exists in all models of the, of the FAS line of, of the things again that NetApp has historically, you know, had success with. We're doing some things, we'll get into a little bit more detail here in a second that kind of changed the context where we can deliver data on tap and it sort of starts to grow beyond those physical pieces of hardware. But it's a great place to start in building a common data fabric because if you're familiar with Mac Offslaw, any given network is only, and I'm paraphrasing that's powerful as the number of nodes within it. You know, the more nodes within a network, the more powerful generally it is. So data on tap is actually the, you know, by most measures, the number one most common commercial storage operating system in the world. Not claiming NetApp is the largest provider of storage in the world, we're not, but because all of our platforms historically have been delivered with this common OS when you actually measure it, we're the most widely deployed single storage operating system. So it's a good place in starting to build a fabric. When you start layering on top of that that we're, I believe it's over 200 and some of the folks in the room here could probably confirm different service providers in the world have built services that are underpinned by NetApp capabilities, then you start to fill out this notion of a common data fabric. Well, that's only one part of the picture and so where does like OpenStack fill into that? Well, commonly we're seeing folks deploy OpenStack on-prem to facilitate a hybrid cloud model. You know, certainly I wanted to build my own set of capabilities that are AWS like. Maybe I don't necessarily intend to do business with AWS but increasingly developer tools expect like an S3 or an EBS or an EC2 endpoint. And so you can levy that of course against an OpenStack implementation. So increasingly OpenStack sort of starts to resemble that common infrastructure as a service control plane. And it's not always necessarily the open source bits themselves, the reference implementation. So, you know, for example, you'll see depicted here if you're familiar with the icons Azure. Microsoft's unrecorded saying we'll start actually over time when they're product managers stating that we'll start supporting API, OpenStack API endpoints on our services which isn't to say they're building Azure with OpenStack or intend to do so but rather that, you know, you can actually write code against an OpenStack API and run it against an Azure hosted capability. So we're seeing that kind of across the board. There was a contribution, I think it's a bit old now at least nine months old wherein there was shims provided for, you know, basic shims for Google Compute Platform wherein in the same way that you can actually, you know, levy application logic that was intended to be delivered against AWS against an OpenStack because of shimmed APIs. You can actually do that with some subset of the Google Compute Platform capability. And that's actually in, I believe, StackForget might possibly have made it into some of the upstream OpenStack projects on GitHub as well. So increasingly we're seeing it being the choice of, there's the various hyperscale providers, the largest sort of providers of public infrastructure as service capabilities. And there's a collection of others that sort of have that ambition, number of whom are actually building their public capability in this case of Rackspace, hpcloud.com, SoftLayer has elements of it. Likewise, they're actually wrapping some of their capabilities with something called, I believe it's called JumpGate which is a way of taking their existing compute as a service capability and making it accessible via the NOVA API. But similarly also deploying Swift. So increasingly OpenStack is that sort of common control point. Either in addressing everything through the native OpenStack APIs or through OpenStack's ability to actually function as an alternative some of these other capabilities through its own API shims or at the other end of the spectrum some of these other existing functioning as a service capabilities themselves wrapping themselves with an OpenStack API shim. This looks like over time it might become the standard control plane across hybrid clouds. We shall see it may not be the only one but as standard as we can hope for and not standards through some standards body that's ratified a bit but through ubiquity through common deployment. And of course, any of the different flavors of OpenStack clouds that you might deploy in your own prem or in a hosted capacity or another boutique sort of IS capabilities that might not be depicted here. So just a little bit more about what I'm referring to if you're not already aware just a selection of some of the OpenStack projects and their equivalence amongst AWS. It goes both ways. You can of course address OpenStack directly via its native APIs, these individual services APIs. Likewise, you could have intended to deploy against AWS and maybe you need to repatriate for reasons of economics or perhaps it's that classic hybrid scenario of bursting out for peak lopping for that once or twice a year. So kind of deviating from that sort of I'll come back to it in just a second. I just wanna talk about like, well, how is NAP involved with OpenStack? And by what means? The reality is as we started an open source data on tap operating system referred to is derived of BSD. And we regularly have kind of a push-pull relationship we'll push stuff into it and likewise syncs our own sources with it. We've been involved in a number of different places and we were the first major storage vendor to have participated in the OpenStack community having provided, having joined signed the corporate contributor agreement having provided upstream integrations having been a charter member of the foundation at the gold level which is sort of depicted here as well. So not only have we been involved for a while we've actually had a chance having been involved as long as we have to have matured some of our capabilities. Most of our upstream integrations most of our integrations started around Cinder we'll get into a little bit more detail about that in just a second. And I'm gonna move very quickly so apologize how fast I'm talking. Certainly be available to answer any questions afterwards. So the place we start with our platforms is to make sure that any of their distinguishing characteristics, any of the things that they do well are not hidden by the abstractions by the service layer that an OpenStack capability provides. We have customers who will use something like Cinder independently of the rest of OpenStack because they desire a single standardized block storage abstraction. And the modular, generally modular nature of OpenStack allows for that. There are certainly caveats. But, and that makes sense from a deployer perspective I don't wanna have to rewrite my application to PlanetLogic against a different backend and a different proprietary API if I decide to swap out backends or have multiple backends that are appropriate for different workloads or use cases or SLAs. So make sense to write against the Cinder API that standard abstraction. But as an abstraction it also isn't terribly nuanced in its understanding of distinguishing characteristics of individual storage systems. So the first place we start in providing integrations is to make sure that the things that are generally useful and interesting and different about NAP systems are accessible in the context of OpenStack aren't hidden by the abstractions. I'll get about into how we'll do that in a second. So that's what I'm seeing here. So going back again to this notion of data fabric and data on tap. Clustered on tap is kind of the latest evolution of that. It's not quite true. I'll talk about why in just a second. And it has the ability to scale up. Probably the better way of referring to it is scale out on tap. It's the ability to take a single capability, a single namespace, a distributed characteristic and scale it horizontally. Actually you can scale it both vertically and horizontally. And what we're trying to depict and it's a little bit abstract here probably in the way it's depicted is that on tap can actually reside atop of course NetApp hardware which is what's classically understood. It can exist atop our flex array flavor of hardware which basically functions as a gateway to other third party storage. You can take the capabilities of on tap and apply it to some of our competitors arrays on top of that. And likewise, the newest addition here and this was just announced last week is something called cloud on tap which is basically on tap as an instance in a public cloud. And so why is that interesting? Well you get all of the capabilities of data on tap. It's ability to support multiple different protocols as a storage server, all of its storage efficiencies but probably the most interesting characteristic of it with respect to like enabling a hybrid cloud is it's thin replication. It's well known and well hardened and established replication capability. Something we call snap mirror. So you have the ability to actually take workloads and move it from your on-prem to a hosted provider to an easy to provide that same data set in as thin a possible way in terms of network utilization. It's thin a way as possible to your easy to instances or to your instances in any number of different public or private clouds. And so this is how we're starting to build out that notion of a common data fabric. So close, I'm sorry, thought I heard a question. So let's talk about a little bit about the open-stack integration more specifically. The first place I mentioned we started was with block storage. I'm gonna talk about images, so glance because actually we didn't have to start. It just automatically worked. So there's two basic options for deployment of glance. If you're not already familiar, there's a file and then there's also a object storage backend. It turns out that unless you're deploying, you have images that immense in number. There's a lot of additional complexity in deploying Swift if that's really the only use case for Swift. Now it may very well be that you have a generalized object storage requirement and you also wanna host your images there that can make sense. But if the only thing you're really wanting to do is deploy a compute as a service capability, frankly, using the file backend is far more efficient. It makes a lot more sense. And what you basically get is automatically the benefits of deduplication. Now there's some other reasons to use this which I'll explain in more details in a second that has to do with our cloning technology. But it's not at all uncommon given that these are operating system bits to see 90 plus percent deduplication rates. Again, there's a lot of commonality from one image type to another. So this is just an automatic quality you got out of the gate. Excuse me. So moving on to object storage, the first thing, there's a couple of things that I wanna talk about here. So first of all, there is Swift itself, the reference implementation, the open source capabilities described in depth here at this summit. And what we do is we take one of our platforms, the thing I haven't been talking about today, which is something called E-Series. And we take a unique characteristic of it and take the 3x storage consumed by default in Swift's consistent hashing ring scheme. This is how it protects data. And we reduce it to 1.3x via a parity scheme. But you might ask, well, I've heard that you can't use RAID with Swift. And that's probably a generally true statement that it's not typically a good choice, not typically viable. And the reason for that is that you're commonly deployed in a capacity optimized manner. You're using largest possible spinning discs, six terabyte drives emerging now into the market. I don't know what the numbers are, but I know in the four terabyte range, certain scenarios, a rebuild could take upwards of a hundred plus hours. And when you look at the number of spindles that you might be deploying in a given sort of RAID set, if you will, you just kind of like do the basic math around mean time between failure. You might need to actually plan to run degraded full time, given the use case or the common sort of profile of Swift the way it's deployed. So it becomes untenable. I mean, because that rebuild time basically means you're running degraded, which means less protected and performance degraded as well. So we have a kind of a cool trick over sleeves with something called dynamic disc pools. If you're familiar with Crush, and I imagine this crowd, there's a fair number of folks who are, we use that same academic work, use that algorithm and deploy it within our, within our E-Series systems to deliver what's essentially a declustered RAID. And long story short is the number is anywhere between five and 10% of the time it would otherwise take to do a rebuild we can do with our dynamic disc pools capability. This is the thing that uses Crush. And so it mitigates that problem and now you can again effectively use an E-Series that you can effectively use a parity scheme, a RAID system if you will to protect the data and make it immediately consistent which is a quality that Swift itself doesn't immediately have. It's an eventually consistent model. And the numbers work out to be about 1.28x for protection within a single site. And clearly, very commonly you're actually architecting to actually protect against site failure. So you'll have other copies elsewhere. This doesn't solve for that basic problem, but it certainly reduces the number of copies that needs to be held in any given site. So a common case would be a 5x, five total copies of a given object. In order to protect it against site failure you would usually want minimum of two at the remote site so that if you do have a failure you don't have to reconstitute it across the WAN. So that 5x can process to about 2.6x if you're using E-Series on both ends. And that helps you scale more broadly and saves you money on operational costs, environmental costs as well. This is just depicting how it shrinks. Apologies, I got off script with my slide too. So block storage, again I referenced earlier, this is actually where we started. We started with a classic mode of that data on tap operating system called seven mode because that's what at that point in time is still the case. The critical mass deployed system in the world are actually using. Cluster on tap is probably a better architectural mesh with the design center for OpenStack itself. But again, you know, seven mode works. A lot of folks, you would like to actually use it in a deployment OpenStack and so we facilitated that. We moved on very quickly to cluster on tap. We had to pull it, we offer a lot of different options in terms of like providing the capacity through the block storage service. The thing that probably is confusing when you first see this is NFS. We're talking about block storage. What is the relevance there? And the basics of it are that the common use case for Cinder is you're providing persistent storage to either boot an instance or to add hot capacity to an in persistent capacity to an instance. So in that scenario, we can rely upon the mediating effect of a component called libvert if you're familiar with it and the hypervisor itself. Long story short, we are mounting NFS to the compute node which is where the hypervisor lives and files end up being treated as virtual block devices unbeknownst to the instance. All it knows is that's a block device and you know, get to interact with it as expected, the guest virtual machine. And the reason why we do this, and to be clear, we support iSCSI as well, I'll explain that in a second, is it's vastly more scalable than iSCSI is. iSCSI, in any given storage system, you're gonna run out of lones and initiators well before you're gonna hit any sort of logical limit associated with number of files in a given export. A common question we hear is yes, but I think of NFS as kind of shared storage in a single sort of fan-in problem. Except for that when you combine it with clustered on tap, you're able to actually supply multiple different storage servers inside of a single namespace. And with paralyzed NFS, you can paralyze that IO such that it becomes more of a distributed characteristic and it mitigates any sort of that fan-in problem that you might classically associate with NFS. Now that said, we do support iSCSI. For those that might be familiar with Ironic or perhaps actually the use of Cinder outside of the context of the rest of OpenStack where you're vending block devices to non-virtualized entities or non-managed entities, you need to actually supply something that can be mountable in a sort of commonly understood way, like supports iSCSI mount semantics. So we do of course support iSCSI as well and we try to treat them as much as pairs as possible, but for scale considerations NFS tends to be the better choice. We did add in iSCSI support to our eSeries systems and you'll see fiber channel layered in over this next release and possibly not fully complete until the second release to the L release, if you will, after Kilo. So one of the things that we did, I talked about this earlier about making sure that none of NetApp's distinguishing characteristics can be hidden by the abstractions that the OpenStack services present, is we developed and this is an activity within the community, this notion of a storage, yeah, a storage service catalog essentially. And what you basically can do, and I'll actually move ahead to this, well, you can deliver any number of different things to your tenant base. You can define it, this is arbitrarily defined, red, blue, green, whatever it is that makes sense here, we're depicting different types of workloads that might make sense to make a catalog available to. So these are composed, these by the way in Cinder parlance are called volume types, these catalog entries and you compose them with unique characteristics of a given Cinder backend. So for example, perhaps archival is compressed, perhaps it's duplicated aggressively, perhaps it's on big, slow, status spindles, something to that effect and perhaps it's the database is on all flash, perhaps it's replicated because you have high uptime and DR type requirements, that type of thing, but you get to administratively the deployer of the OpenStack cloud, the Cinder administrator if you will, define what this catalog looks like. This is just a quick sort of depiction. Here we have a case where we've basically established a volume type and QS specs for a gold, silver, bronze type of capability and this is just depicting via horizon, somebody actually selecting when they want to hey, give me a Cinder volume, I'll select the volume type. I won't bore you with the whole demo and I'm kind of running out of time so you can see they selected gold and gold happened. Well, let's say if gold was let's say this case, they selected silver, silver in this case is defined as having a replication relationship, the container is automatically replicated. Hey, give me eight instances that are booted from volume of type silver. Silver happens, the instances are created and it's created in a container that is automatically replicated perhaps to a DR site. Just an example of the type of thing you could accomplish and the key there is offering the flexibility to build the catalog the way it makes sense for use cases. So moving on to some of the optimizations we did with both Glantz and Cinder, in particular for the cases of creating instances. So by default, if you're not familiar, when you create a virtual machine in OpenSack in Nova, it's what's referred to as ephemeral, which means that it's not, there's no guarantee of data being retained over a boot cycle. You should assume that it won't be retained and it tends to actually be entirely booted off of the local disk on the compute node. So it's problematic to do things like live migration of an instance, running instance from one place to another. So when you use Cinder's boot from volume capability and you use it with NetApp Cinder drivers, the data on tap Cinder drivers, you actually get a different characteristic. So one, those instances are by default ephemeral. Or I'm sorry, persistent. You can treat them as ephemeral if you so desire. It's just a flag you select. The instances come up much, much faster because you don't have to copy the boot image bits all the way down to the compute node upon first boot of that instance image type. We actually clone from Glantz. So if Glantz is on the same volume on the NetApp, when I say volume referring to a NetApp flexible volume, not a Cinder volume, if Glantz is on the same flexible volume as the capacity store for Cinder is, we'll just immediately clone it. Now if it's not in its elsewhere resident on our cluster, we'll do something called copy offload, which means we'll copy it across the cluster interconnect in our storage system. Doesn't have to wash it through the host running the Cinder back in. And if that doesn't exist, perhaps actually Glantz is based on Swift or something to that effect. We'll copy it at once and we'll cache it. Now in fact, Nova does that as well, but it's atomic to the compute node. So your cache is only as big as what is cached on your compute node. When we cache it, it's global to your entire fleet of hypervisors. And so instances come up much faster. They're immediately storage efficient until there's a net new write in that new def of any form from the original you booted and they're persistent and it facilitates live migration. And for some folks, it also allows them to boot their compute nodes stateless, meaning like I don't want local disk in them. If that's something you care about. So that's an optimization we added, I guess two releases ago now and we've added further optimizations too. So moving on to something new to OpenStack. Pardon me, I got far away. And that's not my water. So I'm not gonna drink it. Shared file systems. So not prior provided for an OpenStack. Problem though is if you kind of view OpenStack is the sort of de facto, and we do, open infrastructure as a service capability. I mean, I think it's established itself as the winner, if you will, in open infrastructure as a service. That about 65% of storage infrastructure in the world sold as recently as two years ago, and apologize, I don't have newer numbers, was to underpin shared file system deployment. And even if that number's changed, it's still a very significant portion of the market. And what you don't have within OpenStack is treatment for shared file systems, delivering them as a service. And it's kind of understandable why there's quite a lot more complexity involved than there is in delivering something like a block storage service, something we've become very intimate with as we've delivered that capability called Manila. So Manila is more or less what Cinder does, except for for shared file systems. And it's built to be agnostic to the file system. So SIFS, NFS, GPFS, GlousterFS, you name it. It could be provided for, and in fact in the process of, is in the process of being provided for, certainly the NFS and SIFS from that directly, some of the others from some of the other folks that we've brought in and built a community with. So this is now a formally incubated capability, meaning the OpenStack Foundation Technical Committee has assessed it and it's met all requirements for formal incubation. So it is formally part of the OpenStack fold. This is something that NetApp initially conceived of, design, prototype, submitted, built community around and we are continuing to lead. The Manila Project Technical Lead isn't NetApp employed, for example. There's a separate session, I'm not going to turn around for any more detail. There's a demo and four more additional info in a subsequent session. I think it's actually the one immediately following this on Manila. So please catch that if you're interested. And by the way, also hack at the bits, getup.com slash OpenStack slash Manila if you want. Just a bit about like what we're seeing. So this is numbers that we derive from our auto support capability. So this is if a customer of NetApp desires to supply information to NetApp for support purposes, they have, we have a phone home capability call of support that can supply this information to us. Of course, some folks opt out of it. Some folks would prefer not to supply it to us. So this is not all inclusive, but this is a relatively good representation and probably for obvious reasons, I've not included the actual numbers, wouldn't be appropriate to do so for a variety of reasons, not the least of which we're in kind of a quiet period for reporting our financial results. We've seen a huge ramp just within this calendar year, 285% growth in deployed systems and also a huge growth in the number of customers who are deploying OpenStack on NetApp. And the only thing we can actually measure with auto support is actually the sender stuff. And none of the other stuff I talked about is measurable via auto support. So long story short, this is growing really, really rapidly. Those are pretty, pretty enormous ramp numbers just within this calendar year. And we weren't starting from zero. We were already per the OpenStack Foundation user survey the most widely deployed commercial storage option for sender deployment. Another quick note about the way we actually deploy or the way we do our integrations, we do by default provide them upstream. It's not to say that we can always do so for an actual property reasons, but when we can, we provide our integrations into Upstream OpenStack. And we do that because it's not at all clear to us or for that matter, so far as we can see anyone else who ultimately like the prevailing options are gonna be for distributions of OpenStack. There's a lot of reasons to do it. It provides freedom, the ability for folks to actually like modify our integrations to taste in your own particular deployment. More commonly though, it's just the case that some of you may wanna deploy Ubuntu, some ReLOSP, some Nebula, SUSE, it goes on. At last count, I think there's something like two dozen different sort of readily identifiable OpenStack distributions. Our stuff is in all of them because we are upstream. Just a little bit of a summary of what we've been up to the last two releases. So some of the stuff I talked about already, we delivered our E-Series system enablement for Cinder. I didn't really talk about that, but I briefly did. We also have the ability to stand up E-Series behind Cinder and employ that same storage service catalog construct. We layered in the paralyzed NFS stuff at that same time that the copy offload capabilities I mentioned, that was an additional optimization for improved instance creation. It's a new thing, a nice house release. A big emphasis for us is in building reference and solution architectures. And so we were just starting on this path that's gonna expand fairly rapidly. A big goal when we deliver reference architectures to provide accompanying automation in hand. So if we give you something for example, RELL OSP and High Availability and NetApp. High Availability, a reference architecture for deployment of open stack services with a RELL OSP distribution and NetApp back ends. We wanna also provide you the appropriate accompanying automation to make it so. So reference architecture could be an interesting reading exercise, but wouldn't it be more useful if you could just in a simplified manner deploy it? So that's a goal is to provide puppet manifest and chef recipes where possible with each of our reference architectures. In June, we got Manila Incubated, which was not an insignificant effort. Some of the rest of the stuff that you have here is you'll actually see some of our puppet and chef enablement for our platform is actually just now rolling out. And we implemented support for a capability we don't have time to get into here called pools, cinder pools. And that dramatically improves behavior on our cluster non-tap systems in particular. We've got a lot of stuff planned for Kilo if you wanna hang around afterwards, we can talk about that in more depth. You know, we do partner. I mentioned that we're in any of those different distributions. It's not to say that we don't like do explicit partnering activities. It's not an all-inclusive list, but those are certainly some of the folks are more significant. I guess I forgot to mention MetaCloud. Forgot to remove MetaCloud since they were acquired by Cisco about a, I don't know what, a couple months ago. So we have activities in terms of reference architectures with Red Hat and Rackspace. We have ones underway with SUSE. We have more to come in this particular respect. And I'm particularly interested if there's anyone in the crowd afterwards, if you're using something other than Puppeter Chef or configuration management, perhaps an Ansible Assault, trying to measure like general, gauge general interest on that as well. So this is actually in the process of rolling out, like I mentioned. In fact, actually just two weeks ago, the first Puppet device module for cluster non-tap was made available on Puppet Forge. So that's a very new thing. So just a little bit, I guess in summary about OpenStack and NetApp, we are enabling that common data fabric across multiple different cloud endpoints, which is facilitate, you know, hybrid cloud. And that's just, we're just starting on that path. Our announcements around cloud on tap are an example of kind of directly where we're heading. So there'll be more detail on that here. I apologize if I didn't elaborate. Just to give you a picture of where we see OpenStack relative to that. One of the things that we see a lot of folks doing is using us, you know, a slice of our system in POC. Sometimes they'll use other set of capabilities. Perhaps, you know, local disk is used in a variety of different capacities, but when it comes time to support production SLAs, oftentimes there's no second conversation about reliable storage, reliable back ends, high performance storage. And so, you know, we participate in a lot of POCs, but also we also participate in a lot of activities and changing the storage back end when it becomes necessary to actually keep the lights on, so to speak. And so, you know, the fact that we're well integrated in, you know, a hardened capability proven over many years with a lot of additional features is, you know, kind of removes a lot of the risk for OpenStack when it of itself has a lot of moving parts. The fact that you can actually deploy, and we have a number of folks that are doing this, deploy infrastructure for both kind of that cloud native application infrastructure and your classic sort of maybe POSIX belt application infrastructure on a common, efficient, single proven data infrastructure is something that we've seen a lot of folks find attractive. It seems net inefficient to necessarily have two separate environments for that. And some of the things that we're doing at NetApp are aimed at trying to specifically bolster individual OpenStack services such that they can be used for more classic application deployment. Again, to support classic, you know, high SLAs given a different model of application at the same time facilitating, you know, that cloud native fully fundamentally distributed application, maybe built of paths, that type of thing. We are very heavily invested in OpenStack. We were, again, the first to have provided integrations upstream, very active within the center community. We've led Manila to this point. We have more detail in the subsequent Manila session about like essentially the community road map that we're helping drive. If you are interested in additional details, netapp.com slash OpenStack is probably the best single place to go. There's a particular document there called the NetApp OpenStack Deployment and Operations Guide that talks about, you know, not just the configuration setup, but ongoing care and feeding, how to do this. This is, I think, in its fifth revision, possibly, maybe sixth. So you can find that there, Twitter, and then also for those who use them, the development community or deployment community, find us on free node where they're on IRC, OpenStack-netapp. Happy to talk with you there. There's a number of sessions here as well. So, of course, there was one earlier today. I'm not sure if you're aware, but most of these are recorded, I think all of them perhaps, and will be available on YouTube later. I'm sorry, I went through these too quickly. There's a demo theater, I think it's tomorrow. We have a Manila session, we have a use case showcase session later today. We talk about, like, some of our particular customers and how they're using OpenStack with NetApp. And, likewise, our booth is over here. I think it's on the second floor. So, love to have conversations with you or answer any questions you have. We'll, of course, be there and force them Vancouver. So, we still have the rest of the weekend here in Paris, but just looking forward six months, we'll see you there as well. Thank you. And I even actually finished a little early. Thank you.


Well, I think what makes our products and services truly unique is quite honestly the people, the people at this company. The folks that have come together to create something brand new, never seen before, never applied to cybersecurity. And what we've been able to do with that technology and really apply mathematics and algorithms for the first time to cybersecurity is predict and prevent attacks, not just today's attacks or yesterday's attacks, but tomorrow's attacks, attacks we've never even seen before. We can actually apply this technology and prevent in real time. And that to me is the truly unique capability that we have. So what's enabled us to be truly, truly innovative, I really believe, is a core team of folks that wanted to change the world quite simply to forget everything they had learned about how to do this thing called cybersecurity and start from scratch. And by coming together in the very early days and really creating a company out of nothing and having starvation be our driver, we've achieved something that we quite honestly didn't know would be possible, but when we did, when we saw it happen for the first time, we knew we could change the world with this tech. Well, I think our company can improve the state of the world in a couple of ways. First of all, just applying the technology to endpoints around the world and being able to truly prevent the future attack that has been so elusive in our industry. You know, we've been so reactive and now for the first time with this math approach, we can actually predict and prevent future attacks. But also more importantly, we can get this technology in the hands of those that quite honestly can't always afford it. So through our philanthropic efforts, we can actually empower and enable organizations like charities around the world to get a hold of our technology, protect themselves and protect those that they're serving, even though they might not be completely financially capable.


Because at the end of the day, when I'm coming here, I'm like, I ain't got no problem with say cheese.  Like how can you be too big to mess with a nigga when you I was one of them trampolines you jumped out for? Yeah. Yeah. Cause I definitely I rocked out to your music before. No, but I gave you your first interview. I was that trampoline. Now, I had no idea you had me much better than me.  I'm so good at this. They're like, they're good, but they're not. So, they got better than me, and I'm not that to be like, they're better than me. But they got better than me. Like, they got better than me.  He was happy to tell it Huh? He was happy to tell it Yeah, he was happy like and I'm like, you know, you came and ate my food You know, you can't now you came and got up under that pressure though because what what I was asking you and telling you You didn't have no answer for Now you now you probably do you is one of them niggas who think you too big but nigga you'll get a reality check Wow, so when you when you were talking to him because it was It was a thing that I heard about it, but I didn't tune in i'm not for the sit here and play I don't I ain't for to say I watched it I heard about it because y'all popular as hell You know what?  I don't answer calls You know my secretary got to do this and that and this and I'm like but he's saying bad on getting back to you working on that He's saying he working on trying that what he told us here, but he takes me though Now he takes me soon when he felt some kind of pressure But when I was tech just as a what's up on that interview you didn't reply No, but I get it because for some reason he got them y'all niggas got that resentment toward a nigga like A nigga didn't do something for them or something Yeah, this whole game man that internet games is it's different man Now you want me to go and compromise myself?  I'm like fam like she what you doing for the city though No, I I got which I felt what you were saying or they because you had me thinking like The other day I was telling them like man I'm for the start doing some different things to try to promote the new music when it come out And I'm asking you know because you hit me Yeah, I just I was just saying that We gotta figure out a way to do that to promote the new This is what I'm on. We could I said he got more bloggers in the A lot a lot didn't damn near anybody we got and our bloggers got got some got some you know got some got some Yeah, doing those emotions. So with that being said I be like I look at it from the outside looking in I be like man we with us with us having all these bloggers I see this supposed to be up up when I say up up It's supposed to be three four five artists jumping all at one time right now because we got three four five bloggers That they can put they said they dumber together collectively and put their mood to motion together collectively and blow up three four Five different artists is because y'all controlling the goddamn me the media


From a high-level perspective, when we look at the software supply chain we have four distinct steps that make up the supply chain. First is we're developing our code. Next is we're building it. Then we're deploying it to our platform of choice, and then we need to monitor our code's behavior on that platform of choice. And all these need to be as secure as possible. So how do we do that? First, whatever you're using as foundation for your software development efforts should come from a trusted source. The source that provides curated content with attestation and provenance, be it application libraries, runtimes, or even base images. We're talking a lot about shifting security left. Well, what does it mean? It means we need to support our developers. We need to give them tools to develop code in a secure fashion, identify possible problems early on in the development cycle, but also not stand in their way. Developers want to develop the next cool feature and not deal with security tools all the time. Well, it goes without saying that we should automate our build process as much as possible. Additionally, we should think about augmenting our build process with security steps. So our pipelines should automatically sign images when they're built. Verify artifacts have they been signed. Automatically generate attestations and S-bombs, software builds of material. And the same is true for our deployment process. Whatever we deploy to our systems should have been checked and scanned thoroughly. We should make sure that whatever we deploy adheres to our best practices and standards, our policies, and comes from a trusted build system. Has it been signed? Can we validate its provenance? Does it have an S-bomb attached? Is it salsa compliant? And additionally, in the case of Kubernetes, does it follow deployment best practices? Have limits been properly set? Last but not least, in our efforts to evolve from a software supply chain to a trusted software supply chain, we need to monitor our systems and we also need to be able to do a risk assessment. If a zero-day exploit hits or if a CVE has been identified, where am I using it? Is it affecting me? And if so, what's the blast rate use? With that said, I need to be able to evaluate S-bombs, software builds of material from our own development efforts, but also from trusted vendors that are provided to me. Now that we know what needs to be done to evolve from a software supply chain to a secure software supply chain, let's take a look at what Red Hat trusted software supply chain products can do to help. Well, the first step is pretty straightforward. As Red Hat, we have been providing trusted enterprise open source software for more than 30 years. From Red Hat Enterprise Linux to Application Service, from the Red Hat Maven repositories to OpenShift. So let's see what tools we can give our developers to support them in building secure applications in a secure and trusted software supply chain without getting in their way. We're starting with Red Hat Developer Hub, the enterprise ready and Red Hat supported build of the popular backstage open source project. At the core of Red Hat Developer Hub is the catalog, where a developer can look up and find all components of a company's development landscape. I have been asked to work on the accounting system, so I'm looking it up. I'm checking the accounting system system diagram, and I can see what components it consists of. I could drill down into any of these components from right here and start working on them. But let's look at another example. So I have been assigned ownership of the DB backend component. I open the components home page and check the documentation, which is by the way documentation has code. And as such part of my Git repository and surfaced here in Red Hat Developer Hub. I can open a browser based IDE to start working, or I can open the Git repository right from the component home page. As a developer, I know how this works. So I'm cloning my code and start working in my preferred IDE. Using OpenShift Dev Spaces, following the link from the component home page, I can start working on my code directly here in my browser. OpenShift Dev Spaces based on Eclipse J provides me with a fully working development environment, natively on OpenShift. All the IDE features, plugins and tools needed for a specific task are configured via a dev file, which is also stored along with the components code in the Git repository. No need for complicated VDI setups or developers struggling with lockdown workstations for security reasons. We can work with our code and tools needed right here in the browser. Maintaining existing code is okay, but developers want to build things. Where do I start? To avoid reinventing the wheel for the 100th time and give developers a meaningful starting point and also provide coding and security guard rails, we start building with software templates. Templates tailored for specific tools, languages and requirements. As part of the Red Hat trusted software supply chain, the example templates are built with security in mind, that can be easily adapted and tailored to your needs and existing tool chain. As we can see here, using a template starts with picking the one that suits my needs and filling out the wizard's forms. I just gave my new component a name, since this is Java also an artifact ID, selected the container image registry and the Git repository location. And now a lot of things are happening under the hood. Based on the input, a Git repository has been created with meaningful code as a starting point for the developer, based on what the requirements were, be it a REST API in Quarkus or a backend component in .NET C sharp. Along with the starter code, which can also include guidance on how to use it, we have been provided with the OpenShift DevSpaces configuration that is needed for this type of component. Another part of the package are the Argo CD, aka OpenShift GitOps, manifests to deploy this application. But before we can let Argo CD do its magic, we need to generate something that it can deploy. So, following the true GitOps approach and pipelines as code, the secure pipeline needed for this component, along with the webhooks, has also been instantiated and published. The new component that we just created has also been published to the catalog. While we can open the newly created code repository from right here, let's check out the components homepage in the catalog. We can see that Argo CD is now syncing the application's manifests and creating the requested OpenShift namespaces along with it. Let's make some code changes now and see what it means to shift security left. From our Git repository, we copy the repo URL, clone it, go into the directory, and start working with it locally in our IDE of choice. We're following a documentation as code paradigm here. So, developers can add their documentation right here in their repository while they're working on their code, which is closer to developers work than regularly or maybe not so regularly updating some other wiki page. We can also see some other documentation has already been provided as part of the template. Let's just update the start page here quickly. Next, let's modify our new application start page so we can see our modifications later in the running application. We're just modifying the call of welcome message here. We said this is a Java application since we used the Quarkus Java template, so let's quickly check out the Maven POM file to see the dependencies used and maybe add some others as this is a starter code provided by the template. Opening the POM file automatically kicked off the Red Hat Dependency Analytics plugin, checking for known direct or indirect vulnerabilities in your project's dependencies. These findings are shown as individual problems, but we can also open the detailed report to assess the findings. In the report, below an overall vulnerability status of my project, I can see individual vulnerabilities, their severity, impacted dependencies, but also available remediations, along with some background information about what is causing the problem. Let's close the report for now and go back to our POM file. Problems introduced by dependencies are also highlighted accordingly. Let's just say, as a developer, I have been searching the Internet for a specific solution to a challenge I have. Why reinvent the wheel, right? So I want to use some code I found, along with the required dependencies, and I paste them here. Ctrl C and Ctrl V are my friends as a developer. I can see now that accepting them verbatim was probably not such a good idea as some critical vulnerabilities have been highlighted now and I have now 23 direct vulnerabilities in my code base. Unknowingly, I have introduced two of the nastiest vulnerabilities of recent times, log for shell, and the prominent struts vulnerability that was the cause of the Equifix breach. But fear not, as we can see in our detailed report, remediations, along with background information are available directly from the report. Giving this critical information to the developer enables him or her to fix these issues early in the development cycle. While there are other security measures in place in our trusted software supply chain that would have caught these, the developer needs to fix them anyway. So shifting security left, giving the developer the right tools, saves time. We have fixed these issues by removing those dependencies from our palm file. Ctrl Z is another close friend. Let's move on and commit and push our code. We want to see it in action. We're ignoring the vulnerability that just popped up for now. Give it a commit message, add a docs, change dependencies, and commit our change. Now a browser window pops up, asking us to log in. We're using git commit signing with Red Hat trusted artifact signer, Red Hat's built of the six-door project for keyless signing. That means there is no need to manage, issue, and distribute key pairs that need to be revoked, rotated, and that the developer needs to take care of and have yet another password to remember. The signing process is tied to the OIDC identity and trusted artifact signer issues a short lift key and stores the event in a transparency log. Back on our new components homepage, we check the CI tab and can see that our commit has triggered a pipeline run. As developers, we might not be overly interested in the pipeline steps details, but we want to see that our code commit made it through. So we want to see everything from the context of our development process, which we can. We see all the details of the pipeline run right from the component page without having to go to yet another system. Regarding the pipeline, we want to see as much green as possible. Green is good. Without expanding the visualization, we can also check our pipeline status from this progress bar. We can also check the logs of each individual pipeline task right here. In this case, we see that this pipeline verifies our Git commit. No unsigned commits or commits by the wrong people for this application will even be built, let alone packaged and deployed. We can see that this commit verification has passed. The developer has given this code commit the commit message wrong signature as the previous commit was signed by the wrong person and wouldn't go through. So he tried again with his ID, ultimately taking responsibility for the commit. So the verification and signature check is okay. It also has not only been signed and the signature could be verified, but it also has a matching corresponding entry in the trusted artifact signer transparency log. Called Recore. Another insight are security where developer can get directly from here is the pipeline output. In this case, a security report from Red Hat Advanced Cluster Security for Kubernetes. During pipeline execution, the build steps generate a container image. This image has been scanned and checked. The output shows image scan results, image checks, which are policy checks taking the scan results into account and a deployment check, verifying if best practices have been adhered to. Before moving on, let's quickly check what went wrong with the previous pipeline run.  The commit had been signed, but none of the expected identities had signed it. Which identities are acceptable will depend on the use case and can be adapted to specific requirements. So we're not only checking that a commit has been signed, but also by the right person. As a developer, I want to see my application running. So from the component homepage, I go to the topology tab. I can see that following the successful pipeline run, Argo CD has deployed by application in the development namespace. As proof, I can see my modified greeting. Additionally, following the documentation as code mantra, I can see my updated tech docs right from the link on the component homepage. Nicely rendered, as I would expect it. Let's close the loop and move one step further to pre-prog, our next stage. I create a tag in our code repository, and as we can see in our CI tab again, another pipeline run has been triggered. This pipeline is the promotion pipeline and consists of different tasks than the build pipeline. It uses enterprise contracts together with trusted artifact signer to verify SALSA compliance, among other things. SLSA, or SALSA in short, stands for Supply Chain Levels for Software Artifacts and is a security framework of standards and controls that prevent tampering, improve integrity, and secure packages in infrastructure. Core pillars of SALSA compliance are the existence of build attestations, signatures, and software builds of material, all of which have been created in our pipeline and have been attached to the image in the registry. While this can be easily accessed here through the image registry tab, a more detailed view is available through the link to the Quay registry. Here we can see that the images we created have been signed via COSA. As an additional security layer, Quay scans images at rest. If your pipeline hasn't been run for a while, or if an image is pushed to the registry that comes from a less secure environment, Quay is scanning all images in the registry. From here, you have access to CVE details as well as security advisories pertaining to those vulnerabilities. The same vulnerability information as well as access to the security advisories is available from the image registry tab on our component page as well. Going to the topology tab, we can now see that our LCD has synced and deployed our application to the pre-prod namespace. Closing the loop, we create a release from the tag we created earlier, and we'll see that another promotion pipeline is triggered. While this pipeline is running, let's quickly take a look at the previous runs pipeline output. When we have a detailed view of the rules and policies that have been checked using enterprise contract, validating salsa compliance of our artifacts and build system. Going to the topology view once more, we can now see that our application has been deployed to the production namespace and the cycle is complete. So far, we have looked at the build or CI continuous integration process from a developer's perspective. How we can support developers to make their lives easier while stepping up security measures at the same time, effectively shifting security left. Now let's look at our build pipeline in more detail and which Red Hat products specifically provide these capabilities. To automatically sign a code commit, we use git configured to use git sign. Git sign itself was configured to talk to Red Hat trusted artifact signer and points. This challenged the user to sign in and tied his identity to a commit signature. Similarly, verifying a code commit uses git sign for retrieving and verifying commits against the keyless signing infrastructure provided by Red Hat trusted artifact signer. The build sign image task uses Red Hat trusted artifact signer and cosine to sign the image that has just been built. As a next step, an S-bomb, software bill of materials of the image is being generated and stored in Red Hat trusted profile analyzer for managing S-bombs, CVEs and security advisories across your company. Additionally, that S-bomb is attached to the image, both of which are stored in the Red Hat Quay container registry. Red Hat Quay then starts scanning the image for vulnerabilities. The three ACS tasks in our pipeline use Red Hat advanced cluster security for Kubernetes and its Rux Control CLI binary to scan the image, check if any of the scan results violate the policy and furthermore checks for Kubernetes deployment best practices. For example, if there are appropriate limits set on a container deployment. Moving the pipeline visualization a little further to the right, the Query Recore Sign Provenance task uses another trusted artifact signer capability, the Recore Transparency Log. This task checks if the build provenance or the attestation of the same has been signed and attached to the image by querying Recore for the SHA or SHA value of the attached attestation. But how is this attestation of the build process generated? Red Hat OpenShift Pipelines, the enterprise-ready build of Tecton provides Tecton chains. Tecton chains is a Kubernetes controller that watches all task-run executions in a cluster. Upon completion, it creates a snapshot of them, signs them and stores them, in our case as a signed attestation attached to the image. The check mark signed next to a completed pipeline run notifies the user that Tecton chains has run and signed the task-run snapshots. For the signing process, Tecton chains also uses the Red Hat trusted artifact signer infrastructure. To enhance the security of our deployment pipeline, we need to verify attestations and signatures. Nothing that doesn't provide appropriate attestations and signatures should ever be deployed on our systems. For the deployment pipeline, Red Hat trusted software supply chain uses Enterprise Contract, which in turn uses Red Hat trusted artifact signer to verify signatures and attestations. Enterprise Contract applies a number of policies defined in the Rego policy language to an image, primarily validating itself as a compliance, but can easily be extended with additional policies. The last pillar of any secure and trusted software supply chain is monitoring our systems and being able to react to new exploits or security threats in general, managing our overall security posture. In the Red Hat trusted software supply chain, we use Red Hat advanced cluster security for Kubernetes to monitor the platform. We have already seen it during the build process, where we used its scanning capabilities and policies to assess an image's overall security profile. Let's quickly take a look at these policies. Here, for example, we have a policy that explicitly checks for a specific CVE, in this case, the notorious struts vulnerability. The policy is defined to be active during the build and deploy life cycle phases, and the response is only informed in this case. When I edit this policy, I can change its behavior to also enforce the policy. If I choose this option, a build would fail, and clusters with admission controller enabled would not deploy it. To use it in a build pipeline as we did, I can download the CLI binaries here. If runtime was part of the enforcement life cycle, a port violating the policy would be deleted. But we want to avoid malicious or vulnerable code to reach the cluster in the first place. Red Hat Advanced Cluster Security for Kubernetes comes with a large number of policies, protecting against different life cycle threats, for example, cryptocurrency mining, should someone try to deploy a port that contains such code. Another possible attack vector are networking threats. Let's select our production application as an example. It's fairly simple, but we can see it has no network policies attached, so it's unprotected, from networking access by other pods in other namespaces. Now, let's assume for a moment that somehow one of our GitLab pods has been compromised, or think a WordPress pod in a WordPress namespace on the same cluster. This pod could then try to traverse the network and infiltrate unprotected namespaces and pods if there are no outgoing or incoming network policies defined, as in this case. Red Hat Advanced Cluster Security for Kubernetes allows us to create network policies via the UI, which could be made part of our templates, for example, so appropriate network policies would be available from the inception of an application. Red Hat Advanced Cluster Security also provides compliance checks for a number of industry controls but also allows to define specific individual controls. One example is the CRS Kubernetes. We can drill down and check which controls are not compliant. Opening a control allows me to drill down to the node level should that be required and check for control compliance on that level. Last but not least, a comprehensive list of all policy violations, from security best practices to detected vulnerabilities or abnormal runtime behavior allows to assess the overall risk status of a cluster and search for specific violations. As an example, here we have the violation of a security best practice where a container image contains a package manager. This should be avoided because a package manager could be exploited to load malicious code at runtime. Another very important aspect of the trusted software supply chain is the ability to manage S-bombs, software builds of material, and consume security advisories by trusted vendors that provide me with software and services. Given the rising demand for salsa compliance, more and more vendors will provide me with S-bombs of their products. If I sell a software product, customers will ask me for S-bombs and salsa provenance of the artifacts generated. Red Hat Trusted Profile Analyzer provides me with the capabilities to store S-bombs, security advisories, and CVE publications and easily cross reference them. If a vulnerability is disclosed, which of my products are affected, internal products, or vendor provided? What is the blast radius in my risk profile? Maybe it affects a product, but a component that I'm not using. Red Hat Trusted Profile Analyzer can answer all these questions. So, a new CVE has been disclosed. Let's check how it affects us. I found the CVE in the search. Opening it provides me with a list of products affected. In this case, just one. Opening the dependencies shows the actual component that is affected, as products are being built from many components and packages. Opening the component details shows all the vulnerabilities that this component is affected by. I can also go back from here to check which of my products are using this affected package. From the specific vulnerability, I can access the advisories that have been published, either for a specific product or a number of a vendor's products. Checking the vulnerabilities tab from this security advisory, I can see available remediations in Red Hat Trusted Profile Analyzer. I can also manually check an S-bomb that has been provided to me against the vulnerabilities in advisory's database without permanently storing it. From the search menu, I can also access all products stored in the database. Download their S-bombs or assess an overall product security status. As all product S-bombs are continuously checked against vulnerabilities and advisories as they are ingested by Trusted Profile Analyzer. Uploading and storing S-bombs, for example from a pipeline as shown earlier, can be done via the Trusted Profile Analyzer REST API. In this video, we have seen what a secure software supply chain is and how Red Hat Trusted software supply chain implements it. For ease of consumption, Red Hat Developer Hub, Red Hat Trusted Artifact Siner and Red Hat Trusted Profile Analyzer can be subscribed and installed as a single product named Red Hat Trusted Application Pipeline containing these. However, these products can also be subscribed and installed individually. As we have seen, a Trusted Application Pipeline also benefits from platform security and compliance monitoring, as well as a container registry that also scans container images for vulnerabilities. Red Hat Quay and Red Hat Advanced Cluster Security for Kubernetes are, among other products, part of the Red Hat OpenGIF platform plus offering, but can also be subscribed and installed individually. Thank you very much for watching the Red Hat Trusted Software Supply Chain Workthrough video.


Seethu a nice win against Nino today. She seemed to go wrong pretty early on in the opening Yeah, it was a scotch defense and she probably mixed up the Mu orders by playing g5 immediately without d6 And because of that I got this extra muh4 which started to create some problems for her And then her king just got stuck in the middle Yeah, and I mean after bishop g4 I was clearly better because she couldn't go along castle because of my knight d5 Right, so probably an opening mess up on black side Now Nino is obviously known to have really good results against some of the top men player You saw her game were you expecting the opening to go this way? No, I didn't expect really to go this way because okay, she's a strong player like especially she is doing well in this Gibraltar's So yesterday also she played well, so okay, I was not hoping to go in this way Right well, she's doing she does well in Gibraltar, but you also had a really good Gibraltar Tournament last year you finished fourth. Yeah, so you like it here. Yeah, obviously last year was I had a great run in the Gibraltar So yeah, obviously I want to come back again Right, and this is your first tournament of the year so important to have a good start to the year as well Yeah, okay, I played in Hastings. Okay. This is second tournament. So yeah looking forward For the remaining rounds. All right, and we wish you all the best. Thank you so much


The next item of business is an urgent question. If a member wishes to seek a supplementary question, they should please press the request-to-speak button during the question or by entering the letters RTS in the chat function, I call Liam Kerr. To ask the Scottish Government what its response is to the climate change committee's reports on progress in reducing emissions in Scotland's 2022 report to Parliament and Scottish Emissions Targets' first five-yearly review. The report from the climate change committee published earlier today was produced under the provisions of the Climate Change Scotland Act 2009, and both reports were laid in the Scottish Parliament today. I am grateful to the CCC's latest advice, which makes clear the scale of the challenge in meeting the emissions reductions targets set by this Parliament, as recognised by the committee these targets are among the most stretching in the world, but it is right that we continually act as being ambitious in looking to make sure that we take effect in reducing our emissions targets overall. The provisions of the Act requires Scottish ministers to respond to the climate change committee as soon as reasonably practicable. Once we have considered the advice fully, I will be a copy of the response before the Parliament as soon as possible. Since the climate change act referred to became law in 2009, the Scottish Government has failed to achieve seven out of 11 interim targets. In 2018, the Government put over 200 policies and proposals into a climate change plan, which it then updated in 2020. When I asked whether it had costed achieving its net zero ambitions by 2045, the cabinet secretary told me that it hadn't and wouldn't until a new plan was published at an undisclosed point in the future. I and many colleagues around the chamber have been warning this Government for years about the lack of evidence, data and financial planning. What has the cabinet secretary done prior to this devastating report, and now going forward to ensure that its targets are realistic, backed by clear delivery plans and fully costed prior to launch? I am grateful to the member for his question. Let me just set out in terms of the process that is already in place. The member made reference to an unspecified timeline. The member may be aware that legally we are bound to publish an updated climate change plan by the end of next year, and that work has already started. It will set out in detail the policies that will be taken forward and take into account the advice that we have now received from the CCC on this occasion. It will demonstrate clearly the link between the policy and the outcome that it will achieve in helping to reduce overall emission levels. The member will also be aware that the Committee on Climate Change has also been challenging Governments across the whole of the UK. It is similar to the report that was issued in relation to the UK Government's climate change plans. It is asking for much more detail on delivery. Let me give you a practical example of looking to make sure that we put those delivery mechanisms in place. For example, we published back in October last year our building strategy for decarbonisation of domestic heating. In the last few months, we have also published a delivery plan directly associated with that. We can demonstrate the measures that we are going to take forward. The member asked about the overall cost of that. For example, decarbonising domestic heating is potentially in the region of more than £30 billion, some of which will come from the public purse and some of which will also come from the private sector, all of which are areas that are being developed at the present moment and actions are being taken forward to deliver that. I can assure the member that the work that we will take forward in delivering the new updated climate plan that we are required to do will take into account that advice and make sure that we provide a level of detail that they are looking for. I thank the cabinet secretary for his answer. I noted the inevitable and rather predictable pivot within that answer to blaming the UK Government. The climate change committee was very clear that it is this Government that has the powers to take action on decarbonising buildings, transport and farming, but they have not used them. Responsibility for those failures lies squarely at their door, no matter how much the cabinet secretary tries to suggest otherwise. Since the cabinet secretary brought it up, let's examine decarbonising heat in buildings. In the context of a £2 billion underspent and the biggest financial settlement in the history of devolution, can the cabinet secretary tell us how cutting £37 million from the energy efficiency capital grants budget and £45 million from the heat in buildings capital grants budget will help to achieve the targets that are so catastrophically missed? The member might want to reflect on the comments that I made. The comments that I made about the UK Government assessment by the CCCC was not that I was blaming the UK Government. I was pointing out the issue of a very similarly critical report of the UK Government strategy because of the lack of detail, which is a reflection of the approach that has been taken by the Climate Change Committee in pushing Governments to be much clearer on the delivery work that they are taking forward to meet their statutory targets. That is exactly what I have given a commitment to do. That work has already started and has been taken forward at the present moment. The member made reference specifically to the issue of decarbonisation of domestic premises. There are a number of factors that are important in relation to that. One is the decarbonisation of our natural gas system. As yet, it is unclear, because the UK Government controls that exactly when that is going to happen. It is an important issue that we are keen to resolve with them, so we have clarity. That informs the investments that we make in helping to support the decarbonisation of people's domestic heating systems. We need to have that alignment. As the member will recognise, one of the key recommendations that we came from that report is the need for greater co-operation between the UK Government and the Scottish Government. That is why we have been asking for clarity on that, so we can ensure that the £1.8 billion that we are investing in this parliamentary term alone, which is record investment in decarbonising domestic premises, is used in the most efficient effective way, which is why we need clarity on when we are going to switch our natural gas energy system. That type of approach allows us to make the right informed decisions and to ensure that we are making the progress that I am sure the member wants to make and that we want to make in reducing our overall greenhouse gas emissions. Before I call any supplementary speaker, can I just say that we have now spent six minutes and 53 seconds on three questions and answers? I have received a number of requests for supplementaries. I managed to take many of them as entirely dependent on there being brief one questions and brief answers to match. Colin Smyth, supplementary, please. This report is utterly damning. Progress is stalled. 7-11 legal targets missed. A plea made a year ago for clarity and transparency has gone completely unanswered by the Government. Let us take one of many examples of failure transport. The Climate Change Committee says that we will need 24,000 public charging points by 2030 for electric vehicles. Cabinet Secretary has chosen just over 4,000 in total in the next few years. Does the Cabinet Secretary and the Government even have a target for 2030, the day it says that it will transition to 100 per cent electric car and van sales? When will it set out a clear plan to meet that target for public EV charging points? I am sure that the member will also recognise that the Committee on Climate Change has acknowledged that Scotland has got one of the most extensive public EV charging infrastructures in the whole of the UK, with the exception of central lending. As we have set out, we are investing over £60 million, £30 million from the Scottish Government, £30 million of private sector investment to extend the EV charging network even further in Scotland to make sure that we build on the good progress that we have been making in recent years. Fiona Hyslop is a hard critical report on assessing performance against hard targets set under pressure from and supported by all political parties in this Parliament. Can the Scottish Government also set out which key priority decisions in reserved areas by the UK Government to reduce emissions in Scotland, together with its own required improvements in delivery, are needed to address the climate change committee's concerns? I can think of three immediate areas that we need urgent clarity on. One is in relation to carbon capture utilisation storage, the ACORN project, which needs to progress urgently. Not only is a significant investment getting into that now, it is mission critical to mean our climate change targets here by 2030 and also for the UK, so no more dithering from the UK government on this matter is acceptable. We also need to see further investment into areas that are helping to support to make sure that we have in place systems that can help to roll out a renewable energy programme much more effectively, which is why we need to see reform of the consenting regime, a key part of which is reserved to the UK government, and why we also need to make sure that we see changes being made to the way in which there are regulatory costs being applied to aspects of our renewables, which are acting as an inhibitor to further development. We are leading the report, exposing glaring gaps in plans and progress being jeopardised by ministers failure to co-operate at UK level or to give local councils a fair deal. In light of the CCC stating, aviation policy runs counter to targets, whether the SNP green government will now revisit its support for Heathrow expansion. We are developing an aviation strategy, which will look at both domestic and international aviation, which will be published next year and will set out our approach to aviation policy. In the last session of Parliament, four parliamentary committees raised serious concerns that the climate change plan was not fit for purpose, so it was good to hear the UK CCC finally reflect many of those concerns in their report today. Undoubtedly, the new climate change plan must do better, so will the cabinet secretary accept that we urgently need to drive down the growth in aviation mileage and that no options should be off the table to do that. We will be covered in the aviation strategy, which I just made reference to. I can give the member an assurance that the climate change update plan, which we have already started work on, which will be published next year in draft form, will make a much clearer link between policy and delivery outcomes and how that will impact on our climate change policy overall. That concludes the urgent question. I apologise to those members who I was not able to call for the reasons that I made quite clear a wee bit earlier. There will be a short pause before we move on to the next item of business, to allow front-bench teams to change positions should they wish.


I'm Sudhamsh Vachu. I'm from Arcos Labs. I'll give you a brief intro about Arcos Labs, as most of you might not have heard about it. Hi, I'm Remington Breeze, and I'm a software engineer at Acuity. Oh. You might be curious what is don't-let-a-bot-in. I want to get creative so that I could get picked for the lightning talk, so that's the whole reason. Cool. So about Arcos Labs, it's a cybersecurity company. Why I'm sharing about Arcos Labs is, like, why releases are more important to us, what would happen if releases don't work as expected, or if there is downtime.  It has multiple use cases. It deters bots from creating accounts or hijacking accounts, protects payment fraud on the financial space. Account take-overs pretty much every site that has a login could use our application. New account fraud, like, for example, if PayPal has a promotion for $10, somebody could create used bots and then create accounts and then exploit that marketing. So that's where our product stops users with capture challenges and deters bots. If a manual user is creating multiple accounts, we have different rules and strategies to block those users with complex puzzles and at a particular point, we deny them. So as you see, we have, like, very large customers like Microsoft, PayPal, Adobe, and others. They have very strong observability platforms in their environment. So if our service goes down, they'll detect in no time. So whenever we do a release, we need to be confident that the release will go smoothly and it will not have any regression. So that's where... So we have multiple challenges. I'll share in next slides and why we chose Argo CD for our continuous delivery. With all the amazing talks we had today, if you're not sold on Argo CD, so let me nudge you a bit more. So some of the challenges what we had, multi-day releases, I'm not making it up, as being a SaaS company, we had to make sure release to a region, test it thoroughly, then go to next region, then test it thoroughly. That took multiple days because for a couple of reasons, because we were in ECR and something like Blue Green was not supported out of box. So the end result was, like, 50 different manual steps to be done to make sure that the release goes smoothly and customers are not impacted. Obviously, if you have a multi-day release with, like, six or seven people, you can imagine the toil on the developers, like, dude, release is kind of a dreaded day for everyone who ever was involved in that. So when you have a long release, it has an other side effect. The release velocity would be low because nobody wants to spend multi-day release and then you release once a month or once in three weeks. What would that result to? You will have more rollbacks because a lot of changes are going at once. There is a high probability that something would break. So you spend time in rollback. Then again, you have to do a multi-day release. So that's kind of a snowball and just a downward spiral. And other problem what we had was building always irrespective whether it's a conflict change or whether it is a code change. Kind of goes to, like, different folders and don't build if your code hasn't changed. It's a conflict change you can release without building your image as the code hasn't really changed for you to deploy a new image into your environment. So when we evaluated multiple products that are in the space, what we liked was Argo CD along with the rollouts. So one of the reasons, so multiple reasons as we have heard throughout the day, very fast releases as soon as we make a change in GitHub, then the event is triggered and then you can deploy to all your environments. You increase the velocity. As things are faster, it has a positive effect on the developer's experience. Hey, I made the feature change, so let me release it. And the sooner we release, we are getting a better return on the investment. The time we spend, it's already, it's released to our customers and they are delighted. That makes everybody happy. Products is happy, engineering is happy and developers are happy. And also GitHub's principles. In some of the companies that have worked before, there's a separate change ticket process. You have one level approval, two level approvals based on the complexity of the release. We don't have to do that. GitHub already has protected branches. We already have things for code changes. So if you are doing a code release, why not use the existing process that's already there? And also increasing the release confidence. We can do blue green deployment, test on the inactive stack which is not like taking live traffic and then promote your next version N plus one to take live traffic. This increases release confidence and reduces rollbacks. And with blue green, we don't send any live traffic to it. So we are not affecting any customers. And the north star we want to get to is mirror the traffic from live to the inactive stack so that we get all the application metrics and then our confidence level increases in releases. One other aspect that we looked at Argo CD before choosing that was can it scale as our microservices scale and as the company grows? So that kind of checkbox on the Argo CD it can scale horizontally just as long as the infrastructure in which it's running scales. So it can scale. And also the observability. Yes, I think some of the talks we had like from the Prometheus metrics that are exposed out of box with Argo CD like how do I monitor my, I mean the Argo CD service itself is it deploying or are there any bottlenecks? How do I get visibility if something is not, something is not working as expected? So being part of the release team if something goes wrong, I have to work throughout the night until that gets fixed. But I need a starting point to where the problem is so that's where Argo CD helps by exposing its internal metrics and that you can look at. So before even looking at Argo CD we went through the requirements argument hey, these are the things that we want. You want scalable observability and then blue-green deployment, cannery, notifications, etc. out of the box. So that's the value proposition that's what I saw with Argo CD as Pratik said in the keynote today and yesterday. Argo CD was looked at as a product. It's not somebody put it together hey, this feature looks good, this feature looks good. Okay, let's make it an application out of it. It was thought like a product. There's a single sign-on integration to it. It integrates with Microsoft Active Directory. That's what we use. I was surprised. Really, we use that and then you already have an integration for it so it can't get better than that. Drift management. So GitOps as things change. That's our source of truth. Then our environment would be in sync when we do an auto sync enabled for applications. Metric analysis as part of rollout it integrates with Datadog where we can do the metric analysis and release it. Two more minutes. Okay. So Blue Green, Canada, Out of Box, Slack notifications. So as I said, we had a checklist where a developer would say hey, I'm starting on US Region 1. Do the deployment and then one more Slack message saying hey, we finished on US System 1. That's not good use of time and that would not be accurate because the deployment could happen anytime. So when that is integrated with as part of the Argo CD deployment, then you know that the action happened pretty close to the message that was sent out. Multi-cluster support. One Argo CD can deploy to any number of clusters so you don't have to log into multiple UIs. Command and control for SREs. If a pod is misbehaving, SREs can just restart or delete the pod in production. That's a lot better than getting the credentials from AWS console, updating your credentials file and then connecting to cluster, connecting to the namespace and deleting and somebody could delete it from the wrong namespace. And it's open source. So it's an easy sell to finance team. All right, thank you. So I'm going to speak a little bit about Acuity's partnership with Argos Labs. So as Sudamche mentioned, they have very high requirements for uptime with their product and Argo CD helps provide that but in addition to that comes a higher standard and Acuity helps them achieve that standard. So Argo is a pretty complex product and with that comes a lot of configuration and at Acuity we like to think that we help our customers squeeze all of the value out of Argo. So yeah, some of what we've provided when Argos was having difficulty configuring the Roles extension for example for the Argo CD UI, we helped them to do that. And then on top of that we just have a lot of knowledge here at Acuity about Argo because we are a company of maintainers and experts. So we bring all of that knowledge and help our friends at Argos. And then we also launched last week a platform that makes it easy to configure Argo CD without the box benefits such as security and cost reduction on top of all of the OSS features that you guys know and love. So yeah, thank you guys. Cool, thank you.


Welcome back to Behind the Glass. This week, we hit the road and made our way down to the JL Audio Manufacturing Facility in Maramar, Florida. JL Audio has been in business for over 40 years and during the course of that time, they have earned the spot as the best-selling Marine Audio Equipment Manufacturer. JL Audio's product offering encompasses not just Marine, but also home, car, recreational vehicles, and power sports. Come along as we take a tour of their 160,000 square foot manufacturing facility, divided into several production areas. These include a highly automated wood shop, fiberglass fabrication shop, machine shop, paint shop, loudspeaker assembly lines, and enclosed subwoofer assembly work sails. Today, we will focus on the M6 Marine Speaker Manufacturing Line and give you an inside look at how they are built and tested. The process begins with the motor. The motor is a ferromagnetic alloy that interacts with the voice coil and creates movement using a magnetic field. This is what drives the speaker's movement, which is translated to the pressure waves that we perceive as sound. The uncharged motor is placed inside the basket of the speaker. The basket is the structure of the speaker and houses all of the components inside, hence the name. The basket and motor are placed inside a machine to magnetize the motor. This process only takes a few seconds, but the magnetization lasts for the lifetime of the speaker. The basket is now ready to receive a mounting gasket before being flipped over to receive all of the remaining components that make up the speaker. One thing we noticed during the tour is above every station, there is a screen showing the instructions for each process on the line, ensuring each team member follows precise build guidelines set by JL Audio's in-house engineering team. After a quick QC check, the first of many along the line, a special bonding glue is added and the gasket is properly aligned and permanently bonded. From here on out, the speaker is placed onto a jig on a conveyor belt, where it will stay until it's removed for packaging. This will help with proper fitment of all components and easy transportation from station to station. Adjacent to the previously assembled basket, work begins on the cone of the speaker. The cone is the visible part of the speaker where movement is translated into waves that produce sound. Prior to this production line, the cone has a sub-assembly where a rubber ring called the surround is bonded. This allows the cone to be attached to the basket later in the process. The cone is now placed on a fixture followed by a voice coil. The voice coil is comprised of a copper wire wound up around a cylinder called the former. The coil is then glued to the cone and two flexible wires called lead wires are soldered to the coil. The flexible wires will later allow for movement while the speaker is playing without breaking. A flexible adhesive fills and encapsulates the soldered connections of the lead wires from the elements. Another observation we had was each station is equipped with a vent in the back that removes any fumes ensuring good air quality for the safety and comfort of the team members. The two assemblies travel down the line and into a chamber where a computer programmed automation occurs. During this phase, an applicator is programmed to apply a specific amount of primer to the cone while at the same time a robotic arm or the syringe applies a precise amount of glue to the basket. At the next station, the pre-assembled crossover ring is placed into the basket where the glue was previously applied. The components of the crossover is what supplies the tweeter and mid-range the signal range it was designed to best reproduce. Even though the crossover ring will eventually be hidden within the speaker, the components and connections are sealed to protect them from the elements as well as keep them stabilized even in the roughest conditions. Once in place, a weight is added on top to align and hold while the glue sets. Next, a team member will install the spider on the cone assembly. The spider acts as the suspension for the speaker. It allows for free movement of the voice coil but only in the vertical direction while centering the entire assembly on the horizontal direction. Using an alignment jig, the spider will be placed around the voice coil. Once in place, a layer of glue goes around the edge to ensure it's adhered to the voice coil. Our speaker assembly is almost complete but we want to take a moment to take a look at the process of tuning our JL Audio Ultra Premium Upgrade. With us today is Mr. Adam Iskid and he is our account manager as well as an audio systems designer. The tuning process consists of strategically placing multiple microphones in the zone being tuned. A test signal is sent to those speakers and fed into JL Audio's preparatory software. Adam will analyze and make adjustments to multiple parameters according to the geometry of that zone. The process is repeated in each zone of the boat, typically three zones, bow, helm and cockpit. This gives you the absolute best sounding system on the water. Once Adam feels like the boat's sound system meets expectation, he will save a master settings file for this boat. We'll use that file to flash every single similar model that comes down the line with the JL Audio Ultra Premium Upgrade. Let's go ahead and jump back into the action as we see the rest of the assembly process of a speaker. The assemblies now move on to another chamber area where an accelerant is applied to quickly cure the glue. This ensures that everything is bonded and ready for the next step. When the parts exit the chamber, they are met by another team member who will remove the weight added to the crossover ring and apply a flexible sealant. The assembly is progressing to the chamber where another automated application of glue is applied around the perimeter of the crossover ring where the spider will connect. It will also apply glue around the top rim of the basket where the surround will sit joining the two parts into one. Once the assemblies come out of the chamber, the team member will join the two parts. The cone assembly now dressed with the voice coil, spider and lead wires is placed down into the basket for final adhesion. Once fitted inside, a weight is placed on top to secure the two parts and it's sent into another chamber for another application of accelerator. The accelerator makes sure that everything is firmly adhered before the lead wires are routed and final connections are made. Next, the speaker is removed from the jig where it has been moving along and placed onto a fixture where the lead wires will be soldered to the terminals and sealed with a flexible adhesive. Next, the assembly speaker is placed back onto the jig on the conveyor and makes its way into a final chamber where an adhesive is applied for the installation of the dust cap. As the assembly exits the booth, the dust cap is placed at the center of the cone. The dust cap plays an essential role in doing exactly as it sounds. It keeps dust, water and debris out of the internal areas of the speaker. Next, labels are placed over the terminals, the serial number is placed inside of the speaker and a motor cover is installed on the bottom sealing the motor assembly. An additional sticker is applied to the back of the basket with the speaker's model information. Next, the speaker receives the iconic JL Audio Speaker grill cover. Once complete, it makes its way for final QC and testing. Prior to heading to packaging, each speaker undergoes a battery of inspections and tests. This ensures the absolute highest quality product that JL Audio is known for. It all begins with logging the serial number into the system, capturing all the manufacturing data and assigning the test results for each speaker. The first step is the same as the last, a visual inspection of the speaker for cosmetic flaws and validation of proper assembly techniques. The speaker is then hooked up to a test fixture where an array of functional tests are performed, a proper polarity and a sweep of audible tones is played where the response is charted and compared to the target, resulting in a pass or fail to proceed. It's incredible to see the combination of computer control machines with the human touch working side by side to deliver an extremely high quality product. As you are walking through the endless rows of this impressive manufacturing facility, you can't help but notice the internal culture JL Audio has built as a team. A huge thank you to the entire JL Audio team for their help on this episode. Join us in our next installment of Behind the Glass where we take a look at what it takes to manufacture fiberglass parts using two bolts, a process called LightRTM. Don't forget to subscribe for the latest content from Sportsman Boats. From Somerville, South Carolina, my name is Victor and thank you for watching.


Stuck at home all weekend with nothing to do I decided to make homemade peanut butter cups the recipe is pretty simple peanut butter Chocolate butter some sugar that wasn't in that shot put the chocolate into that thing put it in the microwave Hope that it's microwave friendly don't think it was melt the chocolate into delicious chocolate As I think I use semi sweet chocolate put the little things into the little thing put the chocolate into the little thing Just a little little spoonful put them in there you banging on the counter a little bit that flattens it out Didn't really work kind of worked some I wanted to paint the sides So it actually cups the peanut butter others I didn't because I didn't know the difference take the peanut butter super chunky Because I'm not a child put it into the ball scoop it again slam it off the spoon put the spoon in there give up Butter put a little butter in there put a little sugar in there you got to make it a little sweet You got to make it a little smooth a little creamy so you do that okay There you go That's just a regular old bottom one and that one's got it up on the sides I froze it for 15 minutes at a time. I put the peanut butter concoction into the cups Everything's going great. Everything's going smooth. Look at the delicious peanut butter I'm a peanut butter holocake like a spoonful a night minimum slam that down in the counter see if it flattens it out Oh, it kind of worked. Oh, it kind of didn't work. All right. It works look really good, right?  It looks sloppy as hell doesn't look good Put it back in the freezer for another 15 minutes nice camera work.  Oh, we're back. Okay 15 minutes later. We're back now They just should be done and ready to eat. Let's see how it looks take this one out. Yeah, kind of cool Kind of beautiful and this is the one that had it all encased My thinking was when you bite into it if it doesn't have the chocolate on the outside it might just explode No, it worked fine. It tastes good. They were delicious. I have some in the freezer I'm gonna go eat some tonight great job by me. I'm the best