[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

A case for layered development/build/test/deployment tools.



I've been looking a lot at formal development and deployment process, the tools that implement it and the different use cases that exist.

I've discovered a number of places where I feel that I'd like more control and flexibility than the existing origin-dev-tools can provide.

In one case I have submitted a pull request to address a single case:  I want to build and publish a local copy of the OpenShift Origin Server packages, *but nothing else*.

  https://github.com/openshift/origin-server/pull/1640

If I try (without this) to build the packages from source without the overhead of origin-dev-tools, the process is a bit painful:

  http://cloud-mechanic.blogspot.com/2013/03/the-bleeding-edge-building-openshift.html

The origin-dev-tools require a number of packages that aren't required for anything else (rubygem-aws-sdk is for managing EC2 instances which (in this example, I don't want).

There are a number of tasks which seem to require root when they should not, or perform "prerequisite" tasks which are not needed for the actual task requested.

I think we could probably break the set of tasks down in scope and implement them using tools appropriate to that level.  Then we could use those to automate the steps we need at the next level up without restricting users who do not wish to use them.

1) build a single package
2) build all packages
3) build yum repository and publish
4) manage EC2 (create instance or AMI, power on/off, install OS)
5) install Openshift on host (regardless of type)
6) configure OpenShift on host (regardless of type)

I'm working on 1-3 now.  Krishna's addressing 5 and 6 with Puppet.

origin-dev-tools (nee devenv) really started off to be about 4 at the beginning but hard coding extended it to all levels.

Ideally we could implement and de-couple each layer from the ones above and below, identifying only the input requirements from below and the products to be offered to the layer above.

The Rakefile additions in PR 1640 provide a means for the existing devenv to do task 3 without hard coded logic.

Comments welcome.

- Mark





-- 
Mark Lamourine <markllama redhat com>
Sr. Software Developer, Cloud Engineering
Red Hat, 314 Littleton Road, Westford MA 01886
Voice: +1 978 392 1093
http://people.redhat.com/~mlamouri
markllama @ irc://irc.freenod.org*lopsa


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]