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