Hello, everybody. Welcome. This is the talk on how Walmart is building a successful open source culture. I'm Andrew Mitry. This is Megan Rosetti. Hello. And we want to share a little bit about our journey at Walmart and building actually introducing and changing an open source culture there over the past few years. Let me start off with what is Walmart? So I know that we're here in Spain, in Barcelona, and there's no Walmart here, at least not yet, but now I'm not going to start any rumors, but I get in trouble. But Walmart is actually the largest company in the world. We are Fortune One. We do about a half trillion a year in sales. It was started in 1962 by Sam Walton. Today we have over 11,500 stores under 72 different banners. So like for the European crowd, as the UK is a Walmart banner, we're in 28 countries and we have e-commerce sites in 11 countries. We have over 100 distribution centers worldwide. And we have over 2 million employees. So we are actually, I think we just moved up to number two, second largest employer in the world after the U.S. military. We just actually passed the Chinese military in terms of the size of an employer. So pretty big employee base. And we have about 80 million monthly visitors to Walmart.com. Just to kind of give you a sense of the scale and size of operation that we're running at Walmart. Part of our culture is that each location is part of the larger community. We spend a lot of time at the culture of our employees, motivation to do the best for your peers and work with the best people. And the reason why we bring this up here, right, is this actually helped us translate into the open source culture. It was almost a natural fit as we started to kind of bring these open source ideals into Walmart. And this is actually our team in our Virginia location. So it's part of our Walmart team. Yeah. So Walmart has a technology presence in northern Virginia, in Bentonville, Arkansas, where headquarters is, in the valley under the Walmart labs, in Silicon Valley under the Walmart labs banner, in Bangalore and in Leeds, UK, as well as quite a bit of remote. So next, talk about a little bit about how we've embraced our open source journey. And so at Walmart, pretty much everything starts with a proof of concept. Small engineering or DevOps team. A lot of times we're, you know, reusing or repurposing hardware. And we have this desire to do something new and potentially beneficial. And to convince management, it's worthy. This is kind of where things kind of incubated and started with OpenStack and with other open source projects at Walmart. This initially started about four years ago at Walmart and the POC was successful. It allowed a wider audience for testing. We made a decision to use OpenStack in production, increased our hardware footprint, you know, productized our deployments and configurations. And we made that decision to run all of our e-commerce applications on OpenStack. And so to give you a little bit of context, today 100% of our e-commerce runs on OpenStack. And what we've now been focusing is actually transitioning our retail back office workloads onto OpenStack as well. A lot of the net new workloads are moving onto OpenStack, not just the traditional web app, right? But a lot of data intensive applications and traditional back office applications as they mature, as they're rewritten, as we bring in new ones, we are moving those onto OpenStack as well. It has become the de facto cloud platform within Walmart. Part of the journey was that this was also management driven, like, you know, incorporating that open source culture throughout the company, right? So it had buy in from the top as well as enthusiasm from the ground up. We've actually recently started to work in, so a lot of larger companies that have been around for a while have awards for patents and other innovation. We actually were able to bring, having company awards at the same level as patents and recognition around open source contributions, right? And so we reward that, we're making that part of goals and really trying to make it so that this is part of, not just something you do in your spare time, but part of your day job at Walmart. And so we also have created an internal community where we provide support for those who work on open source projects, even if it wasn't directly related to their day to day work. And I think having it as part of the overall technology strategy and that coming down from both our CTO and CIO's office and cascading down in goals has been a big help in getting maybe even managers that weren't as familiar with open source saying, hey, well, this is now part of my goal structure. How can I incorporate this into what my team is doing? So certainly it's something we have found is it cannot be 100% management driven. You have to have, if you want to forward, you have to have your teams on board as well. And that has been a large part of our journey. So we've adopted somewhat of a dual strategy, working with both management and also with teams to move this culture forward and make certain that everybody is embracing it. We're really finding that teams are adopting the open source culture. They're getting excited about it. They're getting excited about the work they're doing, getting excited about the products that they're able to upstream back into the community. We've made this a part of our onboarding. So as we bring in new team members, they go through how to contribute training. They go through, here are different projects, different working groups that you might be interested in and here are people within the company that can act as points of contact to help answer questions and help you get over some of those initial hurdles. We include the work within the community that we're doing as part of our day-to-day agile planning. It is part of the workload. So for example, the operations team has their backlog rooming and their agile planning and the projects and the works and the bug fixes and the working groups, whatever that team may be working on at that point and individuals within that team, it is all part of that process. The manager within that team approves and knows what workloads are, what time is being focused on, what workloads and the team has complete transparency into what each other are doing as well, which has been a big win without question. We have also added goals not just on the management level, but also on the personnel level as well. So part of individuals' quarterly goals have open source in them too. And we are seeing an excitement growing, which is really fantastic to see as we're moving forward within this. We're seeing excitement within the teams and we're also seeing how people are getting excited about, hey, I just submitted my first bug fix. Hey, I just got this upstreamed. I were just about ready to release this project and have it completely open source. And that's what's getting really exciting for us. So I think the proof is actually in the pudding. So maybe we talk a little bit about how we've actually been contributing back to open source over the past a few years. So in the past year, our team has more than doubled their open stack reviews and increased their number of commits seventh fold. We have core contributors on OpenStack Ansible and OpenStack Watcher. And so we're providing a lot of feedback in the areas as we're trying to improve what we're doing in OpenStack. Another area that actually one of our parallel teams has invested a ton is that we actually run, I think, one of the largest, if not the largest, puppet infrastructures in the world. And with about 49 million total resources in puppet that are managed through puppet. And we're also even adding Windows nodes and whatnot. Something else that we're doing is we're actually contributing new open source projects. So in the past year, we've open sourced two large projects. One is OneOps. It's our application life cycle management platform. It was a startup that we had bought a few years ago. We took their technology, we improved it, and we've now open sourced it. It's up on GitHub. And if you guys have any questions about that, we can talk about that offline after. Feel free to hit me up. The other one that we just open sourced in the past couple of months is Electrode. It's a universal platform for React and Node that's been getting a lot of good reaction in the community and positive buzz. And I think they did some great presentations over at Osconn in the UK if you want to catch the videos online. Some of the other things that we've been doing is both internal and now external tech blogs regarding the work the teams are producing. And we formed an internal open source team. So I think this before was called a council. We renamed it to a team. And I think we want to make it, one of our goals is make it as seamless as possible and being able to push open source out the door, not some, we do review, we do try to make sure the appropriate due diligence is done around making sure you're using the right open source licenses and whatnot. Not saying that there's no review, but we try to make that as quick and as lightweight for our developers so that they can be encouraged to contribute code outside of Walmart. So this is actually a photo of our team that went to the Austin Summit. And something we certainly found is needing and wanting to support our individual teams. So we have several different locations working on multiple projects. And it is great to be able to bring people together and support them not only at summits but at different conferences. We host meetups presenting at open stack days. Wherever the information really seems to flow and to fit, whether it's something that we have open sourced, whether it's a project that we're working on, but really coming together, ensuring that we have people attending the operators mid-summit cycles, which I know will be changing, but really making sure that we have that support throughout for our teams. So part of this is we've talked about like, okay, we're doing this open source culture, but maybe some of your, some of you are asking or maybe your management is asking like, you know, what do I get for this? Right? Like, well, what is the benefit? There's a lot of benefits to open source. We're big believers, but just want to talk a little bit about the transformation of Walmart because of open source and, you know, some stats that we've released. We run over 170k cores on open stack. That's actually be growing quite a bit soon. 100k of monthly one ops auto repair. So one ops is that application platform. It's basically self healing. The VM is replacing them every month. You know, whenever it needs to move a workload or repair a workload or there's an issue with the VM. We have over 40,000 deployments in our platform. We support about 3000 different applications right now on top of cloud running through our one ops platform. And we take, we package 60 different open source products that we pull in, many of which we contribute back to and make available through our one ops platform that we push out and they can deploy on top of our cloud with relative ease. So this is allowed our development community to become much more agile, work within our governance structures and basically get things out the door quicker, which is what matters. So we're very excited about the journey that we've been taking. This past year, we've seen a lot afford movement, which is fantastic. We're excited about what we've accomplished, but we are not done. We have only just started and we have some pretty, pretty big future goals that we will certainly accomplish. We are working on adding open source to our managerial or yearly reviews for managers. Again, it's one of our key requirements that both management and teams are really involved in changing to this open source culture. And with that, we need that feedback and that review. We've added it into quarterly goals for team members, but we should be able to review managers to make certain that they are upholding those initiatives and helping those teams to move forward as well. We are working diligently to create as much transparency as we possibly can with our open source culture in and amongst different teams. We're working, we're not quite there, but we are working on complete transparency throughout the company to the point of everybody goes through different peaks with work. And if somebody is pulled off of a project to be able to bring in other people from different teams to step in and maybe they've gotten stuck on a bug fix, so they're not quite certain where to go with that. So to be able to tap into other teams and say, hey, does anybody know where I might be able to go with this or how we might be able to resolve that and have that transparency not just with one team, but throughout our cloud environments. And then also being able to have an easy way for the company overall to take a look at what we're doing. So it's making it as seamless as possible and that's part of including it in the day-to-day work, but then bubbling that up into one specific area in which the entire company, if they so choose, can certainly go and take a look at the individual projects, products, work groups, whatever people might be working on at that time. I'm really embracing continuing to embrace the open source first mentality throughout our development and our review process. And that is something that's continually put forward and something that we are constantly going back to. And that's great. Have you looked at open source as well? What have you reviewed on that end? What are your recommendations? Where do you want to go with those things? Looking at growing our participation, we want to make it as diverse as possible, really pull in people from all areas and not just, okay, your day-to-day work is on Keystone, so you'll work on the Keystone project and have that be it. We've found some great success with some of our development teams and our operators working on projects that they had not much knowledge with, not a lot of familiarity with. And we found that some of them got really excited. I'm interested in X. Okay, we'll give you time to work on that. And then they have brought that back into the company to say, hey, we could look at doing deployments differently. We could do automation this way. And that's been pretty successful. But we want to keep building that. We want to keep growing that. Continuing to build out our participation, not only in summits, but open stack days, open source projects with Puppet, with other open source initiatives, releasing projects that are created internally and releasing them open source-wise. And that all goes into the irresistible developer experience, which is the overall ultimate goal. All of this leads up to making it easier and not harder for people within the company to not only embrace this culture, get excited about this culture, but also be able to move things forward rather seamlessly within it. Okay, so some of the challenges. There's never, nothing ever goes as smoothly as the proof of concept seems to be. Some of the challenges we've encountered, choosing the name of a project, easier said than done. You laugh, but it's actually pretty hard, especially when it's going public, right? So yeah. Research, research. Coordinating across not only teams, but also different work zones as well, especially teams that are exact opposite on work zones. Being flexible, you put together one process and it works for one team. That does not mean it is going to work for every single team in every single location. What's your end goal? Focus on your end goal. The process getting to it doesn't have to be cookie cutter for every single step of that. We're still working on that a bit. And consistency. Again, keep that end goal in mind. The process may need to change. You may need to be flexible on certain things within it, but what is your end goal? What do you want to get to at the end of the day? Again, accepting that the process may change, but not the outcome. Embracing the culture change. Much, much easier to put that on a slide and to say that than to actually have that happen. You have to be an advocate within your company and to really help push that forward. Really keep going back to it and talk to people about your wins. What's working? But be honest about what isn't working as well. Not everything is absolutely rosy. You're going to hit some bumps along the way and that's fine. Just means that you need to readjust a little bit. For us, a key part, and this has been both a challenge and an opportunity, is making the open source work part of the day-to-day responsibilities. So when the ops team is planning out their work for their sprint, they're reviewing their backlog, this is part of it. And it's not something that's shelved. It's not something that is, well, you can work on that after hours. No, this is part of your nine-to-five. This is something that we will schedule out. And this is something that we will work and follow through on. We're still working on that one, still going through that. Reviewing teams. Making sure that there's a clear understanding of the complexity. We've all delved into projects before thinking, okay, great, I'll have this bug fixed out. Yeah, a couple of hours, I should be good. I should be done. And it takes much longer than that. So understanding, readjusting as you need to. Diverse community involvement. Again, we want to continue to grow that. We've seen that that's a big opportunity for us. And then also vendor agendas has been, I would say, both a challenge and an opportunity. So sometimes I think one of the benefits we bring is a specific to the open source community, to the open stack community. As an operator, as we're coming in with maybe a little bit more neutral of an agenda when we propose items and bring bull prints in, we have struggled in the past where certain vendors might not want a feature implemented because it conflicts with their commercial add-on offering. And so just navigating that. Actually, that's one of the things where I encourage all operators, regardless of if you're a vendor in a different space, but as an operator of open stack, to participate more in the operator summits and the design session feedbacks and the various feedback. I know that the cores that we bring to the table are extremely valued by the community because they are kind of in that more neutral place and bring a lot of weight and getting things done. I think open stack has matured a lot in that space, but I think the voice of the operator is probably still, there's still opportunity there for more of it to be heard, so that's a really good place to participate and give feedback in those design sessions and as decisions are being made, even submit blueprints to participate in reviews, what not, because that opinion of an operator is valued very highly and sometimes it's not always there. And that's also an opportunity with the product work group as well, putting in user stories. There are many different avenues that people can look at and take to really make sure that their, quite frankly, their input is heard and received. And I actually think that's one of the wonderful things about open stack is that we can provide that feedback, right? It's not some closed loop where somebody's off developing their roadmap and developing their feature set and you don't have an opportunity to participate. We do have that opportunity. It's just a change in how things are done, right? Before you were dealing with a vendor and you'd go and say, I want this and somebody would go lobby for you inside the company and get on a roadmap and whatnot. No, now we have an opportunity to be part of that design process, part of what's going on. So as operators, that's a challenge for all of us is, hey, if you want open stack to continuously improve and get better and do more things for your organization, step up and participate and, hey, you know, and it doesn't always have to be with actually writing code. There's many ways to participate in the open stack community. Both within the user committee and within the technical community, lots of different avenues. We're exploring them. So some of our key takeaways, building an open source culture, not something that happens overnight. Kind of pick your battles a little bit. Start with some small wins and promote. Promote the good things that are happening. Promote the good things that you are doing. You may not have everybody on board at once and that's fine. Start with the teams that are on board and show what works. Show where you can have your wins. Don't focus your time on trying to bring everybody on the same page all at once because it's going to get a little overwhelming. Focus on the teams. Focus on the places that you know you can move forward and then use those wins to show how much can be done. We're not exactly where we want to be, but in a year we've made some really great strides and we are able to use those wins to keep moving forward and to keep showing that this is working. This is successful. It's still an iterative process. We're getting there, but we can still use that. Trust your engineers. Trust them. If they say that they're working on a project and that's what they're focused on, give them that room. We'll let them work on that. It may not be something that directly relates to absolutely everything they're doing on a day-to-day basis, but one of the things we have found is some very unexpected wins from that. It's allowed some people to think in different terms and to bring things back into the company that we weren't originally thinking of. We weren't originally pursuing. Then of course be flexible enough to take that and plug it in where you can. Challenge is an opportunity. Don't be afraid of failure. Things are going to happen. You're going to start down a path and it is going to be great. Then you're going to take that and okay, I've got this process. It works so well. This is fantastic. You go to apply it to another team and it completely falls apart. That's fine. Not a problem. Work with that team. Include them on what you're doing. The minute that they think something is being told to them, this is how you're going to do it. This is where you're going to start and this is how you're going to end. You will get pushback on it. Again, that's part of trusting your engineers. Include them in the process. What do they want to see? Teams take on a lot of different responsibilities. Include them in that. Make certain to seek their input. Nothing ventured, nothing gained. That's another part of the failure side. If you don't try it, you don't know if it does work or if it will fail. Go for it. Then just another one to throw out. Brick walls just mean there's another avenue to take. It doesn't mean that it's a stopping point. Just means that you need to catch a breath, look everything over again, and go down a different path. That runs us through the slides. We do have a booth at A37. We want to open it up for any questions that anybody has in about the 10 or so minutes that we have left. If you guys would see, there's one mic there. We'll be sure to repeat questions, too. There we go. Good afternoon. Thank you for the talk. This is extremely beneficial. My question, you talked a lot about how to fix the culture and how to bring open source culture in. I'm going to take a wild guess and say that everything you guys produce is open source. What are some tips and tricks you guys can possibly provide on how to balance that process of what's closed source versus what's open source? How are those decisions made and then how is it implemented? Sure. So not everything is, there is definitely quite a bit of proprietary stuff. We work on a team that is thankfully open source focused, and that's pretty clear because we work on open stacks. Pretty much everything that powers our cloud infrastructure is open source, but there are plenty of things that are proprietary that we don't. I wouldn't say that we have at least, so as Megan discussed, we're kind of, I would say, relatively new in our journey. I mean, we have a few years in, but there's still a lot of growth that we're doing. Right now, we have, I think, a pretty simple process in that evaluation. One is, it's actually a lot of it is left to manager discretion and leadership. So in the end, if it's a net new open source project, we do require VP sign off. And so we would hope that between the manager discretion and VP sign off, whether the technology is core to our critical retail business and e-commerce business, or is something that's part of a larger ecosystem in the nut core. And whether we want to open source that or not is going to be up to those kind of chains. And also, what's the benefit? When we open source one ops electrode, we want to build a community around it. We are excited to share. And it's not something specific to our business use cases, right? It's something that we're using as a whole within our technology ecosystem and would be useful in a lot of other technology ecosystems. So it's not necessarily mature, but I don't know that we've had a lot of challenges. It seems like a lot of what we've been open sourcing are natural fit and existing open source ecosystems, right? We're not necessarily open sourcing a bunch of tools around proprietary technologies, right? So it seems that they do tend to bunch together a little bit. Not to say, I'm sure as we go through this maturity process, we're going to come across some of those questions, but we just haven't had a ton of them so far. Sorry, it couldn't be more helpful than that. Well, and then on the other side, too, is looking at what you're bringing in open source wives and being able to cloud moves very, very quickly. And what was there six months ago may have completely changed by this point. And encouraging teams not to be afraid to bring that into the review process, whether it's a new project or new build out wherever it might stand, to bring it in and put that in as part of the review process. Why does that look like that would fit now and at this point? It's not a guarantee that it's going to be chosen, but it should be submitted. So actually into that point, one of the things that we do do is we encourage our entire team to contribute, not just necessarily developers that are bringing in the product, but whether it's a DevOps team or we still have some various traditional operations team, we still encourage them to contribute, whether it be bug fixes or documentation or whatnot. So it's a cross org function that we try to bring them back into the ecosystem, so we keep that ecosystem healthy, not just about the code. And even to take it a step further, the business side. So on the active user groups, enterprise workgroup, reference architecture, really working kind of all different facets within the community, not focusing on one end. That was a great question. Thank you. Yes. Hi, good afternoon. So what are the positive impacts or benefits you have noticed on employee development or employee growth by embracing this open source culture? Is this something different processes in how you work with different people, collaboration? What are the top things that you can highlight that you have noticed? So I think there's a few things there. One, it definitely has helped bring in quite a bit of talent that is focused around open source. I mean, actually, Megan and I were both attracted to Walmart because of what they were already doing in open source. It's helped us with retention on several notes as part of the culture change actually even in the past year that I've been there. As I have discussions with management and engineers sometimes helping them pivot and see how what they're doing could be contributed back creates excitement in those engineering teams. And hey, I'm part of a larger community. I'm not just doing this little thing inside this big company that nobody notices. I'm now contributing this code back. I'm reviewing other people's code. I'm in weekly meetings. I'm part of this greater thing than what's just inside because we don't have 10 engineers working on every single project. A lot of these might be small. As big as Walmart is, we still have sometimes only one person working on that, one engineer. And they can go be, but let's say it's open stack Ansible for example. There's still like 10 other engineers working on open stack Ansible in the larger community. And they have now become part of that team in contributing and doing things. And so actually I think it's helped quite a bit in our retention as we've pivoted to say like, hey, we encourage this and we reward this. And they're like, well, I want to be part of a company that has that kind of culture. And even we have an engineer, we're going to be open sourcing a new project soon around IP address management and that type of stuff. And it's a small project, but he got excited. He did a lot of work and investment in doing that with Ansible and managing it. And now he's like, in the previous world, I would do all that work and it would be used just at Walmart. Now he's like, hey, knocking on the door. Can I open source this and do it and share it with the world? And we're like, yeah, that's awesome. And not only that, we're going to recognize you for doing it. And so overnight sometimes I feel like those benefits are even larger than a lot of the more traditional benefits trying to retain employees. It creates excitement in what they're doing and being able to share it and talk about it. And have other people even contribute and make pull requests and use that code outside the company. Any other questions? Sorry. Did you have any fights with your legal guys? Yes. So to be honest, I would say more of the fights were in the middle. We had, I think, good buy-in at the top, a lot of interest at the bottom. But so there are there are a few people that didn't get it. I don't know that it was really fights, but I just didn't understand it. And so the initial answers from them when their engineers would go up and be like, can I open source something? The initial answer was no. And we're being frank. And then we would find out about it and be like, can we talk to you, Mr. and Mrs. Manager? This is why we want them to do what they're doing and why you should encourage it. And to be honest, as far as I know, every time we've actually had, it's really education, right? Every time we've educated somebody on this topic, right? We probably should do some more org-wide initiatives around education, right? But every time we've done at least one-on-one so far, or part of our larger open source team have done that, the responses always ended up positive. It's never been like a long-term quote-unquote fight where it got shut down. It was almost always we educate. They're like, oh, that's awesome. Oh, I get it. Okay, let's do it. But it was usually due to some misconception around open source.  And reality is that's not true. I had somebody the other day tell me that NoSQL is not production ready. And I'm like, and what world are you living that NoSQL, Cassandra, and whatnot databases are not production ready? There are a lot of people running it in production, right? So there's still a lot of that myths running around that maybe the vendors and others propagate, or maybe those loyal to those technologies, that really it's just an education thing that you have to work around, which I feel is like with anything new, right? How do you guys keep things coordinated across different offices and different groups so that you don't end up competing versus like, so you use open-stack answer. You also use puppet. They're not necessarily conflicting, but they certainly can be depending on what you're doing with them. How do you make sure that you don't have two teams doing two different things and then all of a sudden you find out you have both of these? I would say that that at times is still a struggle. Yeah, I think so we definitely still have some of that. We haven't fully solved that problem. I think we have a couple groups that like now meet globally across the organization to kind of review from an architecture engineering standpoint what are recommended, what are best practices. I personally like to take more of evangelism approach where we're sharing what we're doing. We're sharing all the teams. That's kind of where the transparency comes and everybody should be sharing what they're doing. Maybe selling is too strong a word, but like I like that evangelism where like say, tell the world about what you're doing and hopefully then it'll be like, well, actually what you're doing in Ansible might work better than what you're doing in puppet or vice versa, right? And let's address the problem that way. And so that's how most of those conversations are happening. Some of the things that we're actually working on putting on is several company-wide cloud days, kind of internal events where we also evangelize so people can get on board with all the different projects that are happening and maybe hopefully get some cross or participation on a lot of those projects. Looking for more participation outside of just the direct, quite frankly, cloud teams or team we're responsible for supporting the project. Yeah. Exactly. Any other questions? All right. Well, we're just about at time. So that is perfect. Thank you guys very much for your time. Appreciate it.


What's going on everybody got a Kyle and Sean here relating sports cards from one box of 2022 23 Merlin soccer This one is for Dustin G. Good luck Dustin. Let's see what we got after this. I got a bow and jumbo for Simon Do that next This is this is in This is in What are we doing? That's like Bernhardt Yeah, no, uh, no match ball this time. No match ball this time See what we got there's Enzo Got a refractor goiri rookie. There's a auto. It's gonna be Gabriel Bata stuta on the out Bata stuta on the Sorcerers auto that one does have a little the ding in the corner We're gonna have to send a box with that Dustin Sorry about that my man. That is a pretty good ding there in the corner That is a Bata stuta on these Sorcerers insert auto Send a box there sir. Sorry about that my man Else we got in here Some nice color for you huga ecotique. There's a Arda on the rookie base and that one is Leventoski Merlin Masters Refractor or Yarsabal got two clubs in her hand. There's a green rookie to 99 Samuel Elling jr. For you Ventus there's a Andres Sheldra Rookie refractor. It's a Aegis alchemy Harry Kool Or Liverpool the red shimmer that one's gonna be rookie at least Ben Segear for Monaco Rookie red shimmer to 299 and next up guys I just have a Bowman jumbo for Simon can fit in a little bit more You guys want to get some personas going Leroy Sonne refractor a few more if anybody wants to get one going There's a Valentin Carboni rookie Merlin refractor or one per box Kobe my new under 21 rookie for man you Man you my new fracter Bruno Fernandez For man you as well.  Dustin that'll do it for your one box of Merlin We are sending a box with that damage about this to to auto We'll get it right out to you. Thank you Dustin


Welcome to another demo video of the Red Hat OpenShift Container Platform. My name is Philip Lamb and I'm the DevOps Solutions Architect for Red Hat's Global Partners and Alliances ISV team. Today, I'd like to demonstrate just how easy it is to configure a multi-node couch-based cluster and deploy an app that consumes tweets from Twitter with the hashtag, vacation. For those of you unfamiliar with couch-based, it is a fully-featured, multi-service, no-sequel database. In this video, we're going to first assume that you have already installed the operator and have created a project, but not done anything else yet. We will deploy a two-node couch-based cluster, expose the couch-based admin UI, create a tweets bucket with two replicas, scale the cluster to four nodes, deploy our real-time Twitter ingestion application, its API service and front-end UI, and finally create an ingestion service to pull tweets from Twitter in order to display them on our front-end UI. Let's get started. Here we are in the OpenShift container platform console view. We're going to first verify that our operator has been installed correctly. I did this previous to this video, so everything is running correctly. I also created an empty project called Twitter that we're going to use for the rest of this video. Now that we've verified the operator is running, the next step is going to be to create a secret in our project, Twitter. We will create from YAML. I have some YAML that I made earlier that I'm just going to paste in. The name of our secret is CBExampleOff, and just a random username and password. We'll create. Now that's created. We'll go over and create a couch-based cluster. We're in the installed operators, and now we click on couch-based cluster on the right. Create couch-based cluster, and we're going to use YAML view. Now there are a few small changes to this that are in the notes, mainly around the names of the images. I'm just going to paste those in directly. A few things that we're doing are to change the size of the number of servers from 3 to 2. We're going to get rid of search, eventing, and analytics. We don't need those for right now, and then we're going to change auto-failover timeout to 10 seconds. We click create, and now we'll just wait a few minutes for that to spin up. Now we see that the cluster has spun up, and it is available and balanced. It currently has two workers associated with it. Now we look at the resources tab. You can see the services and pods that have been created for the cluster. Now that we've got the CB Example UI service, we're going to expose the counter-paste admin by creating a route. We'll click on routes, and then create. The name of the service we're going to use is CB Example UI. The service, CB Example UI, and the target port 8091. We'll create that and give that just a few minutes to spin up. Now that our route has been created successfully, we're going to open it up. Take a look at the admin UI. The username and password that I've chosen are a very secure administrator password combo. Now we can see we currently have two servers up and running, and no buckets. Let's get a bucket created. We'll go back to installed operators, and then couch-based bucket. Create couch-based bucket. Then we're going to do this from the YAML view. Now I've got some that I created earlier that we're just going to paste in. You can see we've got a number of replicas set to two, which with the current two-node cluster is not going to be satisfiable. We'll create that and wait for it to be created. Hop over to the web console and take a look at the buckets. You see down here warning additional active servers required to provide the desired number of replicas. We made a mistake in the previous step on purpose. We need four nodes to support the redundancy that we want, so two replicas. In order to do that, we'll go back to our console and look at the cluster. We'll edit the YAML directly here. We are looking to increase the number of servers from two to four. We'll just save that. Take a look at our details and give this a moment to increase. Now we have four members. We can take a look at our resources here. We notice that there are not one, not two, not three, but four CV example pods that are running. If we look at the console, we can see that both we've had this successful rebalance and we've got everything satisfied, so we are ready to move on to the next step. That's going to be to deploy a Twitter app. The goal next is to deploy an application that will ingest tweets in real-time from Twitter. We've got some OC console commands to run. I'm logged in. We're going to create a new app using some copy and pasted information here. We're waiting on this to build. We can watch this build by going to build Twitter API. We'll give that a few minutes to finish. Our build is complete. We also have a service that's been created as a part of that. We need to expose the routes, the API service. We're going to follow the same steps as we did for the couch-based service by going to networking, routes, then create a route. We're going to call this route Twitter API. The service we're going to look at is Twitter API and the target port 8080 create. We've got this spinning up. I will click on it. One thing we need to do is add slash tweet count to the URL to test the API. Make sure it's working. We currently have zero tweets. That is the correct amount to have. Now we want to deploy our UI. This command just points to an existing container image on Docker Hub. OCP is going to deploy it and create a service for us. I'll just paste this in. Once this is created, we can see that we have a new service created called Twitter UI. We want to create a route called Twitter UI using the same steps as our previous routes. Create Twitter UI. The service is this new Twitter UI service that we had created. We want that to run on port 5000. Create. One thing that we're going to want to do, I'm going to open this up in a new tab. We're going to want the URL for our API. I'm going to copy that. Then on the Twitter UI itself, we need to add API base equal to the actual API. That way we know that we're actually pulling from the right source. The final step is to deploy the tweet ingester. We don't need to create any routes for that service because it only communicates internally with Couchbase. I have a new app, the code for which I'm going to copy paste. We'll wait for that build to complete. We should shortly start to see tweets flowing into our tweets bucket and then see the Twitter UI presenting data. This video is being recorded on a Tuesday. Not a lot of people are talking about vacation stuff. I'm going to go ahead and just paste in a tweet myself. Looking forward to a potential vacation at Starbase Texas sometime in the near future with my buddy Elon. I'll click tweet and there you have it. We got a bonus one too. To recap, today we deployed a two-node Couchbase cluster. We exposed the Couchbase admin UI. We created a tweets bucket with two replicas and then scaled the cluster to four nodes. We deployed our real-time Twitter ingestion application, its API service, as well as its front-end UI. And finally, we created an ingestion service to pull tweets from Twitter with the hashtag vacation in order to display them on our front-end UI. Thank you for watching this demo video. We'll create others in the future. See you then.


This portrait of a female protester buckling her helmet in Kiev is striking, but not unusual. Women have played a key role in this ongoing Ukrainian uprising. This image is especially meaningful this week, as International Women's Day approaches on Saturday. But here's the irony. Women's empowered status in Ukraine today has unexpected roots in Soviet times. That's right. Women of the former Soviet Union used International Women's Day back in 1913 and 1917 as a way to protest World War I and government corruption. In fact, the Russian Tsar abdicated four days after women organized a bread and peace strike in 1917. The next post-Zar government gave women the right to vote. Decades later, when the Soviet Union split up and Ukraine gained independence, many women even complained that their rights had actually deteriorated due to the disappearance of Soviet policies of universal daycare and the expectation that all women should have market jobs. It's a reminder that the struggles of this woman, of all women, are shared, even among folks who are otherwise enemies. That progress is uneven and that eventually success will require constant vigilance.


Hello earth citizens in this video I will show you a 10-minute routine to do for your lower body joints when I talk about lower body joints It means your joints from your waist Downward, so we're gonna work your waist your hip area Your knees your ankles and even your toes, so let's get started first bring your feet shoulder-width apart Toes pointing forward never outward always pointing forward to contain your energy in let's start with a light Warmup in our waist first push your waist to the right side Feel the stretch right here, and now the other side push your hip out to the side feel the stretch and now point your tailbone back and forward From there make a big circle Big circle try to push your waist and hips To every angle of the circle as much as you can the bigger your circle the better your stretch will be Let's do five times one side five times the other side one now the other way big circles One make sure you're moving your waist and hips not just your shoulders your waist and hips to I return sides to side Great and stop bring your legs together lift your right leg first And let's make circles rotate your hips Make sure you can feel your hips rotating right here your hip joint Let's do five on each side one Two Three five now same leg other direction one Two Three Four it's kind of a balance up to Five okay great now switch lift your left leg and rotate the hip joint of your left leg One feel your hip joint two Three five now the other direction if it's hard to balance You can bring your arms out to the side or you can touch the wall or touch something for support Okay, the important thing is is that all your attention is on your hips not on your balance All right same leg other direction one two Three and stop now let's go to the knees bring your legs together Hands on your knees and rotate clockwise to the right side first so rotate clockwise ten times one two three five feel your knees six seven eight nine Ten now other direction counterclockwise one feel your knees maybe you can hear your knees crackling I hear my knees crackling three four five six seven eight nine Ten now knees outward so keep your legs together rotate your knees out one two three Four feel your knees five six seven eight nine Ten now inward one two three six Seven and ten return shake your legs Now next we're gonna do our ankles. So first bring your left foot forward So you can either do this way or to the side. I'll just do forward. Yeah, left foot forward Right foot back lift your heel So your heel is off the ground and then from here lean your body way slightly forward So I'll show you from the side. So you want to lift that heel and then Lean your body a little bit forward. So your body weight is on this leg. Okay, but not too much Just a little bit now from there rotate your ankle Keep the ball of your foot on the floor rotate the ankle Let's do ten times each direction one two three Four here you might hear a snap crackle pop as well five six seven eight nine Ten same foot other direction rotate the other way one two three four five six seven eight nine Ten now you're gonna drop that heel down and now I'll show it from the front so you can see but stop you don't have to keep moving around Okay, so stop moving around with me. I'm just shape I'm just changing the angle so you can see my posture a little bit better So left foot forward still and now roll that foot to the outside roll that foot to the outside and lean your body weight drop your arms lean your body weight So you can feel that subtle push down on the outside of your foot You'll feel the stretch going all the way up the outside of your leg. Stay here. Relax five seconds five four three two one Return shake shake shake Great job now the other foot Right foot forward again. You don't have to shift with me. Okay. Just stay in one place I'm just moving to show you different angles Right foot forward lift your right heel and then Rotate let's do ten times each way one two three four five six seven eight nine ten same foot other direction one two three four five six seven eight nine Ten now drop the heel down Lean your foot to the outside drop your arms lean your body weight forward push Gently against the outside of your foot five seconds one two three four five Okay, return shake shake shake shake shake shake both of your legs shake shake shake And return to center How do you feel? Can you feel your bottom half of your body being stretched out? Of course if you live a sedentary lifestyle and you have a lot of tension in your joints Especially from your waist down you're gonna need more than 10 minutes to loosen up all those places So if you feel like you're still stiff then feel free to re-watch this and go through this routine again The more you repeat the more you practice the more limber and flexible your joints will become You did a great job To experience a full one-hour brain education based class. Please visit a local body and brain yoga studio near you