>> (Narrator) Live from Vancouver, Canada, it's The Cube, covering OpenStack Summit North America 2018, brought to you by Red Hat, the OpenStack Foundation, and its Ecosystem partners. >> Welcome back, I'm Stu Miniman with my co-host John Troyer and you're watching The Cube, worldwide leader in tech coverage, and this is OpenStack Summit 2018 in Vancouver. Happy to welcome to the program, first-time guest Melvin Hillsman, who's the governance board member of OpenLab, which we got to hear about in the keynote on Monday. Thanks so much for joining us. >> Thanks for having me. >> Alright, so Melvin, we were given, start us off with a little bit about your background, what brought you to the OpenStack community, and we'll go from there. >> Sure, yeah, so my background is in Linux system administration and my getting involved in OpenStack was more or less seeing the writing on the wall as it relates to virtualization and wanting to get an early start in understanding how things would pan out over the course of some years. So I probably started OpenStack maybe three or four so years ago. I was probably later to the party than I wanted to be, but through that process, started working at Rackspace first and that's how I really got more involved into OpenStack in particular. >> Yeah, you made a comment, though. The writing on the wall for virtualization. Explained that for a sec. >> So for me, I was at a shared hosting company and we weren't virtualizin' anything. We were using traditional servers, dedicated servers, installing hundreds of customers on those servers. And so, at one point, what we started doing was we would take a dedicated server, we would create a virtual machine on it, but we would use most of the resources of that dedicated server, and so what allowed that shared hosting was to tear stuff down and recreate it, but it was very manual process and so, of course, the infrastructure service and orchestration around that OpenStack was becoming the de facto standard and way of doing it, and so I didn't want to try to learn manually, or fix something up internally, I wanted to go where OpenStack was being highly developed a lot and people working on it in their day to day jobs, which is why I went to Rackspace. >> Okay, one of the things we look at, this is a community here, so it takes people from lots of different backgrounds, and some of them do it on their spare time, some of them are paid by larger companies to participate, so to tell us about OpenLab, itself, and how your company participates there. >> Sure, so I started, well I'm at Huawei now, but I was at Rackspace and that's kind of how I got more involved in the community and there I started working on testing things above the OpenStack ecosystem, so things that people want to build on top of OpenStack and during that process Huawei reached out to me and was like hey you know you're doing a great job here, and I was like yeah I would love to come and explore more of how we can increase this activity in the community at large. And so Oakland Lab was essentially born out of that, which the OpenStack community, they deliver the OpenStack API's, and they kind of stop there, you know. Everything above that is, you do that on your own, more or less, and so also, as a chair of the user committee, again, just being more concerned about the people who are using stuff, OpenLab was able, was available to facilitate me having access to hardware and access to people who are using things outside OverStack in use cases, et cetera, where we want to test out more integrated tools working with OpenStack and different versions of OpenStack. And so that's essentially what OpenLab is-- >> So in OpenLab, projects come together and it's basically, it's an Interop, boy, in the networking world, they've had the Interop plug and plug fest for a long time, but, in essence, projects come together and you integrate them and start, you invite them in and they integrate and start to test them. Starting with, I mean, I see, for this release, Terraform and Kubernetes. >> Yeah, so a lot of people want to to use Kubernetes, right? And as an OpenStack operator you essentially, you don't really want to go and learn all the bits of Kubernetes, necessarily, and so, but you want to use Kubernetes and you want to work seamlessly with OpenStack and you want to use the API's that you're used to using with OpenStack and so we work very heavily on the external cloud provider for OpenStack, enabling Cinder V3 for containers that you're spinning up in Kubernetes, so that they have seamless integration, you don't have to try to attach your volumes, they are automatically attached. You don't have to figure out what your load balancing is going to to look like. You use Octavia, which is load balancing service for OpenStack, very tightly integrated and things, you know, as you spin things up, they work as you as you would expect and so then all the other legacy applications and all the things you're used to doing with OpenStack, you bring on Kubernetes and you essentially do things the way you've been doing them before, with just an additional layer. >> Yeah, now I wonder if you can talk a little bit about the providers and the users, you know how do they get engaged, to and give us a little flavor around those. >> Yeah, so you get engaged, you go to OpenLabtesting.org and there's two options. One, is you can test out your applications and tools, by clicking get started, you fill that out. And what's great about open lab is that we actually reach out and we talk with you, we consult with you, per se, because we have a lot of variation in hardware that's available to us and so we want to figure out the right hardware that you need in order to do the tests that you want, so that we can get the output as it relates to that integration that will, of course, educate and inform the community at large of whether or not it's working and been validated. And, again, so as a person who wants to support OpenLab or for a provider, for example, who wants to support OpenLab, you click on the support OpenLab link, you fill out a form and you tell us you know, do you want to provide more infrastructure, do you want to talk with us about how clouds are being architected, integrations are being architected, things that you're seeing in the open source use cases that may not be getting the testing that they need and you're willing to work with engineers from other companies around that, so individual testers and then companies who may bring a number of testers together around a particular use case. >> Now, you're starting to publish some of the results of Interop testing and things like that. How is open lab, how does it produce its results, is it eventually going to be producing white papers and things like that or dashboards or what's your vision there? >> Yeah, so we produce a very archaic dashboard right now, but we're working with the CNCF to, if you go to CNCF.CI, and they have a very nice dashboard that kind of shows you a number of projects and whether or not they work together. And so it's open source, so what we want to do is work with that team to figure out how do we change the logos and the git repos, to how to driving those red and green, success or failure icons that are there, but they're relevant to the test that we're doing in OpenLab, so yeah. So we definitely want to have a dashboard that's very easy to decipher what tests are failing in or passing. >> Looking forward, what kinds of projects are you most interested in getting involved? >> Right now, very much Kubernetes, of course. We're really focusing on multi architecture, again, as a result of our work with Kubernetes and driving full conformance and multi architecture. That's kind of the wheelhouse at this time. We're open for folks to give us a lot of different use cases, like we were starting to look at some edge stuff, how can we participate there, we're starting looking at FPGA's and GPU's, so a lot different, we don't have a full integration in a lot of different areas, just yet, but we are having those conversations. >> So, actually, I spent a bunch of years, when I worked on the vendor side, living in an Interrupt lab, and the most valuable things were not figuring out what worked, but what broke, so what kind of things, you know, as you're working through this, what learnings back do you share with the community, both the providers and users? Big stumbling blocks that you can help people, give a red flag, or say you know, avoid these type of things. >> Yeah, exactly what you just said. You know, what's good is some of our stuff is geographically dispersed, so we can start to talk about if, what's the latency look like? You may, within that few square miles that you're operating and doing things, it works great, but when I'm sending something across the water how, is your product still moving quickly, is the latency too bad that we can't, I can't create a container over here because it takes too long, so one example of looking at something fail as it relates to that is we're talking with Octavia folks to see, if I spin up a lot of containers am I going to therefore create a lot of load balancers and if I create a lot of load balancers I'm creating a lot of VM's, or am I creating a lot of containers or are things breaking apart, so we need to dig a little bit further to understand what is and is not working with the integrations we're currently working on and then again we're exploring GPV, GPUs just landed more or less, that was a part of the keynote as well, and so now we're talking about, well, let's do some of that testing. The software, the code, is there but is it usable? And so that's one area we want to start playing around with. >> Okay, one of the other things in the keynote's got mentioned was Zul, the CIDT tool, how's that fitting into the OpenLab? >> Yeah, we use Zul as our gating, so what's great about Zul is that you can interac6t with projects from different SCM's, so we have some projects that live in github, some that utilize Garrote, some that utilize gitlab, and Zul has applicability where it can talk to different, it can talk across these different SCM's, and if you have a patch that depends on a patch in another another pod, so a patch on one project in one SCM can depend on a patch in another project, in a different SCM, and so what's great about Zul is that you can say, hey I'm depending on th6at, so before this patch lands, check to make sure this stuff works over there, so if it succeeds there and it's a dependency then you basically confirm that succeeds there and then now I can run the test here, and it passes here as well, so you know that you can use both of those projects together again, in an integration. Does it makes sense? Hopefully I'm making it very clear, the power there with the cross SCM integration. >> Yeah, Melvin, you've had a busy week, here, at the show. Any, you know, interesting things you learned this week or something that you heard from a customer that you thought, oh boy we got to, you know, get this into our lab or a road map or, you know-- >> The ARM story, the multi architecture is, I feel like that's really taking off. We've had discussions with quite a few folks around that, so yeah, that for me, that's the next thing that I think we're really going to concentrate a little bit harder on is, again, figuring out if there are some problems, because mostly it's been just x86, but we need to start exploring what's breaking as we add more to multi architecture. >> Melvin, no shortage of new things to test and play with, and every customer always brings some unique spins on things, so appreciate you giving us the update on OpenLab, thanks so much for joining us. >> You're Welcome. Thanks for having me. >> From John Troyer, I'm Stu Miniman, thanks so much for watching The Cube. (electronic music)