I think it'd be worth filing a bug against the "openstack" client...most of the
clients try to be compatible with any server version.
Probably best to include the details from the run with the --debug option for
both the new and old version of the client.
Chris
On 05/29/2018 10:36 AM, Ken D'
On 2018-05-25 13:52, r...@italy1.com wrote:
> Use the --debug option to see what calls are going on and which one fails.
Thanks! That did the trick. Turned out the image that was causing
failure was one that's been stuck queueing since July, and has no
associated name. The lack of a name is ca
Content-Type: multipart/alternative;
boundary="=_cf36a87f98ab82fda0943c9d76d4868b"
--=_cf36a87f98ab82fda0943c9d76d4868b
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=utf-8
VXNlIHRoZSDigJRkZWJ1ZyBvcHRpb24gdG8gc2VlIHdoYXQgY2FsbHMgYXJlIGdvaW5nIG9uIGFu
ZCB3aGljaCBvbmUgZm
You can use -v (for verbose), directly check logs on openstackclient run.
On Fri, May 25, 2018 at 10:11 PM, Ken D'Ambrosio wrote:
> Hey, all. I've got a new job, and I tried my first Openstack command on
> it -- a Juno cloud -- with Openstack CLI 3.14.0, and it failed.
> Specifically:
>
> kdamb
Hey, all. I've got a new job, and I tried my first Openstack command on
it -- a Juno cloud -- with Openstack CLI 3.14.0, and it failed.
Specifically:
kdambrosio@mintyfresh:~/oscreds newton(QA/PCI)$ openstack image list
Resource doesn't have field name
glance image-list does fine.
Is this a
