On Thu, May 15, 2014 at 09:01:16PM +0000, Alex Huang wrote: > > 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. > > > > 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 and > > why it > > should be affected by versions? [*] If it's config management recipes those > > 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 dir. > > 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 changes 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 release 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 release 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 > components, like Jenkins or Mysql that we can just specify the > version # like 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 independent entity, then we should include it > in the source tree and branch it with the release or risk CI > breaking for that release. For things like this, I rather 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.
Ok - easier to understand this when you guys are ready to share your framework/tools. Even so, I forsee it being composed of tools and libraries that have little to nothing to do with CloudStack. Which is why I would like it to be part of a different repo, have their own independant releases so infra code can be deployed and upgraded by ops guys (of various companies using the solution) at the time they see best. For instance - jenkins instances upgrade regardless of the projects they are building. > > > > > [*] 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 testers should do. It's not to explain the infrastructure code. > I'm sure Santhosh and others will document what they've done and how > others can take advantage. Look forward to it. > > --Alex -- Prasanna., ------------------------ Powered by BigRock.com
