Remove plugging of internal classes from configuration

[Russell Bryant]

Nova currently has the following options:

    cfg.StrOpt('compute_api_class',
                default='nova.compute.api.API',
                help='The full class name of the compute API class to use'),
    cfg.StrOpt('network_api_class',
                default='nova.network.api.API',
                help='The full class name of the network API class to use'),
    cfg.StrOpt('volume_api_class',
                default='nova.volume.api.API',
                help='The full class name of the volume API class to use'),

These options came from the following commit:

commit c729ba8c0aa4d283e84d139bc98e0e89fd933c4a
Author: Chris Behrens <email address hidden>
Date: Sun Jan 15 23:29:41 2012 -0800

    Core modifications for future zones service.

    Makes compute/network/volume API classes pluggable
    Splits some code out in compute/api
    Adds some race condition checking on deletes in compute/api
    Make instance_delete support UUIDs
    Add support to RPC to cast to specific servers
    Migrations for future zones

    Change-Id: Ibee126cd6d325e11770f27589e79dfd0e6104b99

Nova should not expose the ability to replace internal classes in the configuration. These classes are internal implementation details. Exposing it via configuration like this commits us to some level of maintaining these implementation details in case someone has put in their own version. It also seems like a support nightmare.

Based on the commit when these went in, it sounds like we can just remove these options completely and handle what is necessary internally. For example, if these classes need to be swapped out for cells, then when you enable cells, it can be done automatically internally instead of allowing anyone to replace these classes with anything.

[Mark McLoughlin (markmc)]

Makes total sense to me - something like enable_zones=True should just automatically hook in the zones code

[Russell Bryant (russellb)]

I started looking at pulling these out a bit today. Removing 'compute_api_class' is easy. Removing the other two will be a bit more work. It looks like these options are used when configuring nova to use Quantum or Cinder. I think we'll need something like "enable_quantum" and "enable_cinder" and have them do the right things when enabled.

[Russell Bryant (russellb)]

I removed the assignee since it has been a couple of months, so it doesn't seem to be active.

The concensus around this seems to be that we should be moving to entrypoints for all of these types of options and have short names that we tell everyone to use in the configuration.

[Senhua Huang (senhuang)]

It seems only the first configuration option "compute_api_class" exists in nova/compute/__init__.py. The other two options are gone. Is the bug still valid?

[Senhua Huang (senhuang)]

Proposed fix:
Add a function "get_compute_api_class_name" that returns appropriate class name in nova/compute/__init__.py. This function basically returns "nova.compute.cells_api.ComputeCellsAPI" if Cell is used; and nova.compute.API otherwise.

To check whether cell is used, the function reads the nova.conf, and see whether [cells|enable] is set to true.

Please advise whether the above is appropriate.

[Chris Behrens (cbehrens)]

This will not work. When cells is enabled, it needs this special class in the API cell. But it needs the normal class in a child cell. Simply switching the class based on whether or not cells is enabled will break cells, because the child cell will use the wrong class.

[Senhua Huang (senhuang)]

Hi Chris,

Thanks for the comments. Just to clarify the issue a bilt. There are several cases.
- Users set compute.api.class as "nova.compute.ComputeAPI" and [cells|enable] as False, nova will run without cell functionality
- Users set compute.api.class as "nova.compute.cells_api.ComputeCellsAPI " and [cells|enable] as True, nova will run with cell functionality correctly. Internally, API cell will use nova.compute.cells_api.ComputeCellsAPI while child cells use nova.compute.ComputeAPI (and the corresponding HostAPI and InstanceActionAPI).
What if users set compute.api.class as "nova.compute.ComputeAPI " and [cells|enable] as True? Maybe I am missing something important here.. It seems cells|enable == True is the only condition that cells_api.ComputeCellsAPI is used by API cell.

But I agree on your other comment that we should depreciate the old options first rather than remove them.

[Russell Bryant (russellb)]

https://review.openstack.org/#/c/28750/

[Thierry Carrez (ttx)]

Pushing back to H2, please set back to H1 if this is milestone-critical (in which case the fix needs to land in master first and then be backported to milestone-proposed before tomorrow)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/28750
Committed: http://github.com/openstack/nova/commit/40c6c1a9d29608a04f2062e63dcc395acbb0dffd
Submitter: Jenkins
Branch: master

commit 40c6c1a9d29608a04f2062e63dcc395acbb0dffd
Author: Senhua Huang <email address hidden>
Date: Thu May 23 07:17:38 2013 -0700

    Deprecate compute_api_class option in the config

    Add a function "get_compute_api_class_name" within nova.compute
    that returns nova.compute.cells_api.ComputeCellsAPI if cell is
    enabled and this cell is an API cell, and returns compute.api.API
    otherwise.
    Add an option "cell_type" to the config in group "cells".
    Use the default value of "cell_type" (None) for legacy configuration.

    Change-Id: I32f5ccf789c657b563c165bfa8244e819b1a79a6
    Fixes: bug #1049249