cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <>
Subject Re: Discuss on the Jenkins CI
Date Tue, 11 Sep 2012 10:21:12 GMT
I'm not entirely clear about the role of puppet here. Where exactly
does puppet fit in? AFAIK, the slave nodes can be dumb slaves that
just do distro specific builds for us. They can be preconfigured and
reused for each build. They don't even need to have jenkins installed
on them. The slave.jar is just moved into the nodes directly by
jenkins and it can track and monitor their state.

The packaging commands - dpkg, rpmbuild can then be run within slaves
and artifacts can be copied back to master where they are hosted for
download. I think this is how some of the projects build on where you can see distro specific slaves.

+1 - on moving to jenkins controlled builds. External scripts should
be replaced by jenkins plugins. There are a wide variety of them - SSH,
git, mvn and even jClouds.


On Mon, Sep 10, 2012 at 09:07:38PM -0400, Frank Zhang wrote:
> > >
> > > I thought we should use puppet anyway for future expansion.
> > > For now, for instance, installing Jenkins itself should be done by
> > > puppet, adding ssh credential, adding an account, and whatever system
> > > configuration works.
> > > What I expect is we only spring up a vm with puppet agent installed,
> > > puppet master takes care of rest work (no manually 'yum install
> > > Jenkins' anymore) And puppet should go to our test system in future as
> > > well, so now let's take this chance to make puppet warm up.
> > 
> > 
> > It's ok to warm up puppet, but the build is more important. For example, we
> > need to customize the version number, or the name of the
> > artifcates(rpm/deb), it's better to move to new Jenkins, other than hacking
> > on the existing python code.
> We can do that. Just step by step. As setting up puppet is easier, let's do it first.
> Next week I think we can move to Jenkins plugins 
> > 

View raw message