An instance fails at launch when attaching a cinder volume

[Jeff Gojkovich]

Hello,

We are trying to launch instances in an Openstack environment. But when we launch an instance that is supposed to have a cinder volume attached scalarizr throws an exception.

I am pasting the exception below.  Let me know if there are any other logs to might help in troubleshooting.

2016-11-29 20:55:05,684+00:00 - INFO - scalarizr.ops.system.init - Configuring storage volumes

2016-11-29 20:55:05,746+00:00 - INFO - scalarizr.ops.system.init - Ensure cinder: create volume

2016-11-29 20:55:07,855+00:00 - ERROR - scalarizr.ops.system.init - Operation "system.init" (id: 6532ef19-b42d-492a-a5b0-4ddc6707997b) failed. Reason: The server could not comply with the request since it is either malformed or otherwise incorrect. (HTTP 400)

Traceback (most recent call last):

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\api\operation.py", line 187, in _in_progress

    self._completed(self.func(self, *self.func_args, **self.func_kwds))

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\handlers\lifecycle.py", line 446, in handler

    bus.fire("host_init_response", message)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\libs\bases.py", line 33, in fire

    ln(*args, **kwargs)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\handlers\block_device.py", line 95, in on_host_init_response

    self._plug_new_style_volumes(volumes)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\handlers\block_device.py", line 119, in _plug_new_style_volumes

    vol.ensure(mount=bool(vol.mpoint), mkfs=True)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\storage2\volumes\base.py", line 92, in ensure

    self._ensure()

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\storage2\volumes\cinder.py", line 160, in _ensure

    volume_type=self.volume_type)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\storage2\volumes\cinder.py", line 211, in _create_volume

    **kwds)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\platform\__init__.py", line 89, in __call__

    return self.invoke(*args, **kwds)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\platform\openstack.py", line 186, in invoke

    return super(CinderConnectionProxy, self).invoke(*args, **kwds)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\scalarizr-5.1.7-py2.7.egg\scalarizr\platform\__init__.py", line 100, in invoke

    return self.obj(*args, **kwds)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\cinderclient\v2\volumes.py", line 263, in create

    return self._create('/volumes', body, 'volume')

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\cinderclient\base.py", line 299, in _create

    resp, body = self.api.client.post(url, body=body)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\cinderclient\client.py", line 315, in post

    return self._cs_request(url, 'POST', **kwargs)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\cinderclient\client.py", line 275, in _cs_request

    **kwargs)

  File "C:\opt\scalarizr\5.1.7\embedded\lib\site-packages\cinderclient\client.py", line 258, in request

    raise exceptions.from_response(resp, body)

BadRequest: The server could not comply with the request since it is either malformed or otherwise incorrect. (HTTP 400)

[Jeff Gojkovich]

This has been an issue since we upgraded to the Liberty release of Openstack.  With Kilo this functionality seems to work perfectly fine.

[Jeff Gojkovich]

Turns out this is an issue due to the disabling of the v1 api.  Reenabled v1 and it works.  Is there any way to force Scalr to use the v2 of the cinder api?

On Tuesday, November 29, 2016 at 2:05:57 PM UTC-7, Jeff Gojkovich wrote: