Using devstack (thank you!) made it easy to see how the keystone/nova
integration was supposed to work and how to use nova client to create
vms, etc. In this case the old method of using nova-manage to create
users and then zipping up credentials to use with euca tools is not
possible. Is
.
Regards,
A. Yoshiyama
NEC, Japan
akirayoshiy...@gmail.com mailto:akirayoshiy...@gmail.com
2011/10/13 5:45 David Kranz david.kr...@qrclab.com
mailto:david.kr...@qrclab.com:
Using devstack (thank you!) made it easy to see how the
keystone/nova integration was supposed to work and how
Along the same lines, how do you export the shell variables for
euca-tools with keystone since nova-manage to create the zipfile does
not work?
-David
On 10/24/2011 8:29 PM, Vishvananda Ishaya wrote:
Speaking of keystone diablo tag, it is currently missing the following
commit:
I saw the same thing with the version from a week ago after updating
swift packages of a completely working diablo system.
David
On 11/25/2011 11:43 AM, Khaled Ben Bahri wrote:
Hi all,
I tryed to install swift on 7 nodes : the first is the proxy server,
and the others are storage servers
On 11/30/2011 7:59 AM, Soren Hansen wrote:
I don't have anything concrete to offer as an alternative, but I'd
love to see something like devstack that runs either from git or
tarballs and supports multiple distributions.
For production, we recommend people use packages. I think there's a lot
In general, it is unfortunate that there is such a big difference in the
end result between deploying from source and from packages, even though
they are supposed to function the same. Ideally the process structure,
locations of configuration files, etc. could be the same. The location
of
The meetings logs at
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/ only
have one entry (Jan 24) since Jan 18. I think there was an openstack-qa
meeting on the 25th. Is this the right link to find meeting logs? I have
been using it for a number of months.
-David
There was a thread about this in December:
http://www.mail-archive.com/openstack@lists.launchpad.net/msg06296.html
I think that thread is saying that if you follow the official
documentation for configuring live migration, but use --multi_host, then
migration will not actually work. If that is
In tracking down a problem with the tempest flavors test I noticed that
'nova flavor-list' returns this in Essex:
++---+---+--+--+---+-+
| ID |Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
Because at least some OpenStack projects use log files for more than
just error messages, there may not be a one-size-fits all answer to
this. I agree strongly with point 1 below but have also gotten a lot of
value from generic web searching of error snippets from log files,
including searches
There is currently a bug https://bugs.launchpad.net/tempest/+bug/933845
that will prevent tempest from working with keystone. That ticket
provides a workaround but still not all of the tests are working at the
moment. I think the goal is for tempest to become actively run but we
are not there
There is still a bug in tempest and/or keystone. To run Tempest and
devstack you have to:
1. Add catalog_name=compute to tempest.conf
2. Change name to type in rest_client.py
-David
On 2/27/2012 8:18 AM, Ionuț Arțăriși wrote:
On 02/22/2012 07:17 PM, Jay Pipes wrote:
On 02/22/2012 10:49
On 2/27/2012 3:02 PM, Dean Troyer wrote:
On Mon, Feb 27, 2012 at 10:13 AM, Daryl Walleck
daryl.wall...@rackspace.com wrote:
I'm working on updating this document as I'm using Devstack so that I can
either smooth
over or enumerate issues that may come up when running the tests. If you run
This is a great milestone and I was wondering about upgrade. At the last
design summit there was a discussion about how hard/easy it would be to
upgrade to Essex. What is the final answer? Are their (going to be)
instructions on how to upgrade an operating diablo cluster to essex? And
is the
A while back I saw a comment about this in
http://mirantis.blogspot.com/2011/06/openstack-nova-basic-disaster-recovery.html
which suggests that setting these flags may not always be a good idea.
If this is what should be done, why are these flags false by default?
Perhaps a nova expert can
In the spirit of Jay's message, we have a long-running cluster
(diablo/kvm) where about once every 3-4 weeks a user will complain that
she cannot connect to a vm. Examining the compute node shows that
libvirt-bin is hung. Sometimes restarting this process fixes the
problem. Sometimes it does
In case any one runs into this, there is a bug in the Precise upstart
package that causes a reboot after installing essex to result in a
kernel panic. I don't know exactly what in the openstack install process
triggers it but there is a PPA mentioned in comment #11 of this bug
ticket that
In a diablo/kvm cluster that has been running for a long time, a user
reported problems with some vms, tried rebooting them and eventually
deleted them. I recently noticed messages in the nova compute log like:
Found 13 in the database and 10 on the hypervisor.
Looking at the source code I
on the offending
instances
Are u using euca tools ? some inconsistencies are generated by them often
Regards
Lean
On Tue, Mar 20, 2012 at 12:19 PM, David Kranz david.kr...@qrclab.com
mailto:david.kr...@qrclab.com wrote:
In a diablo/kvm cluster that has been running for a long time
Thanks, Jay. I agree with your comments about Essex. The problem is that
I have cleaned up after a number of operational problems in a cluster
that has been up for 3 months. It is hard to reproduce these problems
when the mean time to failure is so long, and real investigation can be
dangerous
This is, indeed, the crux of the matter. The release cycle, for both
diablo and essex, has been that all kinds of incompatible changes are
made right until
the end. During the critical month before release when we need as many
people ad possible to deploy and test real clusters, documentation
If you are trying out Essex on a single node, beware of bug
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/959426
nova services start before mysql on boot
-David
___
Mailing list: https://launchpad.net/~openstack
Post to :
There seems to be an unfortunate difference in opinion out there about
whether the keystone endpoints should be defined using templates
(devstack) or keystone calls (ubuntu). I don't know why keystone is
offering two very different, but seemingly functionally identical, ways
to do this. Is
to change the default backend to SQL,
since most users are looking for the CLI management commands out of
the box:
https://review.openstack.org/#change,5821
-Dolph
On Mon, Mar 26, 2012 at 8:29 AM, David Kranz david.kr...@qrclab.com
mailto:david.kr...@qrclab.com wrote:
There seems
On 3/29/2012 12:46 PM, Justin Santa Barbara wrote:
Is there a good way to map back where in the code these calls are
coming from?
There's not a great way currently. I'm trying to get a patch in for
Essex which will let deployments easily turn on SQL debugging (though
this is
I am also having problems with vnc console but not using dashboard and
of a different kind. First, the documentation says to use the vnc_redux
branch but that is evidently diablo-compatible code. So I used master
and did the same thing as devstack does (I think) and I can get a console
references to
vnc_redux (thanks for bringing that to my attention).
https://review.openstack.org/6002
In the FAQ I also mention the python-numpy noVNC dependency, which
appears to be biting you.
A
On Fri, Mar 30, 2012 at 7:56 AM, David Kranz david.kr...@qrclab.com
mailto:david.kr...@qrclab.com
+1000
I believe the nova team should make backporting essential bugs to a
stable essex base and dealing with the upgrade issue the highest
priority for the start (at least) of the Folsom cycle. We need people to
deploy real systems using Essex. With regard to smooth upgrades, they
won't
This is a really great list! With regard to cluster health and
monitoring, I did a bunch of stuff with Swift before turning to nova and
really appreciated the
way each swift service has a healthcheck call that can be used by a
monitoring system. While I don't think providing a production-ready
operational problem
occurred (disk ran out of space, etc.). Right now errors are sometimes
output for other
reasons such as bad arguments to api calls. This makes it difficult for
an operator to know when a real problem with the system has occurred.
David Kranz
Quanta Research Cambridge
On 4/12/2012
As far as my experience goes, you have to use %(tenant_id)s. I ran into
this problem the first time I did it as well. $ makes the shell think
it's a variable.
David Kranz
Quanta Research Cambridge
On 4/13/2012 9:28 AM, Guilherme Birk wrote:
I've tried to execute the following command
I ran into this a few hours ago. It seems you have to do
glance-manage version_control 0
glance-manage db_sync
before restarting glance-registry. After I did that all was well.
-David
On 4/13/2012 5:03 PM, Lee Thompson wrote:
Fresh install or upgraded install, glance-registry fails.
There was a swift talk at the design summit that is related to (a):
http://etherpad.openstack.org/FolsomSwiftStatsd.
There is a good summary in the referenced blog post:
http://www.swiftstack.com/blog/2012/04/11/swift-monitoring-with-statsd/
-David
On 5/2/2012 4:19 AM, Mark McLoughlin wrote:
The OpenStack QA Team holds public weekly meetings in
#openstack-meeting, Thursday at 13:00 EST (17:00 UTC). Everyone
interested in testing, quality assurance, performance engineering, etc,
should attend!
Agenda for next meeting
* Review of last week's action items
(jaypipes) Get
The QA team had its weekly IRC meeting today. Here is a summary of the
progress and decisions coming out of the meeting.
* Progress
There were a bunch of problems that were preventing the tempest gating
job from running successfully. The last (:-) ) problem was identified.
We hope to turn
The weekly QA Team meeting takes place at 17:00 UTC on IRC
(#openstack-meeting on Freenode). We invite anyone interested in
testing, quality assurance and performance engineering to attend the
weekly meeting.
The agenda for this week is as follows:
* Review of last week's action items
-
On 5/31/2012 2:10 PM, Vishvananda Ishaya wrote:
On May 25, 2012, at 2:36 AM, John Garbutt wrote:
I have been meaning to draft a blueprint around this.
What we have today:
·Migrate: move a VM from one server to another, reboots across the
move (I think) and destination is picked by scheduler
to vm state. There
is also a state transition diagram in dot format.
Comments welcome. Thanks,
All
On Mon, Jun 18, 2012 at 12:26 PM, Jay Pipesjaypi...@gmail.com wrote:
On 06/18/2012 12:01 PM, David Kranz wrote:
There are a few tempest tests, and many in the old kong suite that is
still
An assumption is being made here that the user and cloud provider
are unrelated. But I think there are many projects under development
where a cloud-based service is being provided on top of an OpenStack
infrastructure. In that use case, the direct user of OpenStack APIs and
the cloud provider
An excellent idea. I believe that if the below message had been sent in
April, the tenor of the discussion would have been much different. I
think a main source of angst around this was that there was no mention
at the Folsom summit of nova-volume being simply removed immediately,
except
I am a bit ignorant about image formats and such. The size of the Ubuntu
precise cloud image at
http://uec-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img
is about 221Mb. If I boot that image with flavor m1.tiny and use
image-create I get an image that is 2Gb. If I do
I share Doug's concerns but would state some more strongly. IMO, it is
simply unacceptable to modify user-visible behavior based on whether
some package that happens to be used in an implementation is installed
or not. This package is installed on Ubuntu by default and may be used
by other
It is a little strange but the following seems to be true.
1. The nova HTTP API has a max_count and min_count that go in the
request dictionary.
2. This is not documented.
3. The novaclient python api create function has these arguments.
4. The novaclient cli does not have them, or at least
On 9/24/2012 9:38 PM, Chuck Short wrote:
Hi
On 12-09-24 07:39 PM, Sam Morrison wrote:
Hi,
I've started using the Ubuntu Cloud Archive packages for Folsom in
Precise.
Haven't been able to find out much information about them so I'm
asking here.
I've found the packages have quite a few bugs
On 9/26/2012 2:55 AM, Girija Sharan wrote:
Hello all,
I am using Tempest *stable/essex* not master. And in stable/essex
there are very less number of tests as compared to tests in master.
Would you please suggest me which one should I use.
One important thing is that in master version there
I am really confused about this. There are two pages that suggest the
cloud archive is ready to use:
http://blog.canonical.com/2012/09/14/now-you-can-have-your-openstack-cake-and-eat-it/
https://wiki.ubuntu.com/ServerTeam/CloudArchive
What they tell you to put in /etc/apt/sources.list is
On 10/30/2012 12:43 PM, Renier Morales wrote:
Hello,
I'm wondering if someone has already created a nova paste
filter/middleware for enabling Cross-Origin Resource Sharing (CORS),
allowing a web page to access the openstack api from another domain.
Any pointers out there?
Thanks,
ServerActionsTestBase is not the test class. You have to use
ServerActionsTestJSON (or XML).
Look at the bottom of
https://github.com/openstack/tempest/blob/master/tempest/tests/compute/servers/test_server_actions.py
-David
On 11/9/2012 8:04 PM, Stef T wrote:
Hey Ravi,
Cool, and how do
Sometimes when I boot a bunch of vms seconds apart, using the key_name
argument, some instance will not have its key injected.
I found a bug ticket marked won't fix with a comment from Vish that
key injection was for developer convenience[1]. Of course
the personality argument could also be
Ishaya wrote:
Key name is the recommended method, but injecting it into the guest is not. The
key should be downloaded from the metadata server using a guest process like
cloud-init.
Vish
On Jan 11, 2013, at 10:20 AM, David Kranz david.kr...@qrclab.com wrote:
Sometimes when I boot a bunch
Now that we are at feature freeze, is there a description of
incompatible configuration or api changes that happened since Folsom?
That is, a description of how deploying grizzly differs from deploying
folsom.
-David
On 2/22/2013 7:21 AM, Thierry Carrez wrote:
Martinx - ジェームズ wrote:
The Tempest (QA) team certainly considers them to be public and we just
started getting some contributions that are testing novaclient. In other
work I am also a consumer of several of these APIs so I really hope they
don't break.
-David
On 3/1/2013 8:50 AM, Dolph Mathews wrote:
I believe
Due to some bugs in nova it can happen that a vm fails to start and, due
to another bug, 'nova delete' will not delete it. There was a mention
somewhere that you have to manually remove it from the database but I am
not sure exactly what command will do that. Can some one help me out?
-David
In tracking down a problem with the tempest flavors test I noticed that
'nova flavor-list' returns this in Essex:
++---+---+--+--+---+-+
| ID |Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor |
There are a bunch of tests that fail in diablo because they expect a
particular 4xx response code and that code is different in diablo and
essex. I have checked in some fixes for this by making the test less
rigid about which 4xx code it gets but there are still more I have to
deal with. I am
On 2/24/2012 2:30 PM, Jay Pipes wrote:
Nice job, David! Keep up the good work. I approved that skipper for
the bug so we should be getting close now.
Going to get to the remaining reviews now.
Cheers,
-jay
OK, great. If you create a stable-diablo branch I can get those tests in
shape as
I have filed nova bugs for all the failures in diablo/stable and posted
the changes to make everything pass except for the glance dependency
which is covered by https://bugs.launchpad.net/tempest/+bug/944410. We
decided to make the negative tests (that fail due to a wrong error code)
succeed
Never mind the last one. That was because I don't have two images. That
test should be skipped in that case.
On 3/23/2012 12:18 PM, Jay Pipes wrote:
On 03/23/2012 11:51 AM, David Kranz wrote:
I am getting the following failure on a new essex cluster using Ubuntu
packages. It seems 404
I submitted a fix for the markers problem on the essex stable branch and
now all the tests (almost) pass using the real essex release. The only
issue was a non-reproducible failure. I ran this a dozen more times and
did not see it again :-( . So be on the watch for this.
On 5/7/2012 2:29 PM, Venkatesan, Ravikumar wrote:
On 5/4/2012 9:08 AM, Jay Pipes wrote:
On 05/04/2012 06:14 AM, Karajgi, Rohit wrote:
Hi,
What is the policy that we should or are following for test cases that
fail due to an existing Open Bug in Launchpad?
For eg:
where the test cases take a long
time
c) Consider which, if any, cases it would make sense to use a pool of
pre-allocated servers rather than spinning up new ones for each test.
-David
On Jun 1, 2012, at 4:03 PM, David Kranz wrote:
I am a little confused about this. Most test classes
There are a few tempest tests, and many in the old kong suite that is
still there, that wait for a server status that is something other than
ACTIVE or VERIFY_RESIZE. These other states, such as BUILD or REBOOT,
are transient so I don't understand why it is correct for code to poll
for those
On 6/18/2012 1:07 PM, Jay Pipes wrote:
On 06/18/2012 12:49 PM, Daryl Walleck wrote:
I can verify that rescue is a non-race state. The transition is active
to rescue on setting rescue, and rescue to active when leaving rescue.
I don't see a RESCUE state. I see a RESCUED state. Is that what you
Daryl, I agree. I sent this message after seeing some more soft reboot
tests being posted. What I meant was that we should limit soft reboot
tests to the ones that are testing that functionality specifically, as
opposed to tests that try to do something or other during reboot.
-David
On
As of a few hours ago the tempest gate is unblocked. However, it seems
that all the pending changes need to be rebased.
-David
--
Mailing list: https://launchpad.net/~openstack-qa-team
Post to : openstack-qa-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-qa-team
I heard from some of my team members that test_server_basic_ops and
test_server_advanced_ops were failing and I can reproduce it with
current devstack/tempest.
Looking at the code it seems that the keystone Client object does not
have a service_catalog object like the error says. So why is this
On 9/25/2012 10:35 AM, Jay Pipes wrote:
On 09/25/2012 09:38 AM, David Kranz wrote:
I heard from some of my team members that test_server_basic_ops and
test_server_advanced_ops were failing and I can reproduce it with
current devstack/tempest.
Looking at the code it seems that the keystone
Folks, there are already a number of proposals for sessions that can be
seen at http://summit.openstack.org/. I will be reviewing them early
next week so I encourage any one who wants to lead a session, or has a
topic that should be discussed, to make a proposal at that page. If you
want to
We discussed this a bit at the meeting today. Monty has proposed a
session on the QA track about parallelizing some of the CI stuff. He
believes tempest could share the parallelization code. See
http://summit.openstack.org/cfp/details/69.
Parallelizing the tempest gate job is as much of a ci
we're trying to address.
Daryl
From: openstack-qa-team-bounces+daryl.walleck=rackspace@lists.launchpad.net
[openstack-qa-team-bounces+daryl.walleck=rackspace@lists.launchpad.net] on
behalf of David Kranz [david.kr...@qrclab.com]
Sent: Thursday
at 9:35 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On 09/25/2012 09:38 AM, David Kranz wrote:
I heard from some of my team members that test_server_basic_ops and
test_server_advanced_ops were failing and I can reproduce it with
current devstack/tempest
.
On 09/28/2012 11:51 AM, David Kranz wrote:
This was the problem (trivial) https://review.openstack.org/#/c/13840/.
Some one please review.
I am not sure when the behavior changed.
-David
On 9/25/2012 10:59 AM, Dolph Mathews wrote:
That generally pops up when you're bypassing authentication
It was recently discovered that the gating job was not running tests
with no @attr. One of the tests that was not being run as a result of
this is broken in at least its XML component. It would be great if one
of the folks who worked on the XML stuff could pick this up soon:
As of late yesterday, the full tempest gate is running all tempest
tests. Not surprisingly, there are some failures in the tests that have
just started running. Most of the problems seem to be due to some recent
change
in the keystone client but there may be others. We are working to get it
There is now a full tempest run going daily and reporting failures to
this list. But that won't work because
jenkins and gerrit cannot be launchpad members. According to the ci
folks, others have dealt with this
by moving their mailing lists to lists.openstack.org. Perhaps we should
do the
75 matches
Mail list logo
