My worry with re-running the burn-in every time we do cleaning is for resource utilisation. When the machines are running the burn-in, they're not doing useful physics so I would want to minimise the number of times this is run over the life time of a machine.
It may be possible to do something like the burn in with a dedicated set of steps but still use the cleaning state machine. Having a cleaning step set (i.e. burn-in means cpuburn,memtest,badblocks,benchmark) would make it more friendly for the administrator. Similarly, retirement could be done with additional steps such as reset2factory. Tim -----Original Message----- From: Dmitry Tantsur <[email protected]> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Date: Monday, 12 March 2018 at 12:47 To: "[email protected]" <[email protected]> Subject: Re: [openstack-dev] [ironic] PTG Summary Hi Tim, Thanks for the information. I personally don't see problems with cleaning running weeks, when needed. What I'd avoid is replicating the same cleaning machinery but with a different name. I think we should try to make cleaning work for this case instead. Dmitry On 03/12/2018 12:33 PM, Tim Bell wrote: > Julia, > > A basic summary of CERN does burn-in is at http://openstack-in-production.blogspot.ch/2018/03/hardware-burn-in-in-cern-datacenter.html > > Given that the burn in takes weeks to run, we'd see it as a different step to cleaning (with some parts in common such as firmware upgrades to latest levels) > > Tim > > -----Original Message----- > From: Julia Kreger <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> > Date: Thursday, 8 March 2018 at 22:10 > To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> > Subject: [openstack-dev] [ironic] PTG Summary > > ... > Cleaning - Burn-in > > As part of discussing cleaning changes, we discussed supporting a > "burn-in" mode where hardware could be left to run load, memory, or > other tests for a period of time. We did not have consensus on a > generic solution, other than that this should likely involve > clean-steps that we already have, and maybe another entry point into > cleaning. Since we didn't really have consensus on use cases, we > decided the logical thing was to write them down, and then go from > there. > > Action Items: > * Community members to document varying burn-in use cases for > hardware, as they may vary based upon industry. > * Community to try and come up with a couple example clean-steps. > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
