Hi gang,
As you may have seen if you actually read all the merge proposal email you get <wink>, as part of my quest to get us closer to a continuous delivery stype of development I've written a script that updates a LAVA instance to the tip of trunk of all the various LAVA components. I will set things up so that this runs every night on the staging instance soon (need to fiddle things somehow so that a sudo password isn't necessary to restart the instance after the code is upgraded).
However, Spring is right now using the staging instance to test some dispatcher changes. If I'd set the cronjob I refer to above up and Spring was particularly unlucky, the cronjob would wipe out the changes he's made to the instance to test while he's testing them. This seems less than ideal.
Because what we do is always going to be hard to test outside a production like environment, I think what we need is yet another instance: one that we can hack about relentlessly as needed to test changes that we haven't yet landed. I propose the name "dogfood" for this (maybe we'd even go as far as having scripts that completely removed the dogfood instance and could recreate it as needed to ensure a clean baseline).
So we'd have:
* production: duh * staging: this is _solely_ used to determine if changes that have landed to the trunk of some component are safe to deploy to production * dogfood: random hacking
I think that potentially we could have some way of bringing up dogfood instances as needed in our private cloud, but tbh for now one on control that we share amongst ourselves in a loose way (i.e. check on IRC before doing stuff with it) would be a useful thing.
What do you guys think?
Cheers, mwh
+1 for this.
On 4 May 2012 07:18, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Hi gang,
As you may have seen if you actually read all the merge proposal email you get <wink>, as part of my quest to get us closer to a continuous delivery stype of development I've written a script that updates a LAVA instance to the tip of trunk of all the various LAVA components. I will set things up so that this runs every night on the staging instance soon (need to fiddle things somehow so that a sudo password isn't necessary to restart the instance after the code is upgraded).
However, Spring is right now using the staging instance to test some dispatcher changes. If I'd set the cronjob I refer to above up and Spring was particularly unlucky, the cronjob would wipe out the changes he's made to the instance to test while he's testing them. This seems less than ideal.
Because what we do is always going to be hard to test outside a production like environment, I think what we need is yet another instance: one that we can hack about relentlessly as needed to test changes that we haven't yet landed. I propose the name "dogfood" for this (maybe we'd even go as far as having scripts that completely removed the dogfood instance and could recreate it as needed to ensure a clean baseline).
So we'd have:
* production: duh * staging: this is _solely_ used to determine if changes that have landed to the trunk of some component are safe to deploy to production * dogfood: random hacking
I think that potentially we could have some way of bringing up dogfood instances as needed in our private cloud, but tbh for now one on control that we share amongst ourselves in a loose way (i.e. check on IRC before doing stuff with it) would be a useful thing.
What do you guys think?
Cheers, mwh
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On 4 May 2012 13:18, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Hi gang,
As you may have seen if you actually read all the merge proposal email you get <wink>, as part of my quest to get us closer to a continuous delivery stype of development I've written a script that updates a LAVA instance to the tip of trunk of all the various LAVA components. I will set things up so that this runs every night on the staging instance soon (need to fiddle things somehow so that a sudo password isn't necessary to restart the instance after the code is upgraded).
However, Spring is right now using the staging instance to test some dispatcher changes. If I'd set the cronjob I refer to above up and Spring was particularly unlucky, the cronjob would wipe out the changes he's made to the instance to test while he's testing them. This seems less than ideal.
Because what we do is always going to be hard to test outside a production like environment, I think what we need is yet another instance: one that we can hack about relentlessly as needed to test changes that we haven't yet landed. I propose the name "dogfood" for this (maybe we'd even go as far as having scripts that completely removed the dogfood instance and could recreate it as needed to ensure a clean baseline).
So we'd have:
- production: duh
- staging: this is _solely_ used to determine if changes that have
landed to the trunk of some component are safe to deploy to production
- dogfood: random hacking
I think that potentially we could have some way of bringing up dogfood instances as needed in our private cloud, but tbh for now one on control that we share amongst ourselves in a loose way (i.e. check on IRC before doing stuff with it) would be a useful thing.
What do you guys think?
Usually we don't need such kind of instance, staging is enough. But for the proxy case, it's an global configuration to lava-dispatcher and validation farm server, which needs some debug during the testing, it happens in real server. Yes I think dogfood is necessary though the usage would not be very frequent.
Cheers, mwh
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On Fri, 4 May 2012 17:01:24 +0800, Spring Zhang spring.zhang@linaro.org wrote:
On 4 May 2012 13:18, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Hi gang,
[...]
What do you guys think?
Usually we don't need such kind of instance, staging is enough. But for the proxy case, it's an global configuration to lava-dispatcher and validation farm server, which needs some debug during the testing, it happens in real server. Yes I think dogfood is necessary though the usage would not be very frequent.
I agree -- most of the time it's not necessary, and maybe most of the time it won't be running (or even present on disk?). But having the DNS and apache config in place will be useful I think...
Cheers, mwh
On Mon, 07 May 2012 09:24:17 +1200, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
On Fri, 4 May 2012 17:01:24 +0800, Spring Zhang spring.zhang@linaro.org wrote:
On 4 May 2012 13:18, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Hi gang,
[...]
What do you guys think?
Usually we don't need such kind of instance, staging is enough. But for the proxy case, it's an global configuration to lava-dispatcher and validation farm server, which needs some debug during the testing, it happens in real server. Yes I think dogfood is necessary though the usage would not be very frequent.
I agree -- most of the time it's not necessary, and maybe most of the time it won't be running (or even present on disk?). But having the DNS and apache config in place will be useful I think...
FWIW, dns is now set up. I'll set up the apache config tomorrow unless someone really wants to beat me to it :-)
Cheers, mwh
On 05/04/2012 12:18 AM, Michael Hudson-Doyle wrote:
So we'd have:
- production: duh
- staging: this is _solely_ used to determine if changes that have landed to the trunk of some component are safe to deploy to production
- dogfood: random hacking
I think that potentially we could have some way of bringing up dogfood instances as needed in our private cloud, but tbh for now one on control that we share amongst ourselves in a loose way (i.e. check on IRC before doing stuff with it) would be a useful thing.
What do you guys think?
I'm +1 on this. I'd been thinking the same thing. I want it really easy to try out a change that hasn't yet been merged and "dogfood" fits that requirement. I'm not a huge fan of the name, but I can't think of anything better and don't want to get stuck bike-shedding.
Along the lines of another thread we had. I think we should have one dedicated board for this instance also.
+1 from me, especially if dogfood has a board along with it.
ZK
On Fri, May 4, 2012 at 7:19 PM, Andy Doan andy.doan@linaro.org wrote:
On 05/04/2012 12:18 AM, Michael Hudson-Doyle wrote:
So we'd have:
* production: duh * staging: this is _solely_ used to determine if changes that have landed to the trunk of some component are safe to deploy to production * dogfood: random hacking
I think that potentially we could have some way of bringing up dogfood instances as needed in our private cloud, but tbh for now one on control that we share amongst ourselves in a loose way (i.e. check on IRC before doing stuff with it) would be a useful thing.
What do you guys think?
I'm +1 on this. I'd been thinking the same thing. I want it really easy to try out a change that hasn't yet been merged and "dogfood" fits that requirement. I'm not a huge fan of the name, but I can't think of anything better and don't want to get stuck bike-shedding.
Along the lines of another thread we had. I think we should have one dedicated board for this instance also.
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On Fri, 04 May 2012 12:19:25 -0500, Andy Doan andy.doan@linaro.org wrote:
On 05/04/2012 12:18 AM, Michael Hudson-Doyle wrote:
So we'd have:
- production: duh
- staging: this is _solely_ used to determine if changes that have landed to the trunk of some component are safe to deploy to production
- dogfood: random hacking
I think that potentially we could have some way of bringing up dogfood instances as needed in our private cloud, but tbh for now one on control that we share amongst ourselves in a loose way (i.e. check on IRC before doing stuff with it) would be a useful thing.
What do you guys think?
I'm +1 on this. I'd been thinking the same thing. I want it really easy to try out a change that hasn't yet been merged and "dogfood" fits that requirement. I'm not a huge fan of the name, but I can't think of anything better and don't want to get stuck bike-shedding.
I'm just stealing names/process from the Launchpad team, as usual :-)
Along the lines of another thread we had. I think we should have one dedicated board for this instance also.
Yeah, indeed.
Cheers, mwh
linaro-validation@lists.linaro.org
-
Andy Doan -
Le.chi Thu -
Michael Hudson-Doyle -
Spring Zhang -
Zygmunt Krynicki