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

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



I'd been thinking about that.  There are two places where it matters:

1) in the tree above the cart sources
  we could skip those and just search for Rakefiles in the cart dirs

  the all:rpm target rebuilds everything.  The carts take the majority of the time and will likely have the lowest change rate as a group
  though individually new ones will change fast.
  

2) in the root of the cart sources:

tito just builds the package.  it doesn't find and install build requirements, run tests or generate documentation.

They're not conflicting, they're complementary

- -- 

I used the presence of a Rakefile at each directory so that a rebuild could be started at any level.  it would be perfectly reasonable to require one in each package with standard builddep, rpm, testrpm, (unit)test, doc/yard targets while removing the boilerplate Rakefile at the intermediate levels.  The one could either build at the package level or at the top of the tree but not easily "in the middle".

From a maintenance standpoint that avoids the problem when someone adds a new tree (for what ever reason) but negects to add or maintain the Rakefile at each level.

The attempt was prompted by a sense that a new developer coming to work on the origin-server components would find themselves blocked and have to implement something like this themselves.

Matt indicated concern about triggering rebuilds in localized components without rebuilding the matching parts of an upgrade.  I see this as a fairly low risk.  The use cases I see are:

1) a component developer who is rebuilding their part frequently as they work
  This person is going to be touching all of the relevant dependencies and rebase/rebuild
  If their work is truely isolated they're going to be fine.  If not, they will discover as a normal part




On Wed, Mar 20, 2013 at 12:15 PM, Daniel McPherson <dmcphers redhat com> wrote:
Hi Mark,

  I am a little concerned about any extra work and clutter the Rakefiles bring to the cart and cart implementer.  It seems like we are just trading tito build for rake rpm at the cost of this extra work/clutter.

-Dan


----- Original Message -----
> 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
>
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev



--
----
Mark Lamourine <markllama gmail com>
Dad, Hubbie, Software Developer, System Administrator, Road Cyclist

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