Victor Lowther ([email protected]) wrote: > > -----Original Message----- > > From: crowbar-bounces On Behalf Of Vincent Untz > > Sent: Thursday, May 30, 2013 7:57 AM > > To: crowbar > > Subject: Re: [Crowbar] Change in sledgehammer-common impacting more than > > Pebbles > > > > Le jeudi 30 mai 2013, à 07:03 -0500, Victor Lowther a écrit : > > > On Thu, May 30, 2013 at 3:28 AM, Vincent Untz <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > I just realized that one of my commits that got merged will impact > > > > non-Pebbles branches, and might be an issue requiring changes in > > > > these branches too. This is the following commit: > > > > > > > > > > https://github.com/crowbar/crowbar/commit/29b97580c42bdfe1e0b548cff7 > > > > 73811eaeea16d9 > > > > > > > > In short, this is changing /install-logs to > > > > /var/log/crowbar/sledgehammer. > > > > > > > > > > That is going to break rather a lot of stuff. > > > > > > > > > > Other branches that are using the sledgehammer-common/start-up.sh > > > > file from crowbar master should probably be updated with commits > > > > like these > > > > ones: > > > > > > > > > > > > https://github.com/crowbar/barclamp-provisioner/commit/0290fc89b4ca8 > > > > d446eac9c3140247f18166fd6f1 > > > > > > > > https://github.com/crowbar/barclamp-logging/commit/9410dd876fc7603e0 > > > > ed9f34cefd78d7a4dcd4633 > > > > > > > > > No -- that is all the builds in all the releases, as Sledgehammer is > > > globally applicable to them all. Your changes modifying these paths > > > will have to be reverted and applied in a way that is Pebbles > > > specific, preferably by modifying control.sh in the provisioner. > > > > I'm sorry, I just don't get how we can change start-up.sh, then. > > Whatever we change there will always break a past release. If we revert this > > change, then it means we need to keep /install-logs/ as a NFS export, even > > in > > Pebbles. > > > > Is there a good reason all this sledgehammer stuff is not per-branch like > > everything else? > > There are reasons that seemed like a good idea at the time when we > did it a year and a half ago,
So what are those reasons, and are they still considered good ideas? > and not everything else is per-branch -- the rest of the build > system and the test framework is also global. ... which means that every time we want to touch the build system or the test framework, we risk breaking them for every single release (where by "release" I mean Fred, Pebbles etc.). So the same question applies, is there a good reason for that? Because AFAICS unless it's a really really good one, it doesn't outweigh the drastic disadvantages of the status quo. If there *is* a really good reason, then the per-branch code should *not* live in the same repo as the globally-applicable code. > > Or alternatively: why do we even have a lot of stuff in start-up.sh? Why > > don't we > > move nearly all of this in control.sh, except for the mount for the one NFS > > export that will make control.sh accessible? > > Having control.sh take over from start-up.sh is in fact the direction I have > been going. Cool :) _______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
