Open Stack

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 <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
>      
> 
> __________________________________________________________________________
> 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
>