Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of Alex.Huang@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Alex Huang <Alex.Huang@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: RE: [PROPOSAL] Using continuous integration to maintain our code
 quality...
Thread-Topic: [PROPOSAL] Using continuous integration to maintain our code
 quality...
Thread-Index: 
 Ac9phfCcUZHuC6ncQyC8gXLKm7nsFQAmL3iwASd8wwAADzO8gAAFe/VAABgMTIAADF9vAAAjU3mAABP5l2A=
Date: Thu, 15 May 2014 21:01:16 +0000
Message-ID: <20CF38CB4385CE4D9D1558D52A0FC058711316@SJCPEX01CL03.citrite.net>
References: <20CF38CB4385CE4D9D1558D52A0FC05870768C@SJCPEX01CL03.citrite.net>
 <EDD8E64855FBDA45ACDFE02112E795B702564350@HQ1-EXCH03.corp.brocade.com>
 <CAGQtxvbxebg2Rh2ZdyRjoPtFj2TyyO_zPrijY6Jq6cMr9nOYTw@mail.gmail.com>
 <CAGTtUd7d2zdASaPvbuEL8z1FuOFqDg_NRtHR0Mzp2O-xx418Mw@mail.gmail.com>
 <20CF38CB4385CE4D9D1558D52A0FC05870F31F@SJCPEX01CL03.citrite.net>
 <CB688D716959224C95995F52DE5E824217ABA66B@SINPEX01CL02.citrite.net>
 <20CF38CB4385CE4D9D1558D52A0FC058710241@SJCPEX01CL03.citrite.net>
 <20140515041105.GA3618@cloud.mshome.net>
In-Reply-To: <20140515041105.GA3618@cloud.mshome.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> On Wed, May 14, 2014 at 06:21:34PM +0000, Alex Huang wrote:
> > I think infrastructure code should just be checked in with the source
> > code.  To separate it means you have to deal with version
> > match/mismatch between infrastructure and source code.
>=20
> Sorry - that doesn't sound right. Usually infrastructure code has little =
to do
> with the source code other than deploying the packages built from said
> source. Could you please clarify the bits that go into this infra code an=
d why it
> should be affected by versions? [*] If it's config management recipes tho=
se
> are usually maintained separate from source of your web-tier. Infra code =
is
> maintained and changed usually more rapidly. I don't get why jenkins
> settings and config management should exist within our catch-all tools di=
r.
> We're going to bloat it up unnecessarily and realise later it should have=
 been
> a separate repo to begin with - for eg. cloudmonkey or marvin.

Let me put out what I consider as a requirement.  The requirement is any ch=
anges in framework, infrastructure, configuration, recipes, scripts, source=
 code, marvin, etc, cannot affect CI that has been established on released =
branches.  You have to look at CI like build for source code.  When a relea=
se is done, you take a label or a branch and you're fairly certain it will =
build again.  CI has to be the same, I might have shut it down for a releas=
e for a while but if I have to dust it off, I have to be fairly certain it =
runs again without a lot of debugging.  Now if there are well established c=
omponents, like Jenkins or Mysql that we can just specify the version # lik=
e we do with maven in build, then it's fine not to include it in the source=
 tree.  But if the components used by CI is not a well versioned independen=
t entity, then we should include it in the source tree and branch it with t=
he release or risk CI breaking for that release.  For things like this, I r=
ather not guess too optimistically about the chances.  We have to treat CI =
running on released branches to be like production systems.  The best thing=
 to do for a production system that works is to don't let anyone touch any =
part of it, as any ops guy will tell you.

>=20
> [*] the wiki did not have enough information about the infra-code

It's not intended to.  The wiki is meant to provide what developers and tes=
ters should do.  It's not to explain the infrastructure code.  I'm sure San=
thosh and others will document what they've done and how others can take ad=
vantage.

--Alex