> - 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. > From my understanding, these models were feasible with Cells V1. I don't think cellsv1 supported any notion of moving things between cells at all, unless you had some sort of external hack for doing it. Being able to migrate between cells at all was always one of the things we touted as a "future feature" for cellsv2. Unless of course you mean migration in terms of snapshot-to-glance-and-redeploy? --Dan _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
