Open Stack

I was investigating this issue and this is what I found:

In the boot request, the compute layer passes the instance_type_id to
the driver layer (driver.spawn) and the driver layer then extracts
actual flavor information. However, different drivers extract/use this
information differently -
- libvirt - nova.virt.libvirt.driver.ComputeDriver._get_guest_config
uses the "instance_type_id" field of instance object and calls the
Flavor.get_by_id (which checks the DB via the conductor). It works on
the objects.flavor.Flavor object
- Ironic - Does the same as libvirt
- Hyper-V - nova.virt.hyperv.vmops.VMOps.create_instane - This uses
the information contained within the "instance" table itself like
"memory_mb","vcpus" which is passed on to the
vmutils.VMUtils.create_vm. So it uses the passed instance dict
- XenAPI - It uses the flavors.extract_flavor to extract flavor
related information (as a dict) from the instance's system_metadata.
It uses the flavor dict.
Because libvirt and ironic query the database, it causes a
FlavorNotFound exception on the child cell.

In a resize request, the compute API itself handles the DB access to
gather the instance_type (flavor) information needed. The
instance_type is then passed down to the driver. This means all the
drivers work on the same kind of object (In this case a flavor dict).

I think we should be consistent in the way these similar cases are handled.

IMO the way "resize" is handled is better for a cell setup.

I'd like to hear your opinion about using the same approach for "boot".

Already in the existing code, the method which initiates action on a
boot request in nova
(nova.api.openstack.compute.servers.Controller.create) queries the
local DB to extract flavor info as a dictionary and passes the
returned "instance_type" dict to the compute API in use. The compute
API makes use of the instance_type dict in `_provision_instances`
which returns a list of Instance objects but not in any subsequent
operations. All further compute API operations (including
build_instances) work on the Instance objects. By passing the
"instance_type" dict to subsequent compute API methods, we can avoid a
second redundant DB lookup. Since in a cell setup that is the step
that generates the FlavorNotFound exception, we can remove the bug.

Regards,
Dheeraj

On Wed, Sep 10, 2014 at 2:06 PM, Dheeraj Gupta <dheeraj.gupta4 at gmail.com> wrote:
> Hi,
> we are working on bug-1211011 (Flavors created in parent cell are not
> propagated to the child cell)..
> we need a few pointers from the community (and people working with cells).
>
> The problem is that if the "instance_type" tables are not in sync in
> all cells we can spawn a
> different flavor than the one selected by the user.
> Example: flavor_A is selected and in the child cell flavor_B is spawned.
>
> This is because what is checked at spawn time is the
> "instance_type_id" in the child cell database,
> and there is not guarantee that this corresponds to the same flavor in
> the parent cell.
>
> A possible solution to this problem can be propagating the flavors to
> all child cells when it is created/deleted/changed in the parent cell.
> But since instance_type_id is an autoincrement field, it will be
> difficult to sync it. Also there may be a problem when applying this
> to an existing cell setup.
>
> We believe that the flavors should only live in the parent cell (API cell).
> In this case every time that this information is needed the child cell
> needs to query the information
> from the parents.
>
> The problem is that at the moment in the child cells the compute api
> not aware about cells.
> Should this be reconsidered?
>
> Also, having this mechanism to query the parent cell will allow to
> more easily add support for security groups and aggregates.
>
> Thoughts?
>
> Regards,
> Dheeraj