- bump version from 2 to 3 for cinderclient
- update aws ec2 interface for create_colume and
create_network_interface. add cilent_token param
- fix describe network interface - something was
changed in neutron ports output
- set metadata port for OVN conf file also
Change-Id: Ie3e5a5930d5a8159050ecc0900239935558dddd7
Currently ec2api uses the volume v2 API by default, but v2 API was
deprecated a while ago and will be removed fron cinder shortly.
This patch ensures that ec2api uses the volume v3 API instead by
default.
Closes-Bug: #1908993
Change-Id: I280d3c009893c67d215b0c7106eec7fe2435c335
Now that we no longer support py27, we can use the standard library
unittest.mock module instead of the third party mock lib.
Change-Id: Iadefcc287b8557723a9bebc816080cf65636686b
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
current devstack deploys glance version '2' only.
use it.
messages in keystone's exceptions was changed.
fix unit tests that checks it.
Change-Id: I7ed1f0ff518efa374a5e3b693c5785958c77340d
At v2.33 new bdm field 'tag' was introduced. This field is automatically
created by snapshot operation for volume backed instance (ebs). The
result of the operation - bdm - is stored in metadata of the snapshot
image. When ec2api user requires to run an instance with this image
changing some attributes of the attached volume (e.g.
delete_on_termination), this bdm is merged with user defined parameters
and sent to Nova. As the result the new 'tag' field is sent to Nova
since v2.32.
However the used API version is v2.10, which does not support 'tag'
field. This did not lead to faults (until I56348dc2) because Nova
verified the first bdm only, but the first bdm for ebs instances was a
bdm for the image. With the noted fix this no more works.
This patch swithes ec2api to use v2.32 to get 'tag' field supported.
Change-Id: I68329bbffeeff5d460f3fca1a212ba20b35fc284
do not use keystone_url in keystone_ec2_tokens_url definition.
configure these two urls independently.
Change-Id: I78c54c26820dfd7b52bf7cec81fa4ca0174a9eb6
Since requirements.txt requres all used OS clients to be present, it
isn't needed to workaround their absence.
Also since required novaclient version supports microversions, it isn't
needed to check microversions support of client.
Change-Id: Ie7f1ca4c0b1ca5661fd76b3fbcb4d661c68e0362
Since that oslo_context is used in ec2api, admin context is cached
between service calls. This leads to that context auth token becomes
outdated, because it has no renewal logic. This is not a big problem for
ec2api service, because each new initialization of regular context
overwrites a previous cached context. But this is a problem for metadata
service, where is no regular context used.
Instead of disabling caching of admin contexts this patch uses the
caching in a separate thread storage. To handle token outdating Keystone
session is used.
Change-Id: I714419dc193471dde8a15715cbaeec83896809c9
An admin may specify nova_service_type which doesn't support v2.1. Or
ec2-api can be run against Nova which doesn't support a required
microversion. ec2-api should check this and put warning to log.
This patch does that. If Nova service doesn't suport the required
microversion, ec2-api uses the last microvertions the service supports.
But do not switch to v2 or v2.1 with no microversions at all. This will
be useful for a future cases, when ec2-api uses new features with their
own microversions.
Change-Id: I1cc828b8cad908d9d029c57d514e4ce7e8f47352
Use bdm v2 to boot ebs instance for gating
novaclient 2.27.0 has a bug with legacy bdm, and fails on instance boot
attempt. This patch uses bdm v2 instead to workaround the bug.
Change-Id: I3d856b2ba4116c19ab936db63d29413fdfbf31e0
Use 'compute' service type by default
It was a grand error to use not default service type as a service type
by default. Now DevStack provides v2.1 by 'compute' service type, does
not provide 'computev21' at all. Because that gating fails.
Change-Id: I8a68d331583ea575a5883cd2c451245a9119016b
Nova provides several API versions. Each version is provided on its own
endpoint. Endpoints are registered in Keystone service catalog with
different service types. Only one 'compute' service type name is
reserved for compute services. So names of other compute service types
are depended of custom deployment.
ec2-api prefers to work against v2.1 Nova API which allows to maximize
AWS compatibility. But service type provides v2.1 is unknown. It may be
not 'compute' one, as it is in DevStack. So ec2-api should allow to set
service type name to use it.
This patch adds an ability for service type to be specified. Old manner
of verification that used service type supports required API version is
inapporpriate now. So this check it's dropped, but a new one will be
added in a separate changed.
Change-Id: I59da2d7dada07d2f1b8e25ca17161b469a00fdfe
Since current requirements require python-novaclient>=2.22.0, we can
feel free to do not support previous versions.
Change-Id: I88ee261a61e1e71083d087d58352e3fbd3ea4d56
Currently requests to these services are not logged with debug=True
config option by default. This makes debugging difficult.
Also set default log level for keystoneclient.auth to WARN, because it
floods logs with useless info.
Change-Id: Idfe2684b4146bb3c44159a08572e3c0eeff85f5f
Ghanshyam Mann