On 8/29/2018 3:21 PM, Tim Bell wrote:
Sounds like a good topic for PTG/Forum?
Yeah it's already on the PTG agenda [1][2]. I started the thread because
I wanted to get the ball rolling as early as possible, and with people
that won't attend the PTG and/or the Forum, to weigh in on not only
such as preserving IP
addresses etc.
Sounds like a good topic for PTG/Forum?
Tim
-Original Message-
From: Jay Pipes
Date: Wednesday, 29 August 2018 at 22:12
To: Dan Smith , Tim Bell
Cc: "openstack-operators@lists.openstack.org"
Subject: Re: [Openstack-operators] [nova][cinder][neut
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
> - 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
2018 at 18:47
To: Jay Pipes
Cc: "openstack-operators@lists.openstack.org"
Subject: Re: [Openstack-operators] [nova][cinder][neutron] Cross-cell cold
migration
> A release upgrade dance involves coordination of multiple moving
> parts. It's about as similar to this s
On 08/29/2018 02:26 PM, Chris Friesen wrote:
On 08/29/2018 10:02 AM, Jay Pipes wrote:
Also, I'd love to hear from anyone in the real world who has successfully
migrated (live or otherwise) an instance that "owns" expensive hardware
(accelerators, SR-IOV PFs, GPUs or otherwise).
I thought
On 08/29/2018 10:02 AM, Jay Pipes wrote:
Also, I'd love to hear from anyone in the real world who has successfully
migrated (live or otherwise) an instance that "owns" expensive hardware
(accelerators, SR-IOV PFs, GPUs or otherwise).
I thought cold migration of instances with such devices was
On 08/29/2018 12:39 PM, Dan Smith wrote:
If we're going to discuss removing move operations from Nova, we should
do that in another thread. This one is about making existing operations
work :)
OK, understood. :)
The admin only "owns" the instance because we have no ability to
transfer
> A release upgrade dance involves coordination of multiple moving
> parts. It's about as similar to this scenario as I can imagine. And
> there's a reason release upgrades are not done entirely within Nova;
> clearly an external upgrade tool or script is needed to orchestrate
> the many steps and
I respect your opinion but respectfully disagree that this is something
we need to spend our time on. Comments inline.
On 08/29/2018 10:47 AM, Dan Smith wrote:
* Cells can shard across flavors (and hardware type) so operators
would like to move users off the old flavors/hardware (old cell) to
>> * Cells can shard across flavors (and hardware type) so operators
>> would like to move users off the old flavors/hardware (old cell) to
>> new flavors in a new cell.
>
> So cell migrations are kind of the new release upgrade dance. Got it.
No, cell migrations are about moving instances
Sorry for delayed response. Was on PTO when this came out. Comments
inline...
On 08/22/2018 09:23 PM, Matt Riedemann wrote:
Hi everyone,
I have started an etherpad for cells topics at the Stein PTG [1]. The
main issue in there right now is dealing with cross-cell cold migration
in nova.
I think in our case we’d only migrate between cells if we know the network and
storage is accessible and would never do it if not.
Thinking moving from old to new hardware at a cell level.
If storage and network isn’t available ideally it would fail at the api request.
There is also ceph
Hi everyone,
I have started an etherpad for cells topics at the Stein PTG [1]. The
main issue in there right now is dealing with cross-cell cold migration
in nova.
At a high level, I am going off these requirements:
* Cells can shard across flavors (and hardware type) so operators would
14 matches
Mail list logo
