Rick,
This is a problem of dependency resolution rather than an issue of
keystoneclient specifically. You can see that glanceclient has a cap on
keystoneclient that the installed version doesn't meet.
Dependency resolution has always been a problem but is raising its head again
recently. If
- Original Message -
From: German Eichberger german.eichber...@hp.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Saturday, 25 April, 2015 8:55:23 AM
Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate
Hi,
You could call GET project/project_id and verify that the project really
exists in Keystone. But again by doing that you would be increasing load on
Keystone server. When UUID tokens are being used, an additional call is
needed to verify the token. If you add another call to this then it
Excerpts from Steven Dake (stdake)'s message of 2015-04-23 23:27:00 +:
Hi folks,
I have spent the last couple of days trying to bring some sanity to the image
building process for Magnum.
I have found a tool which the Atomic upstream produces which allows a simple
repeatable
On 04/26/2015 02:21 PM, Gregory Haynes wrote:
Excerpts from Steven Dake (stdake)'s message of 2015-04-23 23:27:00 +:
Hi folks,
I have spent the last couple of days trying to bring some sanity to the
image building process for Magnum.
I have found a tool which the Atomic upstream
On 4/26/15, 11:21 AM, Gregory Haynes g...@greghaynes.net wrote:
Excerpts from Steven Dake (stdake)'s message of 2015-04-23 23:27:00 +:
Hi folks,
I have spent the last couple of days trying to bring some sanity to the
image building process for Magnum.
I have found a tool which the
The tox.ini entry for dsvm-fullstack sets OS_ROOTWRAP_CMD=sudo
{envbindir}/neutron-rootwrap {envdir}/etc/neutron/rootwrap.conf (and
something similar for rootwrap-daemon).
Is this the answer you were looking for, or are you saying OS_ROOTWRAP_CMD
doesn't appear to be honoured in your case?
-
Hi, Sergey
we are in the same phase like you, I have noticed that there is a topic in
the https://etherpad.openstack.org/p/sahara-liberty-proposed-sessions
currently we decide to do the HA on service level (HDFS etc), here is the
doc
Our CI system is currently not processing any events. This means that no
new check or gate jobs get started.
Uploading new patches and reviewing is working fine.
But new patches uploaded will not get checked and patches approved will
not get gated and merge - and recheck will not help either.
On Sunday, April 26, 2015, Jamie Lennox jamielen...@redhat.com wrote:
- Original Message -
From: German Eichberger german.eichber...@hp.com javascript:;
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org javascript:;
Sent:
On 18-Apr-15 02:41, Mike Bayer wrote:
On 4/17/15 1:29 PM, Zane Bitter wrote:
On 16/04/15 04:05, Anant Patil wrote:
Hi,
Sometime back we had a discussion on IRC regarding sqlite migration
scripts. Since sqlite is mostly used for testing, we were thinking
about moving the sqlite migration
Dear Sirs,
1. Test 3rd CI connectivity
History on ci-sandbox
https://review.openstack.org/#/c/177134/
1st log:
http://openstack.infortrend.com/34/177134/1/check/noop-check-communication/75112cd/
2nd log (recheck):
12 matches
Mail list logo
