Sunday, August 5, 2012

Openshift Broker: Writing a Plugin Pt 1 - Prep

Welcome Mechanics

Openshift Origin is an open source "Platform as a Service" (PaaS) system.  There's a lot of focus on the applications you can create using Openshift Origin.  This column though is dedicated to the people who need to create and run one.

Openshift Origin: Moving Parts

The Openshift Origin service consists of two major components and several minor ones.  The major components are a broker and one or more nodes.  The broker is the control center of the service.  It manages and coordinates the creation and distribution of user applications to the nodes.  The nodes are the place where the user applications run.

The broker also depends on four other services.  It maintains its own metadata in a data store.  User actions are allowed based on the authentication of the user requests. New applications are published in DNS via a name service.  The broker communicates with the nodes through a message service.

The four broker services are abstracted so that they can be implemented using any suitable back-end service.  The back end services are integrated with the broker using plugin modules.

This modular approach means that it is possible (encouraged!) for people to implement their own plugins for the back end services.

Have It Your Way

  Each service currently only has one plugin implemented:
  • Datastore: MongoDB
  • Authentication: MongoDB
  • Name Service: BIND
  • Messaging: Mcollective/QPID
I expect that there will be people who would like to user other implementations for those services.  For example, an Openshift Origin architect might choose to use one of the commercial DNS providers to publish applications.  Most of these have their own DNS update protocols and do not offer and RFC 2136 compliant mechanism. She could implement the StickShift::AuthService interface as a new plugin to interact with the commercial provider.  I expect that there will be people who want to use one of several alternate authentication mechanisms.  OAuth, LDAP, Kerberos, and Active Directory are all possible. It is common today for web services to authenticate using one of the common social media sites.  The choice is up to the service developer.

For someone who intends to implement a new plug-in there are a few considerations:  The Openshift Origin broker is a Ruby on Rails application.  The plug-ins are written in Ruby and will need access to some information from the Rails framework.

What Owner's Manual?

The Openshift Origin service is young and it is still growing and changing rapidly.  Implementing a service is still an exercise for the early adopters with both the benefits and risks that go with it.  There is a lot of room for new developers to contribute but the ecosystem around it is still a bit raw.  Both the code and the documentation need a lot of work.  Expect to do a lot of digging in the code to make it work.  Make good use of the community forums and development email and IRC resources.

The current plugins are stored in the openshift/crankcase repository on Github.  They are packaged as RPMs for inclusion in Fedora and Red Hat Enterprise Linux and their derivatives.  They are also packaged as Rubygems for use on systems which don't use RPM for software management.  Integration with the existing software management tools will be easiest if it is done from the beginning.

I'm going to implement and detail a new name service plugin for Openshift Origin.  This will implement the StickShift::DnsService interface. The most common request for development and testing has been for DNSMasq.  This is a small local service which provides a non-delegated forwarding name server.  It is useful in isolated networks. (in the sense of "individual hosts are not directly accessible from outside").  It can provide DHCP and TFTP services for network booting and dynamic addressing as well as providing dynamic hostname/IP address publication.  Properly configured it will forward requests for which it does not provide answers so that within the network it serves it provides seamless responses for both internal and external networks.

Create the Work Space

Much of the work needed to create a robust develop/build/test/package has been done already for the existing Openshift Origin modules and plugins.  The quickest way to get started right off in the right direction is to fork the openshift/crankcase project and create yourself a development branch.

You're going to need a Github account and a work station with the git client.  The development process will be easiest on Fedora or RHEL, but it's not necessary.  On a Red Hat derived system a lot of the setup will be automated.  I'm going to assume Fedora 16 for this series.  If you you're on anything else and you try one of the setup steps and it doesn't work you may have to do some digging to resolve it.

I'm going to assume you have a working knowledge of git and access to help using Github.

So here's how we get setup:

  1. Workstation: Fedora 16 (easiest), RHEL 6.x or Fedora 17 (see Idiosyncracies)
  2. On RHEL, you'll need to enable the EPEL repo
  3. Install git client
  4. Create Github account
  5. Fork openshift/crankcase
  6. Clone your project
  7. Create a development branch
There are good documents to learn how to do these tasks on the Github site and in the git documentation so I won't repeat them here. The one thing I will  mention is the hub tool which is designed specifically to add the kinds of work flow steps that are required to manage a project in Github.

In general it's a good habit not to do development on the master branch even of your own fork.  You're going to want to merge updates from the original project master branch into your master branch and then rebase your development branch against your local master. This can also make the cleanup which is often needed prior to a pull-request easier.

Because I'm writing a DnsService plugin using DNSMasq, I'm going to name the branch uplift-dnsmasq (I have no idea where uplift came from but it's the prefix in Openshift which indicates a DnsService plugin)

Initialize the Development Environment

There are two ways to prepare the build environment for a new rubygem plugin.  You can create a complete build environment for all possible packages, or you can just install the minimal requirements for your plugin.
The full environment is needed if you mean to rebuild the entire package suite.  However there are still some gotchas when creating a build environment on non-Fedora 16 systems.  A minimal build environment can be customized more easily but will likely fail when trying to build other packages.

Minimal Build Environment






For just building a Rubygem plugin, the whole build environment might be overkill. All you really need is the build tool tito and the ruby and rubygems packages (and their dependencies)






  yum install tito ruby rubygems








Complete Build Environment

The build environment is created with a rake task: build_setup.  So, to use it you have to install rubygem-rake.




  yum install rubygem-rake
  cd crankcase/build
  rake build_setup



Fedora 17



The build_setup task is currently written for Fedora 16. There is also currently no Fedora 17 repo for Openshift Origin.  The first time you run the build_setup task it will create a file called ss.repo. You will need to edit the crankcase/build/Rakefile and replace $releasever with 16 so that the installation process will  complete.



Fedora 17 also has a different version of openjdk.  You'll have to change any references to java-1.6.0-openjdk and java-1.6.0-openjdk-devel to refer to version 1.7.0







Ready to Begin





At this point you should be ready to begin work on the new plugin.  In the next installment we'll create the skeleton of a new DNS plugin.





References















Posted by



at







































No comments:















Post a Comment


















        

      









Subscribe to:
Post Comments (Atom)