 Going, going. Well, hello and welcome to our workshop today. Hopefully you guys got a chance to see our fun live demonstration we did yesterday, where we actually had a data scientist and engineer come on and show us how to do some really cool things with the OpenShift data science platform. Well, today you're gonna get a chance to get hands on with that. But two of our lead experts here at Red Hat who have been working on this product for quite some time. And more importantly, Giam in particular helped craft this workshop. So I think that is super exciting. And already we can see it in Alpaca. We love the Alpaca component, right from Sophie there. So I want to welcome everyone here. Make sure you use the Q&A and the chat. Go to that stage section where it says stage and go to chat. You'll see the chat Q&A. See us there. I already have a hello and welcome message there. I'll add one more. And all tell us where you're at. Tell us where you're from. Tell us what you're thinking, what your experiences in the AI data science world, AIML and data science world, because we want to hear from you. And we want your feedback. If you love the technology, if you hate the technology, if you love the presentation, hate the presentation, give us your feedback that helps us make a better technology, a better product, a better user experience for you going forward. Okay, so we love to hear more from you. At this point, I am just here for color commentary and to be fun. Otherwise, the experts are showing up now. So I want to turn this over to Sophie Watson. I believe she's up next. Thanks so much, Bear. Hi, everyone. Thank you for joining us today. We're really excited to have you here. You are the first non-Red Hatters to get hands on with this platform. So that's pretty exciting. I'm Sophie. I'm a data scientist here at Red Hat. And today I'm here giving this workshop with Guillaume. You want to introduce yourself, Guillaume? Yeah, sure. Thank you, Sophie. I'm Guillaume. Guillaume is a data engineering architect. Advocate, whatever you want to call me. But I'm here to help you figure out how to set up those data engineering thing or data science platforms and anything. So I've prepared this workshop for you so that you'll have a feel on what you can do with Red Hat OpenShift Data Science. Awesome. And we also have some fantastic helpers behind the scenes as well. So shout out to Audrey who's going to be monitoring the chat for us. Audrey spent a lot of time on the internal pilot program for the Red Hat OpenShift Data Science platform. So she's got more experience with this than the rest of us, I think, combined. So please, if you are stuck, if you have any questions, just ask in chat. We've got a few different ways set up that we can help you and we can even set up a little breakout room with screen share if we need to. Also shout out to Chris and Alex who are helping us with setting up the cluster and monitoring that for us. So everything runs smoothly today. And Edson, Kristin and Savannah who helped us set this up. Thanks, squad. Okay. So what are we going to do today? Well, first and foremost, we're going to give you an overview of Red Hat OpenShift Data Science. So yesterday in the keynote, you got a brief snipper of it. Today we'll talk about what it does, how it does it, and how it really supports data scientists and the machine learning workflow. From there, Guillaume is going to talk to us about the use case that we'll be dealing with today in the hands-on session of the workshop. And then we'll dive into that. Now, I understand that we might have a mixed audience today. Perhaps we don't have many data scientists or any data scientists at all, in fact. Let us know in chat what your role is, please. That's completely cool. So what we want to do today is show you how easy Red Hat OpenShift Data Science makes it to get started and get going, how it supports your data science teams. And provide some of the tools and technologies that they need to get their jobs done. And you might just learn some data science techniques along the way, but it's okay if you're not a data scientist. There's not going to be a quiz at the end. So I'm just going to whiz through a few slides to talk about what Rhodes is. And we'll start by thinking about what data scientists actually do. So the way that we see this workflow here at Red Hat, data scientists need to start by gathering and preparing that data. If you don't have access to data, then you can't train a machine learning model. Once you've got that data, it's on to training the model. So this really encompasses everything from exploratory data analysis, feature engineering, on to training that function, which is able to answer a question that you want asked. So we can just think of our machine learning model as a function. It takes in data and it spits out a prediction. And we'll see one of those in action in a moment. In order to get business value from machine learning, these models need to be put into production as part of a larger application. And deploying machine learning models into an application is, for me as a data scientist, one of the trickiest points of this workflow. I'm not a release engineer. I don't know how to package software. So this is kind of a pain point for me and we'll come back to that in the workshop. And then finally, once that model is in production, it's important to be able to monitor and manage it over time. There are so many ways that a machine learning model can break. But the question really is, if it does break, will you notice machine learning models don't break in quite the same way as standard software, which might just not compile or spin an error code? So Red Hat platforms already support this, these workloads, OpenShift and all of our middleware portfolio and other applications really provide that hybrid cloud service with self-service capabilities. So data scientists can go ahead and deploy these models without having to file a ticket with IT. As a data scientist, I can access GPUs to scale out my application. And I get the same experience whether I'm running on my local machine or in the public cloud when I'm using OpenShift. So what's the problem? Well, as a data scientist, I'm not an OpenShift expert. I'm not a Kubernetes expert, and I shouldn't have to be in order to get my work done. OpenShift supports those workloads, but what we really want to focus on now is the data scientists and their workflows, which happen on top of this platform. And we want to enable data scientists to do that without having to become the OpenShift experts. So that's where Red Hat OpenShift data science comes in. Red Hat OpenShift data science is delivering a common set of data science tools as a foundation, as the foundation of an AI as a service platform, and it's integrated with partner cloud services. So the service, as we'll see, is built around Jupyter notebooks and extended further by adding open source and partner tools through a shared UI. We'll see how SOS2imaged helps to take those models and put them into production once you've created them. We'll all be able to deploy a model, hopefully, in our session today. And you can gain the benefits that you get from the OpenShift platform without having to become an OpenShift expert. So it's a managed cloud service at the moment running on OpenShift dedicated on AWS, and this means that there's no need for IT to manage infrastructure. It provides data scientists with access to a whole ecosystem of ISV certified software that's available on the Red Hat marketplace already, and it really supports these core components of the data science workflow, from exploring data, developing a model, and integrating it as part of a larger application. So we see Red Hat OpenShift data science as being ideal for rapid experimentation, and actually you can take the models that you've created and developed on the platform and export them and run them elsewhere, as perhaps you want to take them away from their managed service and run them on-prem. There's nothing stopping you from doing that. So in terms of initial release components, this is what our stack looks like at the moment. So we've got a few partners and ISVs as a service in there, Starbust, Anaconda, IBM Watson Studio, and Selden for model serving, and that's all working on top of Red Hat OpenShift data science. The service also works with the newly announced Red Hat OpenShift Streams for Apache Kafka service, which is excellent for dealing with your streaming data as it flows into your machine learning system. Whoops, sorry, my mouse is... I'm stuck. Okay, I figured it out. Computers. And in addition to the managed service, we've got our partner ecosystem that can be combined with the service to provide these custom-managed applications. So really, ROADS isn't a one-size-fits-all. It's a... You're not getting something just straight out of the box and that's what you've got to stick with. It provides the flexibility to integrate with a range of our managed ISV software partners to create an experience that your data scientists like. When we talk to data scientists, they work in so many different ways and are used to using a range of different tools and this really supports that ecosystem. So that's Red Hat OpenShift data science. We'll get hands on with it in a moment, but before we do, I'm going to pass over to Guillaume who is going to tell us about our use case for today. Yes, because whatever you're doing in data science, it's always better to understand what it's about because at the end of the day, it has a business goal. There's something we are trying to achieve with what we are doing in data science. So here, the scenario is part of a broader workshop that I'm preparing with my team that will be available later this year. But the story is that I don't know if you're aware, but in London, there is a special low-carbon emission zone where there is a toll that you have to pay whenever you are entering this area of London with your car. So what we are trying to implement in this scenario is that we have many different stations around this area. That's the black boxes that you can see all around where we have cameras that will monitor the traffic and take pictures of the car passing by. Then from this picture, we want to extract the license plate from the full image. We want to be able to extract only the area where the license plate is, then recognize the license plate number itself. In the full scenario, what we will do is that we will send this information using Kafka and a Kafka mirror to some central location where we will have some kind of mechanism listening to the Kafka stream, being able to deploy Amber alerts. You know, those alerts whenever the police, for example, is looking for a specific car for child abductions and this kind of stuff. We'll also have a data enrichment process that will be fed from the Kafka stream, that will enrich the data with the license registration database so that from the license plate we gather more data like the car model, the owner, and so all the other information that we will store into an object storage data lake so that we are able later on to do statistical analysis or to train models to be able to recognize certain patterns in the traffic and things like that. So that's the overall scenario. That's a smart city scenario. We are trying to gather data about what's going on. In this workshop, we'll tackle the first problem, which is how can we, from a picture of a car, extract the license plate and extract the license plate number itself. That's exactly what we'll do during the workshop. Back to you, Sophie. Thank you. So I think with that, we are ready to get into the hands-on section of the workshop and get you kicked off. Audrey, do we have any questions hanging about that need answering before we get going? I see a no in chat, so I'm going to take that as a no. Thanks, Audrey. All right, so in order to get signed up today and set off with our workshop, we're going to need you to go to this link here. I am just going to pull this up in a new window. I'll also drop that in the chat in case, oh, thanks, Guillaume. Just leave me to it. Okay, so Guillaume's dropped that URL in chat, so I am going to stop sharing our slide deck and head over to that. So hopefully that should take you to a spreadsheet that looks like this. If people do not have access, please let me know. And all you need to do today is pick a username and that will give you also a very secret password. So I'm going to come down here and take user 27. So my username is user 27, and my password will be the same as your password, which is RHODS, but how OpenShift Data Science demo. So there's three columns here. We've got workshop instructions. You can get these loaded up, and you should be on a page that looks something like this. Again, any problems, please let us know. And we're going to start for now using the OpenShift Data Science URL. So I'm just going to step you through getting going and logged in to OpenShift Data Science. And then from there, we will leave you in peace for 20 minutes or so to get on with the workshop. We are around for any questions. If you run into any bugs, anything that isn't working as you'd quite like it to, then please just let us know. Okay, so when I click on my OpenShift Data Science URL, I get taken to this page here, and it's asking me to log in with OpenShift. So I'm going to make this page bigger and log in with OpenShift. And what you want to do is you want to click workshop, since we are in a workshop. My username is user 27. Yours will not be user 27. Please don't log in with me. That would be humorous, but also painful. And my super secret password, which is your super secret password, is R-H-O-D-S demo. All lowercase. So from there, you can log in. And what you're seeing now is Red Hat OpenShift Data Science. So this should look like what you saw yesterday in the keynote when Subin gave us his demo. And I just want to give you a quick tour of what we've got here. So as we can see under the applications section, we're currently in Enabled. So this is everything that we've put turned on in the service at the moment. And for us, that's just stupid to have. That's where we're going to be focused today for the exploratory portion of our workshop. If we head over to the explore menu under applications, you can see a range of the additional applications that are available to be added to your instance. So feel free to have a look at these. Explore and find out more. Now, we also wanted to make the Red Hat OpenShift Data Science experience as easy as possible to get started with. And we don't just want to target seasoned data scientists, but also those that are perhaps new to the field or new to some of these technologies. You don't have to have used Jupyter Hub before. You don't have to have used Kafka before. And so in order to aid that, we've put together a great set of resources here. So our resources are split into different types. We've got tutorials, which are kind of long form. And certainly the workshop you're doing today will soon appear as a tutorial in this platform. We've also got standard documentation. But the thing that I want to point out today is Quick Starts. So these guide you through getting going. So here we've got a nice Quick Start for creating your first Jupyter notebook. And we can click Start Tour. And it will step us through those sages. I'm going to close that for now. But yeah, have a look at the range of documentation in there. If you think anything's missing, let us know. Again, we want this to be as useful as possible. So if there's something not there, then please shout. So to get started with our workshop today, we're going to head back to that Enable tab and we're going to launch Jupyter Hub. Again, you're going to have to re-authenticate. So log in with workshop. Same username and password as before. And you'll be taken to a page that looks like this where you can launch your notebook server. So as a data scientist, a big pain point for me is getting a repeatable environment. I might traditionally work on my laptop, so I'll install some packages. And then suddenly I find I need to work with some secured data, so I log into my work system and my work machine. And I try to run the same code that I had on my computer on the work machine. And it doesn't run or it runs differently because there's different packages and different versions available. So with Red Hat OpenShift Data Science, we've given you a set of predefined notebook images that contain the libraries and packages that you might need. And today we're going to be using the TensorFlow library. So let's stick with our TensorFlow package as is. I often find that there isn't enough CPU on my laptop, so then I moved to the cloud to try and scale up and get access to more. With Red Hat OpenShift Data Science, you can select your container size based on the work that you think you're going to be doing. So I can access a range of sized environments without having to file a ticket with IT. Now for the purposes of this workshop, we've locked it down. So we have limited you to either a small or default container size just to make sure you're not mining bitcoin in the background. And we are going to stick today with defaults. If you click small, you might not have enough memory to get through the lab. And that would be really sad. So please don't do that. If we were connected to a cluster that had GPUs enabled, on this page, there would also be a GPU box. And as a data scientist, I can say, yes, I want a GPU. And that would also be added to my environment. So this is really a self-service environment for me, not filing a ticket with IT and a uniform experience for every data scientist on the team. You could also add more environment variables here into your Python environment. So suppose you were wanting to access data that's in an S3 bucket, you could put your S3 credentials in this page as environment variables and they'd be injected into your notebook environment. So we're sticking with TensorFlow and container size default. And with that, I'm going to go ahead and start my server. Okay, fantastic. We are in Jupyter Hub. So at this point, I'm going to stop talking to you. I'm going to mute my mic and probably turn off my camera for a bit. And I recommend you head over to the workshop instructions. Please take a read of the first couple of pages that tell you what we're going to be doing. Step one tells you how to get started with our Jupyter environment, which we just stepped through. So you can go ahead and start with step two. Now, I think we have about an equal number of Red Haters around to help today as we do people in attendance. So please do shout out if you hear any roadblocks. We'll be happy to help. I think we're going to hang around for about 20, 25 minutes and then Guillaume is going to come and give us a walkthrough of how we deploy a model as a service in OpenShift. So we'll come back and do that at about quarter past. How does that sound, Guillaume? Yeah, that's perfect. And again, if you are stuck at any step or you don't know exactly what to do or you just want to have some more information, just hail us in the chat. It would be a pleasure. You know, we'll show you directly what's going on on the screen. We are also able to manage, of course, what's going on underneath because for those who are beginning with this, what in fact was happening when Sophie launched her notebook is that a container was launched inside OpenShift. So that's a dedicated container for your environment, for your experiments or whatever, but we have the ability to monitor. So if anything goes wrong with that, we will be able to even maybe debug it live just to help you go with the workshop. So yes, for that part, normally for the first part, the first few notebooks, you should be able just following the instructions. You should be able to do it yourself. And once we get at the last step, I guess it's seven or something for the packaging and serving of the model, we will get back to you and we'll do it together. I will be sharing my screen to show you that. So if you don't agree with that, it's the time to put it in the chat. No, we don't want to press it like this. Just see it. I don't know, Sophie, but as it seems some people already have finished, maybe we could add some column spreadsheets so that when people are finished with this, they could add in the spreadsheets. Okay, so there so that we don't wait for nothing. Okay, for everyone, this is what I did. I just added a column right to the username so that you are able to enter whatever you want to tell that you're finished. Guillaume, can you go ahead and just do a screen share? Everyone is finished because you know, honestly, we didn't know how much time it would take, so it was 20 minutes, but we will see. Hey, Guillaume, welcome back. Yeah, I don't know what happened. As people are building and testing the model and things like that, maybe before jumping to the last part, I can put a few words here. As you have seen, it takes time to develop a model. And in fact, for this specific workshop, the problem was not in the model itself, but much more to find the dataset. We discovered while building this model that finding a curated dataset with pictures of cars and annotated pictures, where is the license plate and everything is really hard. There's no public dataset like this. And in fact, there are some datasets available for this specific use case, but it costs a lot of money because it takes time to prepare all these data and everything. So that's why it shows that you have to have this curated and reproducible platform to be able to develop your data science workloads. If you don't introduce this for pure disability, it becomes very difficult to juggle at the same time with all those parameters. Where do I find the data? Do I have access to my curated data and so on? So by setting up those kinds of data science platforms, you are able to provide your data scientist with some efficient way to do their work. So you can provide all the data as a feature set, directly in some data lake that you can set up as your source of information that can be shared by all the data scientists. And then you enable them with those capabilities of being able to do those jobs. So that said, I will check. Okay, lots of people are already at step five, step five, which was the model packaging. Okay, so here we have this part of the job that has to be done because data science is not only about training models. At some point, you have to use them. You have to actually put them in production. So we did this first stage of the job at step five, which is to prepare our code to be able to run in an application way, as an API way. Okay, so as you've seen, we have repackaged the code and you can directly open the Python file to see how it's done. But basically, it's all the same content that was in the notebooks, but prepared as a single file that we will be able to use to serve the model. That's one technique. Okay, there are many others. You can also use Selden that is available through OpenSheet Data Science as a partner offer. There are multiple ways. Here it's much more for this workshop, the manual way of doing things using Flask. You could also use, well, in production, I prefer to use a fast API, which is a little bit faster than Flask. You know, Flask is a general purpose web server, whereas fast API will be tailored much more for this kind of this kind of pure serving thing around APIs. Let me see where people are. Okay, well, some people are already testing and validating and already at step five. So I guess it will be okay, Sophie, if I go on with the rest. Absolutely, I think so. Take it away. So what I will do is share my screen. And here you can see I'm logged as user dirty. Okay, so we are in this situation where you have a data scientist who has trained a model. The model is ready to be used, but how can we put it easily into production? And that's what I put in those last steps. So with OpenShift and the S2I, the source to image capabilities, it's actually really easy to deploy a model like this. So what we do is from this developer view, I am in my project user dirty, and then I'm able to add something. And the something can come from a Git repo. Okay, so that's where we enter the ML apps part of the workshop. How do we operationalize the production delivery for this kind of models? And we can apply exactly the same patterns or solutions as we've been using for years and into standard application development. So it's about the same. So here we have a Git repo where our model is and the source is. So what I will do is just get and copy the address. So that's the Git repo we are using from the start. And I will just paste it here. Okay, I have to use here a special option because in fact, the Python file, the package Python file that we are using in this branch, in the app branch is a little bit different than the one you are actually seeing into your JupyterLab environment. Why? It's because in the workshop, in the JupyterLab environment, I wanted people to experiment with car pictures that were already in the repo, in the dataset folder. Here, I change only some part of the code to be able to directly upload images, to send images to an API. And it sits in an other branch of the same repo. So here, that's what we indicate here. We want to use this specific branch when we will pull out the code. We don't need anything else, you know, context tiers or secrets and everything. And you can see that the builder image has already detected that we have Python code inside our repo. That's fantastic. So it has pre-selected for us the right builder image. We can choose to have different versions, depending on the version of Python we want to use. Okay. And here, Python 3.8 is perfect. So it's in sync with the Red Hat OpenShift Data Science environment. And we can have, give a name to our application. Here we can leave the defaults. If we deploy it as a deployment or deployment config, but deployment is okay. And of course, we would want to create a route to our application so that we are able to access it. Okay. And this is what I will do here. I will create my environment. And here in the topology view, we can see that we have our application with its name, license plate, workshop, Git. That's the default name that we choose to have. And we can see that the build is running. So what's happening behind the scene is that OpenShift has fetched the content from the Git repo, has fetched the base image or Python 3.8 on UBI 7. It has fetched all those content. And it's building an image by injecting our code inside the base image. It's recreating a container image that it will, afterwards it will deploy automatically. So it will create the deployment that is needed into OpenShift just to tell the Kubernetes engine that you have to deploy this container with these specifications, configuration and so on. And at the end, it will also create a route to be able to access this service. So it will take some more time. So we'll leave it running. And while it's building, I may try to answer some questions in the chat. There is an internal server error. So, Guillaume, there is a question from Sonya. So we may want to go through it. Yeah, that's what I'm looking at right now. But okay, so what we can do while it's building, you know, we'll try to have a look live. So I will log in again at this time as an admin and we will have a look at what's going on. So it was on project. Oh, if you already have your error, that's perfect. Yeah, that's the kind of the tricky parts to be, you know, to be able to figure out if you need a backslash at the end and everything. In this case, we did not. So I hope it's working now. Perfect. So yeah, sorry about that. It's part of, you know, when you want to implement things, it's some kind of the standard development journey because you have to make sure that the configurations and everything will fit with whatever the API is waiting for. And so in our case, what I should have done, what I will do for next iteration is, you know, to curate whatever is entered to make sure that there is no double backslashes or things like that. So as this is solved, I will go back to my own environment. Okay, here we can see that the build is finished. Perfect. And if I click on the application itself, I have some more information like the routes, as you have seen for those who have already been there. Now I have a route that sees accessible and I am able to query directly the API. Okay. So normally, and I see that people seem to already been there and able to try to query the API. So I see a question from Brent. Prediction not able to read license plate. I don't know if you are using the, there is an image that I provided inside JupyterLab, inside the repo that is called car.jpg. Maybe Brent, can you try with this one just to make sure everything is working or just tell me, oh, yeah, it's already working. It's okay. I will stop sharing my screen because in fact, everyone seems to be at this point. So they already figured out what to do. So yes, Brent, if you can try with the car.jpg that is directly at the root of the repo, just to make sure it works or not. But yes, the model itself may not be able to detect everything. Okay. That's the limitation. And that's where you see the real work for data scientists is trying to set up a model, trying to set up the best model that is able to have the best predictions. In our case, this model is not really good to be honest. Well, it's quite good with plates that are easy to figure out. And what I found is that the plates from the United Kingdom are really easy to read because there's only the numbers, the letters and the numbers. But there's no fancy things all around as we have in Canada or in the US, which makes it really difficult for a model to figure out, okay, where is the license plate exactly? Where is the license plate? What is different from the license plate, from the numbers themselves versus the graphics or those things that we put around the license plate themselves to product them? That's the difficulty. That's where the real work is. Data science is not about, oh, let's bone a TensorFlow notebook and import TensorFlow, trend model, serve model. Now, it's a little bit more convoluted than that. And that's why it's almost on purpose that it shows a model that is not perfect so that you can see your limitations. Okay. Normally, the job would be this MLOps pipeline where you would gather some more data from a dataset, then you would retrain the model and then you will publish again and retest the model on as many images as you can before being sure it really works. So that's why it's so important to have not only a platform that is able to give you notebooks, okay, notebooks are great, but you can do it on your laptop. Okay. It's from my platform perspective. Here, that's why I find it so interesting to be able to run all those things on top of OpenShift because you can at the same time deliver those data science tools to your users, but you can also implement all the results that goes around. You know, the ingress pipelines to gather data and to have data ready for your data scientist. You can do the model building pipelines to be able to deliver those models into productions. You can equip your model. Say, you know, when you're using Seldom, Seldom automatically export metrics that you are able to then to gather into Prometheus and Grafana to look for models queuing or those kind of things. So that's why it's really important to have all those tools, you know, monitoring pipelines, automated deployments that will really help you make the best of your models, of your data science work. Okay. That's... I'm always preaching for the platform, you know, not only the tools themselves, but where you are running them and how you are building them. So please let us know in chat if you're not having success with your model. Yeah, exactly. Gilbert just highlighted the point that, you know, it's kind of an incremental process that's certainly cross-functional teams that are working on these products. You need data scientists, app devs, dev ops teams in order to get these models into production. So by getting your data scientists on to OpenShift, you've got everybody on the same platform where you want to build these intelligent applications that continually learn from data. And something we didn't really get into today was kind of the monitoring of these models once they're in production, but just in the same way that you can use OpenShift to monitor your standard applications, you can use it to monitor every stage of the process that's happening in the machine learning pipeline. And then you can also leverage different skill sets from your organization because you may already have people who are specialized into, you know, creating dashboards and monitoring and everything, which is something that the data scientists may not simply know how to do or consider that it's not their job to do. You know, I'm talking with a lot of customers and when asking about their pain points with what they are doing right now, I often have the case with data scientists telling, oh, the thing is that I'm doing all this stuff about the infrastructure and things that I'm not supposed to do. I was not hired to do that. I was hired to develop models. At the end of the day, I'm doing all sorts of different things. So here by putting this on top of OpenShift, you are able, and exactly as Torsten described, you are able to, oh no, to achieve it. Described, you are able to handle different parts of the job to different people with different skill sets, different approaches. So yes, it's easier to put this into motion at an organization level. Sorry, I was saying Torsten had a question, but Chris has been answering it in chat, but you can go over that, I think, for the audience as a whole. I had to create for this workshop to be able to have everything inside the SEM repo to different branches. And they are a little bit different. The main branch, the one that you pulled inside your JupyterLab environment, that's the main branch of the repo, it's the Python file that is serving the model at the end, you know, at step five or something, is waiting for just a string, okay, the name of the image. And then the script is written to look, to read this image from the dataset folder, okay, because that's all workshop environment or JupyterLab environment. But in the app branch, the one with which we are building the model at the end, it's a little bit different here. The prediction function is not waiting for a name, for a file name, it's waiting for the file itself, okay. So that's what we do, this processing of encoding base 64, the image so that we can pass it directly inside the JSON payload to the API. So the predict function is just able to receive the content of the image and not only define it. So that's what allows you to send whatever you want from wherever you want. It doesn't have to figure out where to read the image from. And yes, Gilbert made a good point, separation of concerns. Yes, it's a software architecture principle. Here, it's exactly has, you know, okay, before joining Red Hat, I was the CTO of Laval University here in Canada. And so we were not only doing data science, but many applications and things like that. So separation of concerns are for principle there and I guess it should be the same everywhere. You don't copy code into production. You always restart from a Git pool from the main repo that has been validated, you compile and you deploy into production. You don't copy anything from dev to prop, okay. So that's exactly the same principle here. You should have your data scientist prepare model. Once the model are ready, they are sent into a repo. Okay, doesn't matter if it's Git or something else. It has, you have your model and then you handle the model to the dev ops team, to the ML ops team, to deploy monitor under the model. That's how it should work both for practical purposes, but also for security purposes, okay. It's the separation of concerns that is really, really important. Basically it's, you know, it's nothing new here. It's about bringing the best patterns, the best ways of doing things that we've been learning in DevOps for the past 10, 15 years. It's about bringing this to data science, you know, applying the same principle, version your code, version your data, build automated pipelines. That's the same idea that we are trying to apply. So here right at because of this knowledge about helping developers get along with all those tools, that's all this knowledge that we are bringing into the data science field. We are applying exactly the same recipients. So I think given that we're running into our last 20 minutes of the session today, I just want to say thank you so much for spending time with us, getting hands on with the service, giving us feedback and pointing out things that you liked and didn't thank you so much. And we're obviously open to more feedback. So please reach out if you have any. I dropped a couple of URLs in the Q&A section of the kind of chat function. So if you want to find out more about Red Hat OpenShift Data Science, you can do that from either that landing page there or also from the blog. If you're interested in getting yourself or your teams onto the platform, please reach out to your Red Hat account manager or to us and we can get a conversation going there. So I hope you've seen how the platform supports data scientists from giving them this self-service environment where you don't have to bug IT and file tickets in order to get your environment that you can run your workloads repeatedly in and all really just at the cost of having your work stored in Git. That tiny little bit of version control really goes a long way. Hopefully you've had some insight into what data scientists do, how we spend our days. It's not all license plates, but I think this is a really good representation of what we do. And then seen how to deploy those models. So how Red Hat OpenShift Data Science and OpenShift itself helps data scientists to get their models into production rather than just as artifacts that are running in notebooks. Thank you to everybody who has helped us out today and thank you to you for attending. We will be around for the next 20 minutes. Happy to answer any and all questions or happy to try to answer any and all questions, I should say. So yeah, please continue to get involved. We'll be here. Thank you. So Sophie, your links were in the Q&A so I just repasted them into the chat window for everybody. Thanks. So we've got a question from Lynn in chat. Is the OpenShift Data Science part of the OpenShift installation or is it a plug-in to OpenShift? So yeah, as Chris has pointed out in chat, it's currently available as a managed service and it's an add-on to OpenShift dedicated running on AWS. The contents of Red Hat OpenShift Data Science are a subset of the things that we've been developing and running in our community project, the Open Data Hub. So the Open Data Hub is our upstream community project based on Kubeflow and the Open Data Hub is available as part of OpenShift installs. So we've got a couple of questions in the Q&A. I just stepped away for a couple of minutes. Did I miss those being answered or do we want to step through them now? We were able to answer them. Yeah, I missed them too, so we can answer. The question from Lynn, you answered. The one from Nicholas. To add it to other OpenShift installation. So other than OpenShift dedicated, I guess that's the question. Open Data Hub, upstream version of Open Data Hub can be deployed anywhere on any OpenShift installation. So I cannot talk about the intent after OpenShift dedicated, but it's sure that we'll consider this any other installation. Maybe Sophie, you can give more info or drink. No, I think you covered it perfectly. Thanks, Kier. No, but it's sure. We're being asked to install things on-prem, to have things running into OpenShift in the cloud, but apart from OpenShift dedicated, here this first release version of OpenShift Data Science, it's the first release. So depending on the welcome, depending on the continuous pressure of customers, I guess it will evolve into something more. All right. And then we had the question from Lynn Arthur if I have OpenShift running. Can I deploy this to Jupyter Hub? Sure, totally. It's as Chris put in the chat with the upstream version, OpenData Hub that you can find on OpenData Hub.io, you can install exactly the same platform. It's an operator. So what it means, if you go to the OpenData, how is it called again in OpenShift? It's not a marketplace. It's the operator hub. Operator hub. Thank you. If you go to operator hub and look for OpenData Hub, you will find it. Then you can install the operator itself. And then in a project, you can instantiate and OpenData Hub instance. Okay. So you can select which components you want to deploy. It can be only Jupyter Hub. It can be other components that are part of OpenData Hub. But you have all the instructions on the website, on OpenData Hub.io. And then you are able to deploy this exact same environment. It's not supported by Redat. That is the difference with OpenShift Data Science. It's your own environment. But you can redo the exact same workshop. You can do the other tutorials that are available through the website and everywhere. So yes, that's the idea. Try it yourself. If you already have an OpenShift installation, yeah, please just go ahead. And I don't know, Sophie, if we, I guess we have other options for people who want to try OpenShift Data Science. I think we do in the pipeline, but we're still early days here. Still early days. Yeah. All right. Well, I think with about six minutes to go, please shout if you have any more questions, drop them in the chat or the Q&A. Else, again, thank you so much for spending time with us this morning or afternoon or evening, depending on where you are.