Greetings! I am currently a member of the TC, and I would like to
continue to serve.
I'm going to write this email backwards because I am aware it is quite
long. I have put what I hope to achieve on the TC at the top, but
provide background detail afterwards for those who want to dig deeper.
I am
Hi Gary,
Almost the same I have posted another way of the fix.
https://review.openstack.org/#/c/49942/
Both try to fix the same issue.
Gary's one changes neutronclient itself and mine chnages quantumclient proxy.
I am not sure which is the direction, but at least one of them should
be merged
Regarding https://review.openstack.org/#/c/49942/ (against
quantumclient branch),
the gate for quantumclient branch of python-neutronclient seems broken.
It seems the script expects master branch of python-neutronclient.
I am not sure what is the right direction to propose patch to
quantumclient
Confirmed.
On 10/06/2013 04:04 AM, Michael Still wrote:
Greetings! I am currently a member of the TC, and I would like to
continue to serve.
I'm going to write this email backwards because I am aware it is quite
long. I have put what I hope to achieve on the TC at the top, but
provide
Hello, Mike!
As for Nova connected thoughts, it was just a reference to the Roadmap,
that includes implementing the reservations opportunity first of all for
the solid virtual resources (VMs, volumes, …) and next for the complex ones
(Heat stacks, Savanna clusters, …). To implement complex
Thanks, Dina. Yes, we do not understand each other; can I ask some more
questions?
You outlined a two-step reservation process (We assume the following
reservation process for the OpenStack services...), and right after that
talked about changing your mind to use Heat instead of individual
Sometimes, when i run tox on neutronclient, the
test_ssl.TestSSL.test_client_manager_properly_creates_httpclient_instance
may fail. However, gate doesn't catch this problem, and even in my env, it
doesn't fail everytime, is there any other developer have meet same problem?
--
blog:
Hi there,
We've been investigating some guest filesystem issues recently and noticed
what looks like a slight inconsistency in base image handling in
block-migration. We're on Grizzly from the associated Ubuntu cloud archive
and using qcow on local storage.
What we've noticed is that after
