 So, hello everyone, welcome to our session. This is part of the community track. I am here with a few others from Orlando, Florida, all the way from the United States. We represent the OpenStack Central Florida group. So you'll be coming along on this journey with us and hopefully you guys learn a thing or two about some of the lessons that we've learned that helped us build and grow our community as well as to help build not only our cloud, but also our relationships with everyone that's kind of local to our group. So my name is Luke Short. I'm here from Red Hat. I'm part of the automation consulting team. I primarily work with automating the OpenStack lifecycle using Ansible. We also have Joe Still from Phase 2 Technology. He's a senior DevOps engineer. And also Maria Bracho, who's also from Red Hat, part of the OpenStack product team. And we had one more member of our group who unfortunately couldn't make it. So I just wanted to give a quick shout out to Donnie Hamlet. He's been a big help. He's the leader of our organization. He helped bring this all together and we wouldn't be here today without him. So first of all, a big huge thank you to Hostime, who actually has provided us with Cavespace, free networking, free power, free servers to help us build our community cloud. So this is 100% free, no strings attached cloud, which is pretty amazing that companies are allowing us to do this as a user group. After Studios has also been a huge supporter in this. We needed a very large space where we could convene and meet with each other to have all these amazing talks and presentations from the community, from different members of companies from all over the world, who have come to help give us some presentations. Red Hat has also been a large sponsor of this. From this picture here, Maria was actually able to help us get a meetup, a whole bunch of executives, engineers, consultants, all over from Red Hat to come. They came over, met up with their local community. It was such a great time. We had people who were from our group, who weren't even from our group. We were all able to convene, learn from each other and network. It was such a great experience. So the OpenStack Central Florida group, CFL Central Florida, mainly the Orlando area, so think Disney World, Mickey Mouse. Donnie Hamlet, as I said earlier, was the founder of our organization. He helped bring us together towards our common goal of learning about OpenStack. And it goes much further than just OpenStack. So as they were kind of talking about in the opening keynote today, it's kind of all about open infrastructure. OpenStack is not just a single service. We're talking about all the different technologies involved. So it's written in Python. A lot of services are moving to containers that are managed by Kubernetes. There's all these different technologies that we're all getting together to learn about and share our experiences with each other. So currently, we have over 300 people registered on meetup.com who have either come to previous events or have been interested in some of our events. We've had tons of presenters, which I'll talk about in just a second. But it comes back to this whole idea that OpenStack is such a great technology to bring people together because you don't just have a single focus. You can kind of branch off into wherever your heart's desire is. There are so many other community groups nearby. There's the Python user group. There's Docker user group. And we've already worked with them to help kind of spread the knowledge around because there's so many overlying areas with that technology. So here is a list of past events and speakers. This isn't even the whole list. The main point I want to get across here is the fact that we got together on our own in our spare time and we were able to get all of these great presentations. And all you have to do is go out and ask. So many companies out there, Red Hat, Suse, Rackspace, Chef, they're all so willing to literally fly out to wherever you're at, give a talk to your community, even if they don't fly out, even just virtually. And there's so much you can learn from these experts in the field. So you are learning so much from this. Getting together as a community helps you to build your own skills, helps you to help mentor others. There's so much opportunity for everyone involved. Sorry, before we introduce this video, we talked about building a community. And this is all about people and where we live and where we are. So Orlando, probably the first thing that you think about is Disney and the parks. And I think at least the two of us have annual passes to Disney. And I'm pretty sure it looks as well. And we do do that, but we also have a community of technologists. So we want to tell you a little bit about that with this video. This is Orlando. This is where we believe in magic and fantasies and wishing upon stars and the power of the imagination. This is where we believe in dreams and seeing them come true. This is Orlando, known around the world as the home of happiness. And to those who live here happily, as home. This is more than just a place to stay awhile. It's a place to stay on the cutting edge. Here, innovation comes in every form. Entertainment in every variety and thriving businesses. So if you think you know, all there is to know about Orlando because until you get to really know this place, this community and see all the reasons why it's so magical, rest assured, you don't know the half of it. So we have a great community and we have a lot of different industries that get together to, you know, do some magic. We have a whole set of processes. So we're in really good company. Not necessarily very specific, you know, OpenStack or Kubernetes developers or engineers, et cetera. But we're surrounded by folks that do consume that tons of IT departments starving to get more information and to learn. That's why the goal, the specific goal with which Dany, who's not here with us, but wanted to be, created this user group was to get us together to learn. So the first goal of this group is to be a learning platform for all of these professionals that want to come and share with us. Part of the things that I also wanted to say is, again, it's not Silicon Valley. So obviously we don't have tons of OpenStack operators or tons of OpenStack developers, but we have managed to bring people to come and talk to us and share with us how to build clouds. And we've had a couple of examples of building clouds from scratch, which we will see more about that. So yeah, this is Orlando, big in the simulation and entertainment industry, obviously. Tons of universities. One of the things that we had to figure out, because we're such a small community, we needed to figure out a way of getting together. And one of the things that brought us together was OpenStack, it was open source. But then we're very familiar with building open source software, but here we wanted to apply the same principles to open source software, to how we collaborate and organize ourselves. So I earlier shared with, I think it was Look First, this book called The Open Organization, I've read it years before, and it was actually the reason why I wanted to go and work for Red Hat, and I did apply, and then that happened. And I shared that, and I said, hey, I think we need to work together. This way, I think we need this community to apply these principles so that we can be more effective. Since we're so few of us and we're busy, so organizing meetings, bringing speakers, getting the ball rolling, and getting the community cloud up was being very challenging when you have only two to three hours to really apply to work on this side project. So we started thinking about this and the rest of the group was very positive about it, and we said, sure, let's apply the tenants of the open source way into the way that we work. And those are right here. So from a transparency perspective, we needed to make sure that opens organization works to make their data available to others so everyone knows what is going on and has access to all the information and also to external participants. So we're very transparent in the way that we work and that allows us to work and communicate better if you cannot make it to a meeting or if somebody else cannot come, then we still get the ball rolling and moving. Inclusivity, this is pretty obvious from the word, but it also, it's inviting others with different backgrounds to come and help us. So some of the obvious on this are gender, creed and whatnot, but we have a lot of inclusivity in different technical backgrounds, so networking professionals, storage professionals and infrastructure professionals come together to help each other build a cloud because OpenStack needs all of that. And then also adaptability, so be able to be open to change. So at any time that we started a new cloud, it took us like six months to then get together again and start the new one and OpenStack obviously releases quite often, so we were like, okay, now we have to go start from scratch and figure out which release we're on and try to see which distribution we're gonna try this time, et cetera. So it needs to be very open to change and adapt. Collaboration, again, pretty obvious, but really being open to others coming in and jumping in. It was really important for me working for Red Hat, specifically from a product perspective, not to be very prescriptive to the community, but actually be a member of the community. So the way that I'm contributing is just sort of bringing everyone together and making sure that the resources are available to learn and to continue to do what we do. And also community at the center, so that's pretty obvious. Cool, all right, yeah. So our first attempt at a community cloud was back in 2016 with the Liberty Release. We had the bright idea to perform a totally manual installation. I think that was actually Donnie's idea. I think he said it'll be fun. It was. No, it was fun. It was just a lot of work. So this photo actually is of the OpenStack CFL team. I think there were like 10 people that came. It was a good turnout. It was really fun to have that many people there. Hostime actually even sponsored the food. Thank you, Vicky, if you're watching, she's the director of Hostime Marketing. To get us started, Donnie brought three servers and a C355025 or 24-report switch that'll, you'll see one that's a silly later. Install the CentOS 7. It actually took a bit of time to do. We probably should have done it beforehand rather than be like, give me a sec, let me install three servers with CentOS 7. You'll notice we should have prepped. It turns into kind of a recurring lesson here. After that, a lot of time was set up, was spent setting up the switch, configuring the required VLANs, making sure that everything was configured as was expected for the build. And then finally, we got around to following the manual installation guide, which is linked up there. I think it goes to the latest version. Though these days, of course, as we'll cover later, there are better ways of installing OpenStack than painstakingly doing the manual process. We get better over time. Yeah, no, it's still that iteration, right? The manual installation actually seemed to go pretty well. We didn't get a lot of errors. We followed the guide very, very specifically. But in the end, there was trouble with public networking. We just couldn't seem to ping the VM. It was up and it looked like it was up and it thought it had an IP, but it just no access and it wasn't the security groups. Luckily, we had Spencer Crum, developer-advocated IBM, to guide us through the neutron troubleshooting, another theme, the group in collaboration for the necessary competences to get it done. Network configurations were a pain. This is where a lot of the waiting was. It was like, hopefully Spencer knows what to do when we were all just listening and waiting for Spencer to tell us the answer. There were trouble where we didn't label things correctly. We didn't follow the architecture we planned. We had this whole plan and followed almost none of it. Made a bunch of ad hoc changes that bit us later. It didn't help that a lot of us were missing the required competence to understand VLANs. I know I didn't really quite understand VLANs. I thought I understood VLANs. I did not at the time. I do now, I think. Spencer did get it working in the end. I think we cheered, right, when he got one of the VMs to ping. Yeah. Yeah, it was a very exciting moment when he was like, yeah, it's actually connecting. We learned a lot about the main OpenStack services and their configuration was very interesting, very informative, but it was a difficult process. Though it was quite a long day, it was definitely a fun experience to have everyone involved there. It was very cool to have the community. So after adopting the Tenants of Open Organization, as Maria described, the OpenStack CFL community members were able to operate with a little more autonomy rather than hopefully having the availability of an individual. We were all able to just do what we thought was best. The community itself became open source is the way it goes. Good book. In early 2018, I think it was Luke, actually, that pitched a reboot of the community cloud using Ansible for Networking Management, OpenStack Triple O, the RDO packages, and the Rocky release to get everything containerized and automated. I quickly established a, I did a free private GitLab repo because we wanted to use GitHub, but it's public, and I wanted to use a weird password management, so it's private for now. We hope to open it up later when we have better password management, but got that up for good. Task management, documentation, and task management, it was actually really helpful to have like, what are we doing next? Everyone that was interested, I just gave them just full admin, just to get everyone all the access they needed. Again, open org, if you empower people with access, they can refer to it and add to it. There was a lot of really good collaboration there. I think it'd be awesome. So first up was the Ansible Networking Automation. Luke was able to hook us up with Colin McCarthy, a red-hatter with some serious Ansible Networking experience. Colin shared his GitHub examples with us, and I think I, yep, I put the link there, check it out, and he showed us how to tame Cisco's iOS with Ansible. I thought I had recorded it effectively, but I botched the audio recording, so it's just him scrolling silently through his GitHub iOS examples while I try to get my dog to stop barking. So it didn't quite work out. We tried to record all the sessions. That first one did not go well. I was no longer in charge of recording after that. However, I was inspired after Colin's explanation to give it a try on our own switch with zero switch administration experience. You'd think that the Liberty installation would count. It did not, but with zero experience, we first had to enable SSH on this thing. There was only Telnet accessible, the C3550, which is why I specified long EOL. I asked someone on the Cisco forum for help. Where do I find this? And they were like, go look for it, which is not helpful. I finally, after Googling the exact firm where someone was recommending, I found some sketchy FTP site on some random IP and just scraped all of the firmware down. I installed one of the firmwares that looked like a bigger number, but I found later after some more research that you needed the K9 version for the crypto functionality. That's what gives us SSH, which we needed for Ansible. It doesn't work or it might, but it's not best working through Telnet. I actually don't know if it works through Telnet. Certainly not through the console serial cable. So after installing the K9 firmware and following some guides for SSH, I was able to authenticate with Ansible. Pretty exciting. The iOS config Ansible module worked actually pretty well, but the template, it was weird, didn't seem to quite apply what we were telling it to do. We would be like, oh, you know, port nine should have these configurations, but when we'd run it, it would have like some of the old configurations. So that was kind of strange at this stage of the operation. Another example, like port 11 just would not respond to anything. It was just not changing at all, which made no sense. But it's actually pretty funny. None of us actually knew how to set up a port channel in the Cisco iOS. So in the video, because we recorded the Zoom session, a lot of our meetups for this rocky installation were virtual. We literally, in the video, Google had to do it and we're like, let's learn how port channels work. It only took like a couple of minutes to find just the Cisco official, here's how you do it. We added it to the Ansible template config and we're able to apply it without issue, I think, because there was no extant configurations to try to overwrite. So that worked really well, but still port 11, not playing nice. We cut the recording off at the hour and a half. I thought it was a good sweet spot because I don't wanna just have a six hour video, where I'm like, struggling to fix the networking. But I think I thought that was at least an interesting educational experience. Can we get the next slide? Oh yeah, actually, Luke, do you wanna discuss this item a little bit? Yeah, I'll tackle this. So one of the interesting things about running a free cloud is that a lot of our hardware is kind of ancient and low-spec, so if a port 11 on the switch didn't work, it could very well be a hardware malfunction, we don't really know, so it makes it a little bit more complicated to troubleshoot stuff like that. So right here is an architecture diagram I came up with for our cloud. So the main things here is we have our Cisco switch and for triple O to work, let me just give a brief overview of triple O, it's the upstream version of the Red Hat OpenStack platform and triple O stands for three O's, it's OpenStack on OpenStack, so we actually deploy an all-in-one OpenStack on the under cloud or the director node and that is used to actually install the over cloud, so that's going to be the end result that your users will be using and interacting with. So we have our under cloud, that's probably our beefiest server, because this is running all of the OpenStack services on it, from here it's going to be using Ironic and Nova to provision and manage the controller and compute node, but what we have here is very simplistic, this is just a simple, just one controller, one compute, no HA, we just need to cloud up and running, we're just playing around with it, we're just learning, so this is what we got and we're hoping to purchase and possibly get more hardware donated so we can eventually expand this out and see how far we can go with this. Very cool. So yeah, so the next part of story time here is the under cloud, so to prep it I, and notice we prepped it this time, I did not say hold on a sec and wait in silence while I go install it, I imaged it with the latest NOS 7, I still had to finalize the switch configuration because I didn't get port 11 working which is part of as you saw our diagram, they're like we need port 11, so after the upgrade though, my Ansible playbook would no longer authenticate which was kind of weird, I solved it later, I'll tell ya. I wound up just logging into the switch and doing it all manually, applying the configuration, desired configuration manually, which actually was a good thing because it revealed the trouble with port 11, the mystery of port 11. The commands I was trying to run were throwing errors that were not obvious, right, in the Ansible operation, it didn't tell us, it failed, it was like I applied the config, you know I ran the things you told me to run, but I learned here that I actually need to make sure to be more idempitant about the way the commands are used, idempitancy meaning if I run it twice it'll yield the same result which is what a lot of Ansible is motivated by. In this case, I had to use the command switchport to activate it as a switchport, I noticed in the errors it was saying error cannot do that must be switchport and Google was like you need to run switchport. After I ran switchport, I was able to run the other commands just fine, they all worked well, I added switchport to the automation config which I haven't run yet because I did a bunch of manual config, I was going to wait until after we did our build to break it, but with that up at the top, had I put switchport at the top, my commands would have run without issue, so good lesson and I guess good on the manual process were educating me on that. And then the undercloud install. Oh well yeah, sure, sure, I would like to mention that the authentication troubles are not to be, Ansible 2.7 changed how networking administration was configured, I think it's better the way they did it, but it's way cleaner, it's the way to do it, but I was surprised and confused at first, but you know, one quick look at the docs is like here's how you do it, thank you Ansible. What was it, oh and then the actual undercloud process which is just one command worked without flaw which is kind of boring, but awesome I guess that it's working, but I have no funny story about how it had anything but success, so that worked really well, it's like 50 containers or something based on COLA just up and working, so that was actually really cool. Yeah, I mean it's amazing how big of a headache OpenStack is, but when you come to deploy the undercloud the all in one step, it's the simplest process, like Red Hat engineers in the community have figured out a very streamlined process to just set everything up and just have it work and that's very important considering you want your undercloud to be as stable as possible to then manage your overcloud that it's actually deploying. Yep, cool, so before we could utilize the undercloud though for deploying the overcloud we had to prepare IPMI on the overcloud nodes, so the actual undercloud installation went well but it being utilized needs and preparation. IPMI was prepared from the BIOS and with IPMI tool we learned about native VLANs, untagged packets get treated as in this case it was VLAN 100 per architecture diagram, packet comes in tags 100 and then comes back out untagged so you can use things like IPMI which does support VLAN but in this case we didn't configure it with VLAN DHCP and PXE, when you're booting up it's like it is untagged so we needed the native VLAN. One of the overcloud nodes was accessible over IPMI, it worked really well and the other one just didn't. It gave us a strange error that we later found had to do with it's basically not accessible. One of our community members Justin found a great option, apparently sometimes with IPMI even if you've configured it and it looks like it's gonna work you need to turn the machine all the way off and then back on so his idea was to turn it off and on again which worked really well thank you Justin. We actually were like there's no way this is gonna seriously be the answer here but it was. Yeah I think we had to literally unplug the power plug and then plug it back in. Yeah no I turned it off unplugged it power to make sure even the capacitor or whatever like all the power was definitely out and then plugged it back in it worked out immediately so that's working really well. I didn't wanna mention it's really interesting especially with all the people I've been mentioning look at what they helped us with, look at what they helped us with having all of these diverse competencies available to us was super valuable I mean it really shows the value of making sure you have I think it was mentioned in one of the keynotes all of the necessary competencies to accomplish a task so that was really cool. So fixing VLANs and he's gonna control the thing and I'm gonna do like so this event I thought was a lot of fun it was actually captured in one of our latest videos like the hour mark so it's funny that we heard earlier in the Volkswagen keynote that networking is the hard part it's like the hardest part right? It is they're not lying. Right yeah so Luke pointed out the uplink was using VLAN 100 instead of VLAN 10 this is like from our Liberty install we used VLAN 104 you know the access port packet comes in tagged 100 and then anyone that wants to have public subnet access you need VLAN 100 in our case we targeted VLAN 10. Rather than change our desired specification we were like I was like no no we will do it right we'll make it the way that we said we would let me change it to VLAN 10. I boasted about how I can totally switch the uplink without having to get out of my desk. You know I will keep it online I'll keep my access and I'll bring the new one up I'll start using it and then I'll bring the other one down and I won't have to get out of my desk. So I added VLAN 10 to the under cloud trunk and then switched the VLAN 10 on the uplink and Luke can I get the next slide? And it stopped responding right? Cause that's how it goes. And if you go to the next slide actually cause it's kind of a reveal situation SSH isn't responding now. So I definitely had made a mistake. And if you give me the last slide here's a screen cap of my surprise and Donnie laughing at me actually which was a lot of fun that's actually pictured Donnie at the bottom there. I had forgotten the server. The server was not able to accept these VLAN packets. So I had the switch all correct but I did not apply to the server. You need both so and it's funny cause like in this video I'm like no I know what I did. But I mean the rest of the video was me picking up my laptop running into the co-location area setting it like in the cab while I console the server and bring the interface up on the new VLAN which was a lot of fun. They were laughing at me the whole time. All in good fun of course. If I had remembered to add the VLAN 10 to the server I feel like it would have worked and I wouldn't have had to get out of my desk but of course it failed. So I was gonna say so to end that that's a lot of the interesting lessons and experiences we've learned. I mean you can't do stuff about experiencing some troubleshooting. Yeah so to end this off I just wanna say just mention you know these are some of the tools that we're using for our community. I mean up has been a great thing to actually get people together at a physical location. Slack is amazing for communication with everyone to keep tabs and what's going on. GitLab for source control for Ansible Playboats for a triple O deployment templates. Zoom for video conference. This is recent tool we've kind of moved to. It's very important for us to have regular updates. We're wanting to move to having meetups twice a week and even if everyone can't attend we at least wanna have it recorded and share it with the group to make sure that everyone can catch up, see what's going on and kind of learn and see everything that we're doing. So hopefully with this presentation you guys are kind of inspired to create your own community group, build your own cloud because it's such an amazing experience and you can get so much help and support from the community. It's amazing. I'd like Open Slack is one of the most amazing pieces of software and you will find so much help on IRC channels, mailing lists just everywhere. So I encourage you, create your own community groups, you know message us, you can even connect. We got a QR code links to our Let's Talk link. This has a bunch of links to our Slack and different outlets that we kind of push out information. So hopefully we can all kind of work together to build a global presence of a community cloud. So thank you guys very much. Do we have any questions from the audience? Yeah, it's like the next 15 minutes is just Q and A if you have any questions or interest. I believe the microphones are up. So the question was, is there a conflict of interest having different employers working together? Sure, I can answer that. So as part of the, you know, just being open organization and working with open source, this is not part of a company specific but it's part of 100% community. We seem very redhead heavy over here because we live in Orlando but we have members from, you know, other companies also joining us. In fact, we have folks from other companies come and visit us. That's why it was so important to enable us to have virtual meetings as well because not everybody lives in Orlando and can come and virtually just talk to us about the stuff that we're doing. From a company itself, having trouble with the work that we're doing, all we use is open source. So we don't use, although the first one was, we did a SUSE install once with SUSE. Yeah, well that was just to experience and test the technology but that was still an educational experience. Exactly, so it's mostly educational and we do it obviously with full rights to the stuff that's, you know, company specific but the goal is that this community cloud is infrastructure that is, again, some of it has been free, the colocation place is hosted by HostDime which gives us access for free and we work with open source. So it's just really professionals getting together. There's absolutely no conflict at all. Yeah, the entire motivation was just educational. I mean, actually like it's not even majority red hat, although we did have that awesome majority red hat event where they explained like the history of OpenStack. It is, you know, people working in DevOps in other locations or people that are just interested in the technology. Yeah, and most employers like having their folks attend because it's really free training. Yep. So that's why HostDime is pretty much giving us a quarter cab which if you add up through the number of years we've said it's significant money. Yeah, very valid. Actually, it's interesting, I'd like to add to that. So I'd been at HostDime at the time and a lot of the motivation for, you know, well, let's host this cab was, hey, if we host this cab and we hang out with all these people that know everything and we get all of this completely free education and experience, people will just shower you with knowledge. It's amazing. So I thought that was exceptionally valuable and if anything, I think we came out on top getting that value was very, very interesting. And of course it's collaboration and it's a best effort and obviously fun should be part of the mix because a lot of things happen if you don't have, you know, take it like heart elite and it just gets pretty sad. Any other questions? Thank you for the question. Thank you. Yeah. It really varies, like we mentioned, we have about 300 members signed up and some are just, how do I call it, scrollers or they just like to see what we do if they don't come and join the meetings. We've had, when we have folks come and visit us, then we have larger meetings but we get to about 30, max, 40 people. Sometimes we have meetings of 10 or 12 and we have virtual meetings as well. Yeah, we've found the largest turnouts is when we're doing really cool stuff like actually installing OpenSec. That's when everyone shows up. Yeah, waiting for the network installation wasn't as popular and the bi-weekly, I believe you were referring to an interest in rapid iteration on the community cloud. I think we have more infrequent though educational experiences. Docs and stuff, thank you. Any other questions? Because we had used other calls before and this seemed like another way to do another installer. So, and it was really, you know, who we had available to come and help. Honestly, I'd actually like to mention, so we had played with OpenStack Ansible because we were all like Ansible is the future here. Yeah, we pretty much, we played around with like all the different OpenStack solutions. I think we've messed with crowbar, OpenStack Ansible, and TripleO. Right now we're playing with TripleO. And part of that is because a lot of the technologies it's moving towards is a lot of what the focus of our group is, so. Containers. Yeah, Docker containers, Ansible. There's, Kubernetes on OpenStack has been a big thing too. That TripleO has been getting a lot more integration on. So there's just a lot of technologies that have a lot of synergy that everyone seems to be interested in. And I mean, to be honest, when Luke had pitched TripleO, I was like, that actually sounds really cool because I'm very interested in the heat project and ironic. So I mean, that's TripleO right there. Yeah. Which is very interesting. And Ansible. And Ansible, yes. But the, I was really looking forward to seeing that bare metal provisioning. It's very interesting. Thank you. I'm actually curious actually. Is anybody, I guess, raised hands if anyone's interested at all or is experiencing currently making their own OpenStack cloud outside of like a company purpose? What's your use case? So people will buy more services from web app and Susan and others. So we can sell more services ourselves. And we do people we like. Yeah. Because it's, everything is self-made. Awesome. So this is a, sorry because you don't have a mic, but this is a group from Norway that's getting together basically a community of cloud enthusiasts to show that this can happen and that over in the infrastructure is the thing. So I think we have... No, that's awesome. That's exactly what I was thinking of hearing. Very cool. Yeah. Thank you. If you want to visit Disneyland, Disney World, we can definitely talk. Yeah. If anyone is interested in either joining our operation or seeding or starting one of their own or collaborating with us on ours with theirs because you can do multiple clouds and do Federation. I definitely think it would be interesting or at the very least educational to have that experience. So please, please reach out if that is of interest to you. Any other questions? Thank you very much for coming. Yeah, have a great day at summer, guys. Thank you. Thank you.