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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
