Monday, March 25, 2013

Podcast: Working with OpenShift with Mark Lamourine

OpenShift is Red Hat's Platform-as-a-Service. Mark Lamourine shares his experiences working with the OpenShift Origin code from the perspective of someone outside the main engineering organization. Mark also discusses what he's currently working on around OpenShift and how interested people can get involved.


Mark's posts on Google+
OpenShift Origin and related links (IRC channels, etc.)

Listen to MP3 (0:14:40)
Listen to OGG (0:14:40)


Gordon Haff:  Hello everyone, this is Gordon Haff, Cloud Evangelist with Red Hat. Today, I'm sitting with Mark Lamourine, who's a software engineer with Red Hat. We're going to talk about the OpenShift Community from a somewhat different angle, today.
A few weeks ago, I interviewed Matt Hicks, who heads the engineering team. He talked a little bit about what OpenShift is doing to make it easier for people contribute code.
Mark, although he works for Red Hat, is really coming at this a little bit from an outside perspective. Among other things, Mark will talk a little bit about what OpenShift is doing from a semi‑outside perspective around community. Welcome, Mark.
Mark Lamourine:  Thanks Gordon.
Gordon:  Can you tell us a little bit about yourself?
Mark:  I've been at Red Hat for three years. My background is in system administration and software development. I worked for awhile at Genuity, which is a defunct ISP. Most of the focus in my career has been on system administration. When I came to Red Hat, I got to work on writing documents that help the system administrators implement the things that they're working on.
Gordon:  What are you doing that's maybe is a bit different from what the people in Matt's engineering team were doing?
Mark:  What I do, is I work from the outside. I am not in the chain of command of Matt's regular engineers. I come at things from the standpoint of the system administrator who needs to implement this on the community box. I'm coming at things from outside. I build the boxes without the benefit of all the internal tools that the people here have, so that I can understand how someone who is coming to OpenShift, as an implementer, will see things.
Sometimes, the people who are doing the engineering lose track of what it is, they want to put the features out, they lose track of what it feels like to be a person who's not totally ingrained in the culture.
We're trying to foster a community. We're trying to invite people in. I'm trying to identify places where there would be blocks, difficulties, or confusion for someone trying to come in and to figure out what things they would need to know so that they can engage well with the regular engineering community.
Gordon:  I think by way of context here, OpenShift started with our online service, and that very much had an external focus on the developer. As we've had our open source OpenShift Origin, our OpenShift Enterprise commercial subscription offering, there's still very much focus on developer but, now people have to actually stand this up on sites, so system admins and architects, also have needs that have to be addressed now.
Mark:  Yeah, that's a change that's happened in the last few months. You're right. When we first put OpenShift online, the focus was on the application developer, that's really the focus of OpenShift in general, is to allow an application developer to not be a system administrator. Now, the service works, but someone in a company who wants to have an internal launch… They've got 400 PHP developers, who are all working on their laptops, in their own little environments, wants to create a standardized environment that they all use and where they don't have to be a system administrator on their own box.
Someone has to make that happen. We have packaging. We have a whole team who are addressing commercial opportunities that Red Hat has for companies that want to do this and pay us for it.
But we also have the community, where we might have a university or a small shop who wants to be able to set one of these up. I'm trying to address their needs. I'm trying to act as one of them and bring their concerns back to the engineering community inside, so that they get a perspective on what it's like to be that person.
Gordon:  This really has been one of the ways that OpenShift has been evolving since we spun it up about 18 months ago, is that there was a lot of interest in the online version. We still have, I don't know, how many applications, a lot...
But what's evolved, both with Red Hat and with the industry in general, is that a lot of companies that we talked to, even relatively small organizations, are like, kick the tires, we ran this online thing, and it's really great, but for something as important as our application development, this is really something that we want to have full visibility and control over.
Mark:  There are a lot of reasons why a company would want to have control over… There's the obvious things, like, we've got business information that we don't feel comfortable having out in the Cloud. Right now, our online stuff only runs on Amazon. But there are other reasons why as well. Not only the information there, but there's the reliability of your service. We are working on having a commercial offering with SLAs, but that's not there yet.
You might want to work in a situation where you're not competing with all of the other users who are on one of these boxes. That you can set up your own and do it. Again, we have an engineering team who's doing that for fairly large commercial interests.
I can see wanting to do this inside a small company or even with only a few people, so that they can collaborate well together. It suits itself well to that kind of shared collaboration, in conjunction with a service like GitHub or your own internal revision control services.
Gordon:  Let's talk about some of the specific perspectives that you've had working with the OpenShift community. Maybe talk about some of the specific things that you've done, for starters.
Mark:  With respect to the product itself, I've done a fair amount of work on the DNS backend services. DNS is one unusual backend service. Most services, you can set up your own little instance and you just run OpenShift or whatever. You can have this nice little self‑contained demo. DNS is, by it's nature, not like that. DNS is publishing. DNS is pushing something out where people can see it.
In most IT organizations, that service is pretty carefully guarded. You have to talk to other people to connect to their service, so that you can publish applications.
Another aspect of DNS is that it's probably the single most reliable and most used service on the Internet, so most people don't get a chance to kick it. They set it up, it just runs, and they don't have to worry about it. It's not until they start trying to publish something that they realize that there's more going on there.
I was surprised to find I have a unique perspective, because as I said, I worked at Genuity. I worked on the DNS servers that published a large part of the Internet during that period of time. I happen to have some background and it's been helpful and fortuitous, but I didn't do anything special for it. It wasn't what I was hired for. It was just something where I saw a need and stepped in.
That seems to be what my role is. If I see something that has a need and I have the background, I step in and offer something.
Gordon:  If somebody at systems admin, let's say, and they want to start playing with OpenShift in the community, what would your recommendation be?
Mark:  The first thing would be to look at the actual community offerings. The biggest activity is on the free note IRSE channel, #openshift or more specifically, #openshift-dev. The #openshift channel is more for application developers. The #openshift-dev channel is for people who are doing implementations, debugging, or working on internals. The second thing would be to look at the mailing lists, which are available on the OpenShift community website. There's specifically a dev channel there, a dev mailing list there. IRC is the big place to start. We've also started working, Krishna and I, on providing content on a Google+ community. All of those are available. They should be easy to find with a Web search.
Gordon:  What are specific types of things that somebody could do if they wanted to maybe start making some contribution?
Mark:  Get a GitHub account for the origin server branch and start looking at the code. That's really the way I approach it as well. I have been on the project since near the beginning, but there's an awful lot I don't know. The engineer's population has grown tremendously since the beginning. I don't know all the people anymore and haven't for a while.
The fastest way is to go look at the code. The GitHub site has fairly good internal documentation you could walk down the tree and look at individual pieces.
Again, get on the channel and ask. I'm one of the people. There are a number of us who are there and watch it all the time.
Even when I don't know the answer, if I see a question go up and no one responds right away, I will at least say hello. I might say, "I'm not the best person to answer this, but post it out here. Talk to me and someone who is will eventually come by, scroll back to the logs, see your question, and be able to answer it."
Gordon:  I've been seeing some traffic in the various lists that were also doing some things to make it easier just to get Origin installed.
Mark:  There's a lot of work there because it's not the easiest thing right now. It's not perfect in Fedora 18. We got the original packages into Fedora 18 with the release, because if we hadn't, it would have taken another six months we'd have had to wait for Fedora 19. But there's still a lot of work to do if you want to build a box on Fedora 18. There are packages that we need that aren't yet upstream. There's a repository that we maintain for Open Shift of those package that are still...We're still working on getting them upstream, but we can't stop development, so we provide them for the interim.
It's been moving. It's a moving target, how to install this stuff is a moving target. There are a number of blog posts, and really, when you find one, you want to look at the age, because the older they are, the more likely they are to be outdated. If you find the newer ones, there are going to be bugs in it. We're still working on it, and we're still getting it so that it's seamless.
But that's really the part I'm working on, is how do I, there are people who are working on how do I wrap it all up. I'm actually working on how to take it apart so that when something doesn't go the way you expect, where do you look? What do you do? That's really what my focus in my various blogs has been.
Gordon:  There's also a new cartridge architecture, cartridges being essentially the plugin mechanism for Open Shift that is planned to really make it easier to develop cartridges.
Mark:  It will. It's not an area that I'm really deep into right now. There are some really good people working on that, so I haven't really felt the need to get into it directly. But the big thing they're doing is providing cleaner interfaces for the user space code. One of the aspects of OpenShift that's a bit unusual in a PaaS is it's not a virtual machine. It's a multitenant system and that was one of the things I worked on early on, was figuring out ways so that you could have individual users that you can't denial of service.
You can't DOS someone else who's on the box. You can't escape. You can run your application there and not worry about whether or not somebody else is eating up all the memory.
What the new cartridge will do is nicely define the boundaries between what are user space tasks, what are system space tasks, and what are OpenShift setup tasks, which really fall in the middle?
Gordon:  What are you working on right now?
Mark:  A couple of different things. I'm actively working on the experience of building an OpenShift broker from scratch without using the package scripts, so that I can see what's going on underneath and talk about it. I'm also looking at the...I've got a pull request outstanding for putting the package build logic in a place where people expect to see it.
Right now, we have a set of OpenShift dev tools. They wrap the build process. It works really well, if you're working in a specific environment that we use for testing and for automation.
It hides a lot of the details of what's going on inside and it doesn't yet allow you to tweak specific areas, build a single package, or run through the build install test cycle, for a single package you might be developing.
What I'm doing is working to move those tasks closer to where the developer is by putting, in this case, a Rakefile, which is a Ruby equivalent of make, into each package directory. So that when someone is developing they look and go, "There's a Rakefile there." I can type Rake tasks and it will tell me what I can do. Then I can go to the top and I can say Rake build.
It will walk down the tree and I don't need a set of special tools to do that. I'm working to make it so that that build process is layered, so that you can get at it at each of the layers as is appropriate for your work.
Gordon:  Sounds like fun stuff. I should also mention to our listeners we have a community day coming up for OpenShift, in mid April, right in advance of the open stack summit in Portland, Oregon. If you're going to be in the area, stop on by.
Mark:  We've also started a Friday IRC hour from 9:00 o'clock Pacific time. Krishna and I, and a couple of other people, will be available specifically to answer open questions, Fridays at noon Eastern, 9:00 Pacific.

No comments: