 Well, welcome everybody. This is a kickoff session for a new special interest group under the OpenShift Commons umbrella for image builders and thanks for coming. We are going to try something a little bit different today. We're going to have Ryan lead the discussion on image building and how to make redistributable OpenShift ready images, which I think is a topic that everybody's asked me at least a hundred questions about Forums and in IRC and on Slack and in other places at conferences So I know this is of interest to a lot of people especially people who have services or frameworks that they want to make sure are available and ready to use on OpenShift online on dedicated or in their own enterprises, so I think the the goal here is to figure out how to have that conversation and get some information out the door and then and expose what we are considering now as best practices, but also to get all of the folks that are interested in this topic to help contribute to those best practices and to give us feedback with folks that are working on OpenShift origin the project to make sure that Our documentation and everything else is up to snuff. That doesn't mean that we're going to do all the writing on these things This means that maybe some of you can can help us find the flaws in the documentation and create better best practices documentation for image builders And this is really a new world order with Kubernetes and containers and all kinds of other things So there's lots to learn about packaging up your services and frameworks and Programs so that they work in OpenShift and on any cloud So I'm going to unmute everybody that's going to be the interesting thing today I'm going to try and keep the people unmuted, but what I'd like to do is have Ryan kick off the call today and Give us a little bit of a background because he's been working on getting node.js images ready and doing a lot of OpenShift evangelism and hearing About some of the processes and using the processes to build those images So Ryan, why don't you introduce yourself or maybe just go to the first slide because I know I put a purpose slide in there, too I may have mentioned this, but it's really about Discussing and developing and disseminating Documentation the best practices for building and maintaining those Images on OpenShift and Kubernetes. So there's some distinctions between just doing that But I'm gonna let Adam, Adam, I saw Adam Teane pop up there. So I said that I'm gonna let Ryan take it away and walk through the agenda that he's got set up for us today Cool, thanks Diane Hi, I'm what looks like we already covered a quick welcome here Here's a overview of some topics I'm gonna touch on today in in our kickoff meeting We'll talk about some of our existing documentation for best practices around image generation We'll talk very briefly about source-to-image and How you can use source-to-image to help enforce standards in your IT organization or across your Environments, Kubernetes environments We'll also talk about using these tools to Standardize your images by producing your own builder images So we'll talk about what builder images are and how those can be used in coordination with source-to-image to produce application containers that should be super useful And Lastly, I'll go into a couple demos on what I've been doing with these Set of tools in order to produce my own builder images specifically targeted for Node.js developers So I'll start off with a quick look. I can't see the chats so I'm gonna have to refer to Diane to manage some of the chats here and Feel free to speak up if you have any direct questions about anything And hopefully we'll have a conversation as I flip through these So the first one I wanted to show here is Some of our project atomic guidelines So I'll open this up in a new window. We'll take a quick look at what's available currently on the project atomic site There's a lot of good tips here if you're just getting started with building images a lot of great pieces of advice that you'll want to use One thing that we're going to and these are really kind of some of the Expectations that OpenShift is going to have In order to manage your container images appropriately So one of the pieces of advice here is knowing the difference between command and entry point We've got some Advice on how to set up those particular entries in your in your Dockerfile If you're currently working on Dockerfiles We have some advice on using exec in order to make sure that your failure gets reported back out to the container Management services We do expect you to use the exposed statement in your Dockerfile to and one way we use that information is OpenShift will look for this line in your Docker image and Try to map Your our load balancer to the particular port that you have identified via the exposed statement So this can give us information on which port your container is hoping to use There's a lot of great tips in here I Really just wanted to get you get your what your appetite here with some of that information from the project atomic guidelines It's a great resource And I want to outline what's working well for us so far before I jump into new topics There's also the OpenShift guidelines Open this up really quickly. This is from docs.openshift.org There's a link there in the slides if you'd like to click through on your own This has a lot of additional usage information that kind of goes Beyond what is listed in the project atomic docs Slightly more OpenShift specific information here But also very good information if you want to build Applications and services that are going to be portable across a maximum number of Docker or Kubernetes based environments. There's some also some good information in here about security and what we do in order to Help lock down these containerized environments one thing that I wanted to point out specifically is support for arbitrary user IDs in the container And hopefully I'll cover that in our example demo section Any questions so far? One thing I'd like to point out is that most of this content is really designed for operators administrators generally people who have root access if you are handing people docker files to work with you're basically handing out the expectation that they will have root access during the life cycle of your build so One thing that the OpenShift crew has been doing to help lock down these environments And make sure that only root users get root access even during a build life cycle And it also a way to codify these requirements and ensure that they're consistently applied is Using a tool like source to image So source to image helps combine your application sources with an operationally maintained base or builder image In order to produce an application container image This source to image effort is available as a standalone project. You could find it here at github.com slash OpenShift slash source to image And there's a variety of information on using the S2i command line tool to run a build using some source code from github for this example and a image that This example shows is pulling an image from Docker hub and then it'll produce a Docker image locally with the following label or tag So that's how source to image in general can work if you'd like to try it out on your own There are downloads here on the releases page So you can grab a copy of the source to image tool And use that Within your Jenkins environment if you already have an external build process, that's fine You could take advantage of these technologies In your existing build systems as well as in OpenShift It is supported right out of the box on OpenShift though and we'll see an example of that on the demo section So how would you how would one go about? Building your own builder images and helping standardize your runtime environments. Well, we've got a nice doc specifically around advice for building builder images So this goes a step further than our more general guidelines that I showed earlier In order to talk about Really specifically what the benefits are with source to image One of the benefits prescribed benefits here is the ability to use To cache build artifacts And recycle them save them in subsequent builds So that's one particular feature another feature my tops top-selling feature for me here with source to image It is having a workflow that has extracted all of the operational tasks that require root and has Accomplished all those in the builder image primarily where Is the image that your ops team is going to maintain? All the operational work doing your yum install or app get install has already been done in advance And so by the time a average developer comes along to take advantage of the builder image They'll be hooking off of a symbol statement Which is where the build actually happens and a run statement, which is where the runtime environment is booted into so these are the two main fields that develop a Operations teams would tune in order to customize the build and run Workflows for developers And we'll see a little bit of that later as well Any questions about the different pieces that I brought up the builder images Differences between that and a standard image I asked in the chat room Ryan How many of the folks who are on a and you can answer in the chat to how many people have used STI before and Let us know that I'm curious a little bit. You know how well-known the S2L S2I stuff is Yeah, yeah it for most people if you have run a build in Open-shift you have problem whether you know it or not you've used S2I As part of that build process So we'll see an example of what that looks like in the next section and if you're interested in Creating your own builder images We have a blog post on that topic This is what you can expect out of that blog how to create your own source to image builders And some of the selling points of why you might go with that approach This particular example Expects the source code to just be static files that will be served up by light HDDPD So it's a very simple kind of static Web server I Believe I think it's static files But really basic light HDDPD D example here in this post if you want more examples feel free to take a look at my source code or The upstream the primary code that I quote off of so my particular image standardization use case that I wanted to Establish a workflow for Node.js developers a little enabling them to use new versions of Node.js that aren't currently supported under Red Hat software collection libraries So this would be an effort to extend a Another base image that's offered by the Open-Shift team There's an image on Docker hub called Open-Shift base CentOS 7 and This image is actually what all of the Open-Shift builder images are actually extensions to this image So this is available on Docker hub. There's not a lot of information here But if you click through to the github repository information For this particular image you can see that this is used as a dependency for the Ruby source-to-image builder the main Node.js source-to-image builder Python, Perl, PHP are all Sharing from this standard base image And there's kind of a debate on Whether we should all be Repurposing a shared Docker file or whether we should be extending a pre-built image on Docker hub For now all of these projects are extending a pre-built image Stored on Docker hub at least for the CentOS Builder images. All right, so I'm going to pause you for a second. Is that an interesting conversation going on in the chat so pop over there Ryan and So a couple the the Microsoft Savvy guys have been using STI for ASP.net So I'm sure we'll get them on sometime to talk about all that but there's some some things I think That are interesting and not not a lot of people have been using this and some are saying that they had better success building with a generic Docker image, so I think the demo part that you're about to do is just going to be quite interesting Yeah, yeah, I would agree that our source-to-image technology is Not what people might X not exactly what people might expect coming from the broader Docker ecosystem It is really meant to be a standalone tool where you're kind of building your own builder Using the technology so so I think the the core technology that they're probably looking at may be a little bit strange But that's not what's meant to be offered to developers They're supposed to build something using that technology and offer that to the developer So hopefully what I've built Has a clear enough value proposition To outline that use case and hopefully I make it easy enough to understand of how I've gone about building it in the first place Yeah, we should have a .net Builder image as well for sure that that would be really cool So what I've done in my work is I've attempted to maintain All of the established conventions from our official SCL based image for Node.js, which is available here on github OpenShift S2i Node.js is the main code That I forked from this is currently providing Node.js 0.10 via Red Hat Software Collection libraries So my fork here is very similar it Builds in the same way it runs its test cases in the same way So at some point I could perhaps hand this off to the OpenShift team If they were interested in maintaining it or running the builds it should be very easy to plug into a distributed build system So I'll get to the demos here and we'll try to see What exactly is all this information about how would we run a build? And let's let's look at a success case here So I'm going to fire up a new terminal and I'm going to try to use the S2i command To run a build locally here. Here. It's downloading my source code Here it's actually running the build and we could see the build output Going into the terminal here This is if I was running this manually And we should have I look at Docker's images It's like here we've got a new pillar.js image that has been built So pretty easy to run a build independently that could have been initiated from Jenkins or some other system Let's see how this same thing might look in OpenShift So I'll use the OC new app command you actually I'll need to really quickly log in to my Local OpenShift virtual machine. I booted up this morning log into this environment and I'll create a new project and I'll also want to log in from the command line should be logged in here with our OpenShift all-in-one virtual machine if you want to try this out On your own. I have a link here You can go to openshift.org VM and we have the same virtual machine environment that I'm using also the OC command line tool that I'll be using is also available from the releases page on OpenShift origin on GitHub So here is the OC new app command that will take my builder image that I've provided and a repo and This will schedule a build and a deployment in OpenShift so I can copy this example Into my terminal and I haven't actually uploaded this particular image I've uploaded this particular image to Docker Hub, but not to my Individual OpenShift environment so you could see hopefully how easy it is to use these images. I'm actually going to build using the current tag But I've labeled on this Node.js image. I Labeled several Node.js releases all onto the same image So we'll be using the Node v6 release by selecting the current tag here So this should schedule the build and deployment. You can see it's creating some resources in my virtual machine Let's go see what that looked like from The web console. Looks like here's the new service has been scheduled. We've got our build running This should be really similar to what we saw from the command line Looks like the first step is downloading the Docker image from Docker Hub I'm not sure exactly how long this will take to download, but we should see the build Automatically stream the build logs automatically stream into the web console Looks like here. It's downloading the application sources and We could follow the logs here Tail the logs to watch it stream into the web console. Once this build is completed the resulting Docker image will be automatically uploaded into our integrated Docker registry as a new application container image and Once that image upload is complete will automatically trigger a new deployment for this image So we should see as soon as that upload into our internal Docker registry finishes a new deploy Should kick off right here So that's a pretty clean workflow From the command line for enabling developers to test out my new source to image build without having to bother their administrator and ask permission to get a Particular base image installed. So this is more of a community use case Showing portability primarily We'll check back in on this in a minute. Let's see What else I have for the demos Did the new app demo? So you can actually help make these even easier to These base images you can make them even easier to distribute By packaging them up as a template. So I have one of these templates available inside my GitHub repo and There's some additional Instructions on how to install this into your project. So I could run this OC create command in order to install the Builder images into my existing project Looks like I already have Image stream that was automatically imported when I ran the OC new app command So I have a case for that in the documentation here If you've automatically imported this command using OC new app You may need to clean out that existing image stream before Okay, so that removed my old image stream that only had the Current tag and is now re-imported the image stream with all of the labeled tags and No JS releases that I've listed on Docker hub. So here's the The amount of no JS run times that I am making available to Developers so they can select from node v6 or the current tag, which is a alias They can select the latest LTS release or a node 0.10 or 0.12 release for their application Let's check back in on the web console and see how we've done so this first build has completed I Can go in and inspect this container that we have running We could see the logs after it booted up See the report. It looks like it reported. We're at node version six Here in the logs and if I run in the terminal I can also see we are we have node version six available another really interesting feature that we touched on earlier was the security aspects of these containers if I check ID Dash you looks like I'm running as user ID 1001 this is usually I May have a bug in my code usually I get a random user ID back when I run this Command so this this demo right here was supposed to show a much longer user ID I'll have to check back in on that feature But this should be part of the security precautions as we automatically drop Drop your privileges as soon as possible before the build even happens Ideally, so I've installed this image locally. Did you have a question Diane? No, I'm just getting some text is on where the dot net Stuff is the dot net images are and One person is asking does S2. I work without open shift and the answer is yes Yeah, and I had a slide on that earlier. You can grab source to image directly off of github and run it independently and The resulting image is a docker image as I showed earlier Here was my Most recent image and I could do a docker run IT with this It needs a port number see if this gets us our Local host 8080. Here's our application just running off of a straight docker run command So yeah, you don't have to use this technology with open shift But I think it's great to have it prepackaged and ready to go right with an open shift So the last example I showed From the slides here was how to install this set of image streams or image source to image builders and make it available to developers so You saw how I could load this application from the command line Let's do the same thing from the web now that I've installed the templates So I'll click on add to template here, and if I search for node J s you could see that I have the Let's show all here looks like I have the standard Somewhere in here the standard node J s images Provided by open shift, and I have my additional builder images that I've provided on my own So there's a LTS tag. There's a latest. There's node six Node five dot ten five dot eleven. There's a ton of different releases available here and Instead since I've already demoed the node v6. Let's check out the LTS release. I'll go to node LTS I'll call this application or this service Dub-dub-dub and I'll pick the default source code. I also You can define your own default source code as part of the source-to-image base I'll click on continue it looks like our new build is now scheduled and Running I can view that build since we've already downloaded most of the base layers The image pull should be much shorter since it will be able to recycle all the base layers that were provided by the CentOS 7 base provided by the OpenShift team and all the layers that are in common with the other tagged release of OpenShift that we've already downloaded so this is only going to be downloading the differences between the current release and the LTS release of Node.js Which have been saved as a separate layer on Docker hub When this build finishes we should see a deploy kickoff here Just like we had with our command line usage case and from then you can go ahead and scale it on up By then it's it's a fully built and deployed image available Within Kubernetes. I could also as an administrator push an update To the base image and that will cause any application containers that have been based on the updated builder to Automatically be rebuilt in order to pick up the patches to the base OS So my workflow here is an administrator if I need to make sure that Heartbleed or shell shock or whatever the latest exploit That hits the news if I want to ensure that it's been closed throughout my entire IT organization I can push updated builder images and any application instances that are that have been built on Top of that builder will automatically get rebuilt in OpenShift That's kind of the beauty of this whole layered build approach Yeah Any other questions about Installing these templates making these this is really I think an important point to note that you want these things to be any images that you build to be very easy for Administrators to pull down into their OpenShift environment and provide to their developers So here's a mechanism that that I've added in my particular Example repo I would highly recommend that you add something similar to any sourced image build that you that you establish so if you want to look at What that source looks like I actually have two of them here I have one for my main releases and I have a separate set of images on Docker hub for release candidates Or preview releases so I usually push here first once I'm happy with the results I push out to the primary image stream. Here's what the sources look like for Importing these images into an OpenShift environment and you could see I have a tag For this Level of detail and here's the Docker image with the release tag that I'm pulling down The questions calls for questions here Yes, Adam. We do want you to package this up for Fedora and another thing that would be really interesting for Fedora, I would love to see if OpenShift This is what all of my applications is are all inheriting from source-to-image base This is what all the Ruby, Node.js, Python, Perl, and PHP applications are based on and this base image is Can generate OS is built for CentOS or built for REL. It would be really cool to see Fedora added to this mix as well so then I can really quickly rebuild my application source and make a source-to-image Fedora available or source-to-image Python by picking up a different source-to-image base So I have a section for questions coming up next, but here's my call to action You all can help us out By helping promote best practices for image production and distribution for by helping standardized workflows for dev teams and operations teams You can help improve container security and most importantly you can help grow the container ecosystem by packaging up your solutions and Making them easy to share Questions this is kind of the end of my demo not just questions I think what everybody is on has themselves on mute, and I want to change that If you go in and unmute yourself, I'm going to unmute all so give no excuses not to talk I'm curious that that we've got a lot of the dotnet folks on here from click to click to cloud and You talked about, you know working with the Fedora folks, but What would it take to get the the dotnet image incorporated into this to this flow The they seem to have a working viable base image Where would we find if we could find that if they posted it in chat and if one of the click to close It probably depends on how That stack is built if they're building from a docker file. That's definitely what I'm doing and what What this source to image project is also doing? But do you want to expose that docker file directly to developers is is a kind of a Maintenance and security question that you're gonna have to ask yourselves at some point Docker files are a great way to get people with root access involved But I'm not sure it's the best way to onboard developers unless you expect all your developers to have root access for your build life cycle So we have docker files in this repo. You can see how we build our base layers for CentOS and REL and if you wanted to see How we extend those base layers for node JS Here's the official process for extending those base layers for the CentOS image and the REL image what we do in this case is we actually do a yum install of the SCL release and then install the node JS 10 package Pretty minimal For as far as package installation goes because most of the work has already been done Here in the base CentOS build If you want to look at the differences for my repo I Actually pulled down Some files directly from Docker hub Here's the differences for my Docker file I actually set a bunch of credentials interact with a GPG key server and I do Curl of the node JS binaries from node JS.org in order to get the latest binaries that are not available in In red hats software collection libraries So definitely Docker files are the right way to go assuming it's a build context that requires root permission once you have a build that already encapsulates your base OS and Your dot net runtime, then you should be dropping privileges as so and handing off to developer workflow All right, so I think that one of the crystal cloud guys is finally unmuted himself Can you tell us a little bit about the process that you went through to get your image? All right, and I Don't think I'm the best person to answer these questions We have Madan here. He can guide you through the whole process But one thing I can say that we are using a source to image and we are making a templates Not only with those bear dot net base images, but also with some other functionalities like database for what he being extra and so on so forth And there was a very nice question about the security. I would like Madan is here To answer this Unmute himself unmuted for a second. Here we come madame Yeah, then this supposed to be the image is developed by using the base image We are using the Docker find concept for building the image. There are various labor layers layers involved in building the image and The details are provided on our website You post the link in In the chat Yeah, surely I last company just send a link It sounds like like Horatio also I think he's gonna go to telecom. He's on the on the call as though I'd mentioned that he's using Docker files At their In their process to do it too. So it sounds like everybody's on the right track here There we go So I think we're we're getting we're getting people into the right track I just think that we didn't have a lot of people who were aware outside of the clips of cloud folks who are red hat partners as well Very aware of SQI, so I think this is a good base jumping off point To get people into the process And really source to image is primarily about building a single image and Enabling developers who have source code that they want to layer on top of an image If you were building an image That was a database image. You might not use a source to image to to assemble that But this type of strategy allows you to drop permissions as quickly as possible So the application build is not run in a root context So I think this is a big security upgrade potentially But it all depends it's it's definitely focusing on a very particular use case And I think we'll have additional meetings and discussions that talk about how to get multiple images orchestrated together standards for Templating these images and sharing multi service Multi-image solutions using these template files So I think that'll all come in later meetings and for the discussions But this is just one way of helping provide standardization throughout your IT organization by Building better operations tools that enable your developers That in the next session that we were going to top it that we're going to try and cover was the enterprise workflow for Banco Santana's protobahn IT group. We were going to talk about They're using their CI CD workflow to do build images For production So I think that that will give us just yet another use case this one really focused on the developer side of things I'm wondering if other people have there you go And there's the dotnet one. I'm wondering if the click-to-cloud guys Would talk maybe and I'm thinking a cadence of every two weeks for the The SIG group meetings to talk about this subject other other subjects That people would like to hear about If so type them into the chat and then if I incorporate them Or type them into the mailing list if you have questions about What we're discussing today or feedback on the documentation because I think that was Like Adam and a few other folks on the call in the chat room in the early on in the conversation It sounded like the documentation that we have for this process is missing something and I'm curious what people Are thinking that it's missing or if now that you've seen this demo With someone's like and I'd really like to see docs that don't involve OpenShift so like if you unmute yourself Can you hear me? Yep, I can hear you explain what you mean So I know that when I learned OpenShift and Docker whatnot. I started really really simple with just a local Docker server running and building images and then I kind of graduated up to OpenShift because even though OpenShift has got all this great stuff It does require a lot of knowledge to really know what's going on I mean even this presentation talking about image streams and builds and you know It's a lot to understand just to get started with one part of the technology and So I think it would be really helpful if there was some kind of tutorial that said okay You want to build a source 2i so like the example? I've got is I've got Docker image for a maven built Java application it runs on Tomcat I Think s2i is the right way to go but it's been difficult for me to kind of get into it because I Would really like to start with okay How do I generate just a generic docker file out of this and and how do I build this inside a docker even before? I get to OpenShift and then I can start layering on the additional terminology and stuff like that so I'm rambling but yeah, that that was kind of why I was thinking with that So I'm trying to think that that's actually not a bad way of Presenting the information is to do it once for your application Just create a docker file the generic way and then do it again with the s2i way Outlining the the different terminologies like image streams and templates and the things that that we love about using OpenShift and Kubernetes and all that I'm probably a not that's probably a good blog post somewhere or something in the doc center Yeah, I was gonna suggest maybe having two documents in the Yeah, basically two documents in the docs one that they a simple getting started with directly the s2i command line that Addresses how to do this workflow Very simple very standalone and then a separate document how to integrate this workflow into OpenShift Yeah, I think that's a great idea I Think that would be good and I know we're doing a lot of rewrites on the doc center as it is So I'll make sure that gets back And Ryan just posted a simple no OpenShift s2i Jists for those of you who'd like to take a look at it in the chat room So beyond that I know like with open unison mark that's your Baby there at tremolo if you were gonna go and try and containerize that offering What else do you need to help with in order to get that ready to run it with OpenShift? well, so like the way that so Sorry a little discapabulated today. So like the way that we did The open unison deploy it's open unison. It's just the j2e war file You know what once it's built, but there are customization points in there JSP pages configuration files key stores Images stuff like that. So ideally if I when I deploy open unison without Containers I Tell people to start with a maven file that goes with an overlay and then add your extra stuff into that So that way you get all the binaries it produces the war file and then you drop it into tomcat or J boss or whatnot When I created the docker image for open unison What I ended up doing was because I didn't have a good way to do that and I think s2i is the right way to do it Was I ended up creating a base image and really all the base image was was kind of a little bit of a Customized version of tomcat to make it easier to deploy the ending up war file So ideally what I'd like to be able to do and I'm thinking back to what little I did with the old OpenShift v2 stuff Is say okay create your git repo Your git repo will have Maven project file and at a pom.xml and all of your customizations and then you're gonna run a command that will If you're not running OpenShift You're gonna run a command that will go ahead and generate a docker image file that you can push into your Repository or if you're running OpenShift You know instead of going through that say, okay, here's the link. Here's the URL to my Docker or I'm sorry my git repo Just pull it in and do your builds So that's kind of what I'm Like it to be at least in my head. I don't know if I'm just completely off base No, I think that that Sounds like the right way to do things and the reason I asked is because there are many More complex use cases than what we saw today And that and that's what I'm trying to tease out in this conversation and image builder SIG is to get people to to share their processes Get people like you to try it Do some of that work on the side and then come back and show us where the holes are like in the documentation and and help feed the best practices and so we can get better and and Get better redistributable images available for people to use with OpenShift That's sort of one of my my goals for this group The other thing is and I know Adam is on and he's building base images for Fedora So I think at some point it might be interesting for people to find out, you know, how that process happens and Definitely want to make sure that the the click-to-cloud guys get on and talk about How to you know work with their images and where to find them so that that'll be something that you can take up in a future Future future End hopefully I think we have that we scheduled for an OpenShift Commons briefing sometime not too distant It's not we will get that out there as well Are there other topics that people? Would like to hear from other the other resources that I should pull in from the the open source project or red hat engineering That we can help you To get get started and build more of these images and give us more feedback if not Or if you're just too shy to say anything Posted on the mailing the the sig mailing list I'll post the links to this and the and the recording of today's session on The mailing list and on the image builder sig landing page for Open on OpenShift commons, so please Share share this widely. We'd love to get more feedback from folks and you will do on May 18th We'll meet again, and we're going to get some insights on another use case the enterprise use case for That part of on is using for Banco Santana's in their multi-ranging note deployment of OpenShift Which is running on AWS Curious, so it's it's going to be I think a lot of information to digest mark I'll probably have to you to try and build those images or open Unison and then come back and tell us what you found out as well So without further ado, if there's no other questions, I'm going to end this big Kickoff meeting and thank you all for coming