Open Stack

Given the partial retirement scenario (i.e. only racks A-C retired due to cooling contrainsts, racks D-F still active with same old hardware but still useful for years), adding new hardware to old cells would not be non-optimal. I'm ignoring the long list of other things to worry such as preserving IP addresses etc.

Sounds like a good topic for PTG/Forum?

Tim

-----Original Message-----
From: Jay Pipes <jaypipes at gmail.com>
Date: Wednesday, 29 August 2018 at 22:12
To: Dan Smith <dms at danplanet.com>, Tim Bell <Tim.Bell at cern.ch>
Cc: "openstack-operators at lists.openstack.org" <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] [nova][cinder][neutron] Cross-cell cold migration

    On 08/29/2018 04:04 PM, Dan Smith wrote:
    >> - The VMs to be migrated are not generally not expensive
    >> configurations, just hardware lifecycles where boxes go out of
    >> warranty or computer centre rack/cooling needs re-organising. For
    >> CERN, this is a 6-12 month frequency of ~10,000 VMs per year (with a
    >> ~30% pet share)
    >> - We make a cell from identical hardware at a single location, this
    >> greatly simplifies working out hardware issues, provisioning and
    >> management
    >> - Some cases can be handled with the 'please delete and
    >> re-create'. Many other cases need much user support/downtime (and
    >> require significant effort or risk delaying retirements to get
    >> agreement)
    > 
    > Yep, this is the "organizational use case" of cells I refer to. I assume
    > that if one aisle (cell) is being replaced, it makes sense to stand up
    > the new one as its own cell, migrate the pets from one to the other and
    > then decommission the old one. Being only an aisle away, it's reasonable
    > to think that *this* situation might not suffer from the complexity of
    > needing to worry about heavyweight migrate network and storage.
    
    For this use case, why not just add the new hardware directly into the 
    existing cell and migrate the workloads onto the new hardware, then 
    disable the old hardware and retire it?
    
    I mean, there might be a short period of time where the cell's DB and MQ 
    would be congested due to lots of migration operations, but it seems a 
    lot simpler to me than trying to do cross-cell migrations when cells 
    have been designed pretty much from the beginning of cellsv2 to not talk 
    to each other or allow any upcalls.
    
    Thoughts?
    -jay