Open Stack

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 <dtantsur at redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Monday, 12 March 2018 at 12:47
To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org>
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 <juliaashleykreger at gmail.com>
    > Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
    > Date: Thursday, 8 March 2018 at 22:10
    > To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
    > 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    > 
    
    
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev