Inline.

On 03/12/2018 01:00 PM, Tim Bell wrote:
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.

You only have to run it every time if you put the step into automated cleaning. However, we also have manual cleaning, which is run explicitly.


It may be possible to do something like the burn in with a dedicated set of 
steps but still use the cleaning state machine.

Yep, this is what manual cleaning is about: an operator explicitly requests it with a given set of steps. See https://docs.openstack.org/ironic/latest/admin/cleaning.html#manual-cleaning


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.

++

We may even add a reference set of clean steps to IPA, but we'll need your help implementing them. I am personally not familiar with how to do burn-in right (though IIRC Julia is).


Tim

-----Original Message-----
From: Dmitry Tantsur <dtant...@redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, 12 March 2018 at 12:47
To: "openstack-dev@lists.openstack.org" <openstack-dev@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 <juliaashleykre...@gmail.com>
     > Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
     > Date: Thursday, 8 March 2018 at 22:10
     > To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to