[Nova][Ironic] Reset Configurations in Baremetals Post Provisioning
mark at stackhpc.com
Mon Jun 24 14:58:20 UTC 2019
On Fri, 14 Jun 2019 at 11:18, Kumari, Madhuri <madhuri.kumari at intel.com> wrote:
> Hi Eric,
> Thank you for following up and the notes.
> The spec is related but a complex one too with all the migration implementation. So I will try to put a new spec with a limited implementation of resize.
I was talking with Madhuri in #openstack-ironic about this today .
While talking it through I raised some concerns about the nova
resize-based design, which I'll try to outline here.
When we deploy a node using deploy templates, we have the following sequence.
* user picks a flavor and image, which may specify required traits
* selected traits are pushed to ironic via instance_info.traits
* ironic finds all deploy templates with name matching one of the
* deploy steps from the matching templates are used when provisioning the node
The deploy steps could include RAID config, BIOS config, or something else.
If we now resize the instance to a different flavor which has a
different set of traits, we would end up with a new set of traits,
which map a new set of deploy templates, with a new set of steps.
How do we apply this change? Should we execute all matching deploy
steps, which could (e.g. RAID) result in losing data? Or should we
attempt to execute only those deploy steps that have changed? Would
that always work? I don't think we keep a record of the steps used to
provision a node, so if templates have changed in the intervening time
then we might not get a correct diff.
The original RFE  just called for specifying a list of deploy steps
via ironic API, however this doesn't really work for the nova model.
> >>-----Original Message-----
> >>From: Eric Fried [mailto:openstack at fried.cc]
> >>Sent: Thursday, June 13, 2019 11:15 PM
> >>To: openstack-discuss at lists.openstack.org
> >>Subject: Re: [Nova][Ironic] Reset Configurations in Baremetals Post
> >>We discussed this today in the nova meeting  with a little bit of followup
> >>in the main channel after the meeting closed .
> >>There seems to be general support (or at least not objection) for
> >>implementing "resize" for ironic, limited to:
> >>- same host 
> >>- just this feature (i.e. "hyperthreading") or possibly "anything deploy
> >>And the consensus was that it's time to put this into a spec.
> >>There was a rocky spec  that has some overlap and could be repurposed;
> >>or a new one could be introduced.
> >> an acknowledged wrinkle here was that we need to be able to detect at
> >>the API level that we're dealing with an Ironic instance, and ignore the
> >>allow_resize_to_same_host option (because always forcing same host) 
More information about the openstack-discuss