Currently only 'xen' is supported for the 'hypervisor'
parameter. So examples are changed to 'xen'
instead of 'hypervisor'.
Change-Id: Ibd40dcfd3801c7a4165e299a1232ea46f2f17cf4
Implements: blueprint api-ref-in-rst
This patch move the all v2.1 api sample tests under
'functional/api_sample_tests'. Also move sample files under
'doc/api-samples'.
Co-Authored-By: Ed Leafe <ed@leafe.com>
Co-Authored-By: Alex Xu <hejie.xu@intel.com>
Partial-Bug: #1462901
Change-Id: I2b924f2ad7687a23a018a9b658e8acd9e04d7963
Currently v2 and v2.1 have separate functional tests and their
corresponding sample files. As v2 and v2.1 are supposed to be identical,
there is overhead to maintain two set of functional tests and sample files.
We can have one set of tests which can run for both v2 and v2.1.
This commit merges Agent functional tests.
Change-Id: Ibfbe20f6c0b773ec7cf39d532074075c722deb63
More work needs to be done in rfc3986 to give the user more control over what
they consider to be a valid URI in the context of RFC 3986. For example, a
previous incarnation of these tests checked that "1" and "abc" were invalid
when according to the RFC they are.
Update the API samples and tests to use valid URIs
DocImpact
Change-Id: I288fbaead64990db1053b7a11e82904611b8498f
This adds an extension that provides REST API for list/create/delete/
modify agent build. The interface is accessed via
GET /v2/{tenant_id}/os-agents
PUT /v2/{tenant_id}/os-agents/id
POST /v2/{tenant_id}/os-agents
DELETE /v2/{tenant_id}/os-agents
And this patch also create tests to get agent build API Samples.
DocImpact
Implements one workitem of blueprint apis-for-nova-manage
The agent is talking about guest agent.The host can use this for
things like accessing files on the disk, configuring networking,
or running other applications/scripts in the guest while it is
running. Typically this uses some hypervisor-specific transport
to avoid being dependent on a working network configuration.
Xen, VMware, and VirtualBox have guest agents,although the Xen
driver is the only one with an implementation for managing them
in openstack. KVM doesn't really have a concept of a guest agent
(although one could be written).
You can find the design of agent update in this link:
http://wiki.openstack.org/AgentUpdate
and find the code in nova.virt.xenapi.vmops.VMOps._boot_new_instance.
In this design We need update agent in guest from host, so we need
some interfaces to update the agent info in host.
You can find more information about the design of the GuestAgent in
the following link:
http://wiki.openstack.org/GuestAgenthttp://wiki.openstack.org/GuestAgentXenStoreCommunication
DocImpact
Change-Id: I5830388a894efce5b13680fc6916e0cd81a16624