The my_ip, host and use_ipv6 options are used all over the codebase
and they're pretty well related to each other. Create a new netconf
module for them to live in.
There are now no options registered globally in nova.config!
blueprint: scope-config-opts
Change-Id: Ifde37839ae6f38e6bf99dff1e80b8e25fd68ed25
The enabled_apis option is only used in nova-api and nova-all but
there's no more obvious place to put it than nova.service. At least
this location is consistent, since we quite have a number of other
options related to the APIs in nova.service.
blueprint: scope-config-opts
Change-Id: I86e200fa5ad91ac0b7ab6837cc61e5927b2ebeb7
Move the compute_manager, console_manager, cert_manager, network_manager
and scheduler_manager options into nova.service.
Apart from the tests, these options are mostly just used in nova.service
so it makes sense for them to live there. Also, metadata_manager already
lives there.
blueprint: scope-config-opts
Change-Id: I180859817b57c081b83d6a6f075a6ff76bb0ef6d
Even though the compute_topic opt is used outside nova.compute.rpcapi,
it makes sense for the RPC module to "own" the topic option.
blueprint: scope-config-opts
Change-Id: I453951825481b9a5ba1865f6bf1223f7b1e25f98
This is the final step in enabling availability_zones using aggregate
metadata. Previously all services had an availability_zone, but the
availability_zone is only used for nova-compute. Services such as
nova-scheduler, nova-network, nova-conductor have always spanned all
availability_zones.
After this change only compute nodes (nova-compute), will have an
availability_zone. In order to preserve current APIs, when running:
* nova host-list (os-hosts)
* euca-describe-availability-zones verbose
* nova-manage service list
Internal services will appear in there own internal availability_zone
(CONF.internal_service_availability_zone)
Internal zone is hidden in euca-describe-availability_zones
(non-verbose)
CONF.node_availability_zone has been renamed to
CONF.default_availability_zone and is only used by the nova-api and
nova-scheduler. CONF.node_availability_zone still works but is
deprecated
DocImpact
Completes blueprint aggregate-based-availability-zones
Change-Id: Ib772df5f9ac2865f20df479f8ddce575a9ce3aff
Part 3 of 6: blueprint general-bare-metal-provisioning-framework.
Change-Id: Ia19ce00edb84aa924c2ab2c9c2217f6b49073d69
Co-authored-by: Mikyung Kang <mkkang@isi.edu>
Co-authored-by: David Kang <dkang@isi.edu>
Co-authored-by: Ken Igarashi <igarashik@nttdocomo.co.jp>
Co-authored-by: Arata Notsu <notsu@virtualtech.jp>
The scheduler_topic opt is only used in nova.scheduler.rpcapi and it
makes sense for the RPC module to "own" the topic option.
blueprint: scope-config-opts
Change-Id: Iafb8705eb716b650b63e060fe1dd36666bcee812
Even though the console_topic opt is used outside nova.console.rpcapi,
it makes sense for the RPC module to "own" the topic option.
blueprint: scope-config-opts
Change-Id: I0f00927ca1c0bba7b21315240165e83e7075ebb7
The network_topic opt is only used in nova.network.rpcapi and it makes
sense for the RPC module to "own" the topic option.
blueprint: scope-config-opts
Change-Id: Icd779f34df47ac6dd048b3e41995e872d8859872
The cert_topic opt is only used in nova.cert.rpcapi and it makes sense
for the RPC module to "own" the topic option.
blueprint: scope-config-opts
Change-Id: If3584b8e1984e0425d9f33133f9d291739b04d49
a part of blueprint general-bare-metal-provisioning-framework.
Implement nova-baremetal-deploy-helper.
This service listens for HTTP requests from baremetal deploy ramdisk,
formats the remote disk and writes an image to it, as part of baremetal
PXE provisioning.
blueprint improve-baremetal-pxe-deploy shows how we plan to improve this
process.
Change-Id: I0a1b020cc5f81d49559acd4dcc781397a58e2c01
Co-authored-by: Mikyung Kang <mkkang@isi.edu>
Co-authored-by: David Kang <dkang@isi.edu>
Co-authored-by: Ken Igarashi <igarashik@nttdocomo.co.jp>
Co-authored-by: Arata Notsu <notsu@virtualtech.jp>
Co-authored-by: Devananda van der Veen <devananda.vdv@gmail.com>
This introduces *EXPERIMENTAL* compute cells functionality as a way to
scale nova in a more distributed fashion without having to use complicated
technologies like DB and message queue clustering.
Cells are configured as a tree and the top level cell should contain
nova-api without any nova-computes while child cells contain everything
except nova-api. One can think of a cell as a normal nova deployment in
that each cell has its own DB server and message queue broker.
The top level cell keeps a subset of data about ALL instances in all
cells in its DB. Child cells send messages to the top level cell when
instances change state. Data in 1 child cell is not shared with another
child cell.
A new service, nova-cells, is introduced that handles communication
between cells and picking of a cell for new instances. This service is
required for every cell. Communication between cells is pluggable with
the only option currently implemented being communnication via RPC.
Cells scheduling is separate from host scheduling. nova-cells first picks
a cell (currently randomly -- future patches add filtering/weighing
functionality and decisions can be based on broadcasts of
capacity/capabilities). Once a cell has been selected and the new build
request has reached its nova-cells service, it'll be sent over to the host
scheduler in that cell and the build proceeds as it does without cells.
New config options are introduced for enabling and configuring the cells
code. Cells is disabled by default. All of the config options below go
under a '[cells]' section in nova.conf. These are the options that one
may want to tweak:
enable -- Turn on cells code (default is False)
name -- Name of the current cell.
capabilities -- List of arbitrary key=value pairs defining capabilities
of the current cell. These are sent to parent cells,
but aren't used in scheduling until later filter/weight
support is added.
call_timeout -- How long to wait for replies from a calls between cells
When using cells, the compute API class must be changed in the API cell,
so that requests can be proxied via nova-cells down to the correct cell
properly. Thus, config requirements for API cell:
--
[DEFAULT]
compute_api_class=nova.compute.cells_api.ComputeCellsAPI.
[cells]
enable=True
name=api-cell
--
Config requirements for child cell:
--
[cells]
enable=True
name=child-cell1
--
Another requirement is populating the 'cells' DB table in each cell.
Each cell needs to know about its parent and children and how to
communicate with them (message broker location, credentials, etc).
Implements blueprint nova-compute-cells
DocImpact
Change-Id: I1b52788ea9d7753365d175abf39bdbc22ba822fe
Clarify docs for nova-novncproxy to indicate that it only serves
noVNC web content. Also remove duplicated link from manpage
Change-Id: Ia1f4aff21591132a5c41810a371d248ea0001e1f
Add commands to nova-manage for configuring cells in the DB.
Implements blueprint nova-compute-cells
DocImpact
Change-Id: Ic1a950181d5ce191780647838c5d06e5410676f7
The VCS version string in nova/version.py has been hardcoded
to 'LOCALBRANCH:LOCALVERSION' since change
0bbb0e8cb1daa351af91cf97b2bcababfc0c7f9f
The only places which use this info are some logging calls,
and since 'nova-manager version' command. The latter would
more usefully output the distro specific package string.
Delete the VCS related methods in version.py and replace their
usage with a new method version_string_with_package() which
appends the distro-specific package tag
Change-Id: I972b79c329198cb5376d537c6b672830094cd759
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This error reporting needs more work, but this at least stops us
from presenting a stack trace to the user and is as broken as
before.
Resolves bug 1091403.
Change-Id: I941983b60cc3762a916d57b7ea67264e093cfa44
Add syslogging capabilities to nova-rootwrap, if you set parameter
use_syslog to True. You can specify a facility (syslog_log_facility)
and level (syslog_log_level) to use. Finalizes bp nova-rootwrap-options.
In doing so, it moves rootwrap config parsing to a nova.rootwrap.wrapper
object (and adds unit testing for it). It also improves log messages
content (including the name of the matching filter and the escalation
path used). Incidentally fixes bug 1084766.
Change-Id: Idb8cd9c9febd6263dafab4bc2bff817f00c53dc0
Import latest cfg from oslo-incubator with these changes:
Add deprecated --logdir common opt
Add deprecated --logfile common opt.
Allow nova and others to override some logging defaults
Fixing the trim for ListOp when reading from config file
Fix set_default() with boolean CLI options
Improve cfg's argparse sub-parsers support
Hide the GroupAttr conf and group attributes
Fix regression with cfg CLI arguments
Fix broken --help with CommonConfigOpts
Fix ListOpt to trim whitespace
updating sphinx documentation
Don't reference argparse._StoreAction
Fix minor coding style issue
Remove ConfigCliParser class
Add support for positional arguments
Use stock argparse behaviour for optional args
Use stock argparse --usage behaviour
Use stock argparse --version behaviour
Remove add_option() method
Completely remove cfg's disable_interspersed_args()
argparse support for cfg
The main cfg API change is that CONF() no longer returns the un-parsed
CLI arguments. To handle these args, you need to use the support for
positional arguments or sub-parsers.
Switching nova-manage to use sub-parser based CLI arguments means the
following changes in behaviour:
- no more lazy matching of commands - e.g. 'nova-manage proj q' will
no longer work. If we find out about common abbreviations used in
peoples' scripts, we can easily add those.
- the help output displayed if you run nova-manage without any args
(or just a category) has changed
- 'nova-manage version list' is no longer equivalent to
'nova-manage version'
Change-Id: I19ef3a1c00e97af64d199e27cb1cdc5c63b46a82
Provide i18n to some exceptions that were not
provided before.
Change-Id: Ia320ba5f12e82686c8ee7973a77f152eb4b02bd4
Signed-off-by: Chuck Short <chuck.short@canonical.com>
Moving the test-case setup and teardown code into managed fixtures
so that we can better interact with them when we start running things
in parallel.
Part of blueprint grizzly-testtools
Change-Id: I406be0a88b14c0dba2d22b4957e26a53442bbae3
Prevent nova-manage from stack tracing when the wrong number of
arguments are passed in.
Fixes bug 1083315
Change-Id: I7b9a237a82b4255d88c01c6a56ad0ccd4a6ee984
Adds support for a configurable set of trusted directories to search
executables in (exec_dirs), which defaults to system PATH. If your
filter specifies an exec_path that doesn't start with '/', then it
will be searched in exec_dirs. Avoids having to write multiple
filters to care for distro differences. Fixes bug 1079723.
Also returns a specific error rather than try to run absent executables.
Change-Id: Idab03bb0be6832a75ffeed4e78d25d0543f5caf9
Updates the rxtx_factor validations in the instance_types modules so
that rxtx_factor is validated as a float. Given that rxtx_factor is stored
as a float in the database this makes sense... and also adheres
to some of the extension documentation as well (although some of
the extension docs were incorrect as well).
Previously rxtx_factor was being cast into an int which caused it to
be stored and displayed incorrectly via the API.
This patchset adds a test which fails with the old code.
Additionally some of the API docs are corrected so that rxtx_factor is
listed as a float in all examples.
Fixes LP Bug #1081287.
Change-Id: Iae98522a1f2ed63cbd2497b0b0af5ac2d9bb935c
nova-dhcpbridge's FLAGFILE environment variable is one of the few
remaining references we have to "flags".
Switching to use a new environment variable is easy, but we need
to take care that when you upgrade the code the compute and network
services might not be restarted immediately.
If this happens, the services may launch a new dnsmasq (so rootwrap
needs to continue to support FLAGFILE) or an existing dnsmasq might run
the lease script (so the script needs to support FLAGFILE).
Change-Id: Ieb55daa2507abb8327c7f5a2ef2f682740f31a5d
We always launch dnsmasq with FLAGFILE set, so something is very broken
if FLAGFILE isn't set when nova-dhcpbridge is launched.
Also, the fallback to CONF.dhcpbridge_flagfile is a little strange - at
this point, we haven't parsed any config files so the only possible
value of this config option is its default value.
There's no real need to gracefully handle this condition either - a
KeyError is a straightforward enough error.
Change-Id: I734d7b739f17c8a9ab48d8ba13baacff3f00e1c4
The only reason for importing nova.config now is where one of the
options defined in that file is needed. Rather than importing
nova.config using an import statement, use CONF.import_opt() so
that it is clear which option we actually require.
In future, we will move many options out of nova.config so many
of these import_opt() calls will either go away or cause a module
other than nova.config to be imported.
Change-Id: I0646efddecdf2530903afd50c1f4364cb1d5dce1
Modules import nova.config for two reasons right now - firstly, to
reference nova.config.CONF and, secondly, if they use one of the
options defined in nova.config.
Often modules import nova.openstack.common.cfg and nova.config
which is a bit pointless since they could just use cfg.CONF if
they just want to nova.config in order to reference CONF.
Let's just use cfg.CONF everywhere and we can explicitly state
where we actually require options defined in nova.config.
Change-Id: Ie4184a74e3e78c99658becb18dce1c2087e450bb
This adds a new service called "nova-conductor" which will provide
services for nova-compute, such as completing database updates and
handling long-running tasks.
Right now, this just adds a fraction of the database-related work
so that we can proceed with incremental changes to nova-compute.
For compatibility/flexibility, both LocalAPI and (RPC)API classes
are provided. Users concerned with performance or compatibility
who wish to maintain compute-node-local database accesses can
set the [conductor] use_local=True, which will mimic the legacy
behavior.
DocImpact
Change-Id: Ib81d879f40b7daceeffad5af0631c7db68168661
nova.flags is no longer needed except to load nova config options shared
across multiple daemons.
This removes nova.flags from the bin programs and makes sure that
nova.flags is imported in nova.config for now.
Change-Id: If066ac0070387bee4b41e6a78ad972f7a0955c75
* Remove volume calls from nova.db.api
* Remove volume calls from nova.db.sqlalchemy.api
* Remove tables from nova/db/sqlalchemy/models.py
* Remove Xen Storage Manager Volume Driver code
* No migration to preserve data in unused tables
* Remove quota support for volumes
DocImpact
part of bp delete-nova-volume
Change-Id: I2c82c96d67f3746e5de28f917dd8ceb0c8037e27
Fixes Bug: #1074717
During volume attach on Windows a process is spawned. The process
currently fails with the following exception, due to eventlet monkey
patching of the os module.
NotImplementedError: set_nonblocking() on a file object with no
setblocking() method (Windows pipes don't support non-blocking I/O)
The fix consists in avoiding monkey patching the os module in
nova-compute on Hyper-V
Change-Id: Ib513bc218da83b751439bad114baac24b08e3d02
Use the global CONF variable instead of FLAGS. This is purely a cleanup
since FLAGS is already just another reference to CONF.
We leave the nova.flags imports until a later cleanup commit since
removing them may cause unpredictable problems due to config options not
being registered.
Change-Id: Id0c59b2dc8002ec89ccbc5e5d7986fb68d3a693d