Resources:
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)
Transcript:
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:
Post a Comment