Re: [Openstack] Are the Python APIs public or internal?
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 they should certainly be treated as public API's -- just like any other library. I'd also treat them as stable if they've ever been included in a versioned release. That said, I'm sure it would be easy to find examples of methods attributes within the library that are not intended to be consumed externally, but perhaps either the naming convention or documentation doesn't sufficiently indicate that. In keysoneclient, we're making backwards incompatible changes in a new subpackage (keystoneclient.v3) while maintaing compatibility in the common client code. For example, you should always be able to initialize the client with a tenant_id / tenant_name, even though the client will soon be using project_id / project_name internally to reflect our revised lingo. -Dolph On Thu, Feb 28, 2013 at 11:07 PM, Lorin Hochstein lo...@nimbisservices.com mailto:lo...@nimbisservices.com wrote: Here's an issue that came up in the operators doc sprint this week. Let's say I wanted to write some Python scripts using the APIs exposed by the python-*client packages. As a concrete example, let's say I wrote a script that uses the keystone Python API that's exposed in the python-keystoneclient package: https://github.com/lorin/openstack-ansible/blob/master/playbooks/keystone/files/keystone-init.py Are these APIs public or stable in some meaningful way? (i.e., can I count on this script still working across minor release upgrades)? Or should they be treated like internal APIs that could be changed at any time in the future? Or is this not defined at all? Lorin ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Grizzly-3 development milestone available (Keystone, Glance, Nova, Horizon, Quantum, Cinder)
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: What is the status of Openstack Grizzly-3 Ubuntu packages? Can we already set it up using apt-get / aptitude? With packaged Heat, Ceilometer and etc? Which version is recommended to test Grizzly-3, Precise (via testing UCA), Raring? Is Grizzly planed to be the default Openstack for Raring? I suspect it will take a few days for grizzly-3 to appear in Ubuntu, as the tarballs were cut a few hours ago. As far as I know, Grizzly is indeed the planned default OpenStack for Raring. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Key injection failure on boot
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 used to inject the file. This is odd because key_name is a documented part of nova client, as the files mechanism. So what is the recommended way to do what the key_name argument is documented to do? I think if key_name is not intended to work it should be removed from nova client. -David [1] https://bugs.launchpad.net/nova/+bug/967994 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Key injection failure on boot
Thanks Vish, but I am still a little confused. I am using an ubuntu precise cloudimg and normally when I pass a keyname to boot, the public key shows up in ~ubuntu/.ssh/authorized_keys. Looking at the console log, I presume it is the guest cloud-init that is doing that. But sometimes not. This has to be a bug some where even if it is not in nova. There is a lot of mechanism here that I don't understand. If there is documentation some where about exactly how to use metadata to install an ssh key I can't find it. Do you have any more advice? -David On 1/11/2013 1:32 PM, Vishvananda 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 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 used to inject the file. This is odd because key_name is a documented part of nova client, as the files mechanism. So what is the recommended way to do what the key_name argument is documented to do? I think if key_name is not intended to work it should be removed from nova client. -David [1] https://bugs.launchpad.net/nova/+bug/967994 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Tempest] unable to run subset of tests via nosetests
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 you run (say) only test_reboot_server_hard from
ServerActionsTestBase ?
Whenever I try, I get;
stack@DevStack:~/tempest$ nosetests -sv
tempest.tests.compute.servers.test_server_actions.py:ServerActionsTestBase.test_reboot_server_hard
The server should be power cycled ... ERROR
==
ERROR: The server should be power cycled
--
Traceback (most recent call last):
File /usr/lib/pymodules/python2.7/nose/case.py, line 371, in setUp
try_run(self.inst, ('setup', 'setUp'))
File /usr/lib/pymodules/python2.7/nose/util.py, line 478, in try_run
return func()
File
/opt/stack/tempest/tempest/tests/compute/servers/test_server_actions.py,
line 39, in setUp
resp, server = self.client.create_server(self.name,
AttributeError: 'ServerActionsTestBase' object has no attribute 'client'
begin captured logging
tempest.config: INFO: Using tempest config file
/opt/stack/tempest/etc/tempest.conf
tempest.tests.compute: DEBUG: Entering tempest.tests.compute.setup_package
- end captured logging -
On 11/09/2012 07:16 PM, Venkatesan, Ravikumar wrote:
Test_server_actions.py
~/openstack_projects/tempest$ nosetests -sv
tempest/tests/compute/servers/test_server_actions.py
The server's password should be set to the provided password ...
SKIP: Change password not available.
Negative Test: The server reboot on non existent server should return
... ok
The server should be power cycled ... ok
The server should be signaled to reboot gracefully ... SKIP: Until
bug 1014647 is dealt with.
Negative test: The server rebuild for a non existing server should
not ... ok
The server should be rebuilt using the provided image and data ... ok
The server's RAM and disk space should be modified to that of ...
SKIP: Resize not available.
The server's RAM and disk space should return to its original ...
SKIP: Resize not available.
The server's password should be set to the provided password ...
SKIP: Change password not available.
Negative Test: The server reboot on non existent server should return
... ok
The server should be power cycled ... ok
The server should be signaled to reboot gracefully ... SKIP: Until
bug 1014647 is dealt with.
Negative test: The server rebuild for a non existing server should
not ... ok
The server should be rebuilt using the provided image and data ... ok
The server's RAM and disk space should be modified to that of ...
SKIP: Resize not available.
The server's RAM and disk space should return to its original ...
SKIP: Resize not available.
--
Ran 16 tests in 127.553s
OK (SKIP=8)
Regards,
Ravi
*From:*openstack-bounces+ravikumar.venkatesan=hp@lists.launchpad.net
[mailto:openstack-bounces+ravikumar.venkatesan=hp@lists.launchpad.net]
*On Behalf Of *Venkatesan, Ravikumar
*Sent:* Friday, November 09, 2012 4:13 PM
*To:* Stef T; openstack@lists.launchpad.net
*Subject:* Re: [Openstack] [Tempest] unable to run subset of tests
via nosetests
To run a single test from Tempest:
~/openstack_projects/tempest$ nosetests -sv
tempest/tests/compute/flavors/test_flavors.py
The expected flavor details should be returned ... ok
Ensure 404 returned for non-existant flavor ID ... ok
flavor details are not returned for non existant flavors ... ok
List of all flavors should contain the expected flavor ... ok
The detailed list of flavors should be filtered by disk space ... ok
The detailed list of flavors should be filtered by RAM ... ok
Only the expected number of flavors (detailed) should be returned ... ok
The list of flavors should start from the provided marker ... ok
The list of flavors should be filtered by disk space ... ok
The list of flavors should be filtered by RAM ... ok
Only the expected number of flavors should be returned ... ok
The list of flavors should start from the provided marker ... ok
Detailed list of all flavors should contain the expected flavor ... ok
The expected flavor details should be returned ... ok
Ensure 404 returned for non-existant flavor ID ... ok
flavor details are not returned for non existant flavors ... ok
List of all flavors should contain the expected flavor ... ok
The detailed list of flavors should be filtered by disk space ... ok
The detailed list of flavors should be filtered by RAM ... ok
Only the expected number of flavors (detailed) should be returned ... ok
The list of flavors should start from the provided marker
[Openstack-qa-team] Need to change mailing list server?
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 same? We need to do something in any event. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova middleware for enabling CORS?
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, -Renier ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This https://review.openstack.org/#/c/6909/ was an attempt to add such middleware to swift. It is generic CORS support but seems to have been rejected in favor of putting CORS support in swift directly and checked in last week: https://github.com/openstack/swift/commit/74b27d504d310c70533175759923c21df158daf9 -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] When will the distro (specifically Ubuntu) have package for Folsom release
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 different, but both give errors like this after putting the lines in and doing 'apt-get update': Reading package lists... Done W: GPG error: http://ubuntu-cloud.archive.canonical.com precise-proposed/folsom Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5EDB1B62EC4926EA W: GPG error: http://ubuntu-cloud.archive.canonical.com precise-updates/folsom Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5EDB1B62EC4926EA u Can any one in the know explain what the real story about this? Or am I just doing something wrong? -David On 10/1/2012 1:20 PM, Nathanael Burton wrote: From the release notes: http://wiki.openstack.org/ReleaseNotes/Folsom#Ubuntu_12.04_.2BAC8_Ubuntu_12.10 On Oct 1, 2012 1:17 PM, Matt Joyce matt.jo...@cloudscaling.com mailto:matt.jo...@cloudscaling.com wrote: I am not sure indecently was the word you were looking for there. But I gather you are asking if Ubuntu is packaging folsom on their own (as in it's not part of openstack). So yes, Ubuntu is packaging folsom on their own. And I assume ubuntu will let people know when they are done packaging. They tend to be pretty good about that sort of thing. -Matt On Mon, Oct 1, 2012 at 10:02 AM, Ahmed Al-Mehdi ah...@coraid.com mailto:ah...@coraid.com wrote: Hello, Does anybody know when will the distress, specifically Ubuntu, have packages for the OpenStack Folsom release. Is this effort done indecently of OpenStack by Ubuntu and the release date will be mentioned on Ubuntu's website? Regards, Ahmed. ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Tempest gate is not working
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 back up as quickly as possible. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Tempest gate situation
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: https://bugs.launchpad.net/tempest/+bug/1059568. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] What is going on with test_server_*_ops?
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 using --endpoint --token (no authentication == no service catalog). Is it using old command line options to specify auth attributes, which were just removed in favor of --os-username, --os-password, etc? https://github.com/openstack/python-keystoneclient/commit/641f6123624b6ac89182c303dfcb0459b28055a2 -Dolph On Tue, Sep 25, 2012 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. 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 not failing the tempest build? Looking at the transcript of a recent successful build I don't see any evidence that this test is running but I don't know why that would be. -David == ERROR: test suite for class 'tempest.tests.compute.test_server_basic_ops.TestServerBasicOps' -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/suite.py, line 208, in run self.setUp() File /usr/lib/python2.7/dist-packages/nose/suite.py, line 291, in setUp self.setupContext(ancestor) File /usr/lib/python2.7/dist-packages/nose/suite.py, line 314, in setupContext try_run(context, names) File /usr/lib/python2.7/dist-packages/nose/util.py, line 478, in try_run return func() File /opt/stack/tempest/tempest/test.py, line 39, in setUpClass cls.manager = cls.manager_class() File /opt/stack/tempest/tempest/manager.py, line 96, in __init__ self.image_client = self._get_image_client() File /opt/stack/tempest/tempest/manager.py, line 138, in _get_image_client endpoint = keystone.service_catalog.url_for(service_type='image', AttributeError: 'Client' object has no attribute 'service_catalog' I wouldn't be surprised if this is due to a change in python-keystoneclient. Dolph, was anything changed recently that might have produced this failure? Thanks, -jay -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] What is going on with test_server_*_ops?
Thanks, Jay. But this now confirms that test_server_basic_ops is not running in the gating job. But it does run when I do 'nosetests -v tempest' in my local environment. How could this be? -David Nothing in the gate log, but this in my local: test_001_create_keypair (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_002_create_security_group (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_003_boot_instance (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_004_wait_on_active (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_005_pause_server (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_006_unpause_server (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_007_suspend_server (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_008_resume_server (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok test_099_terminate_instance (tempest.tests.compute.test_server_basic_ops.TestServerBasicOps) ... ok On 9/28/2012 12:12 PM, Jay Pipes wrote: Approved and merged. 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 using --endpoint --token (no authentication == no service catalog). Is it using old command line options to specify auth attributes, which were just removed in favor of --os-username, --os-password, etc? https://github.com/openstack/python-keystoneclient/commit/641f6123624b6ac89182c303dfcb0459b28055a2 -Dolph On Tue, Sep 25, 2012 at 9:35 AM, Jay Pipesjaypi...@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. 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 not failing the tempest build? Looking at the transcript of a recent successful build I don't see any evidence that this test is running but I don't know why that would be. -David == ERROR: test suite forclass 'tempest.tests.compute.test_server_basic_ops.TestServerBasicOps' -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/suite.py, line 208, in run self.setUp() File /usr/lib/python2.7/dist-packages/nose/suite.py, line 291, in setUp self.setupContext(ancestor) File /usr/lib/python2.7/dist-packages/nose/suite.py, line 314, in setupContext try_run(context, names) File /usr/lib/python2.7/dist-packages/nose/util.py, line 478, in try_run return func() File /opt/stack/tempest/tempest/test.py, line 39, in setUpClass cls.manager = cls.manager_class() File /opt/stack/tempest/tempest/manager.py, line 96, in __init__ self.image_client = self._get_image_client() File /opt/stack/tempest/tempest/manager.py, line 138, in _get_image_client endpoint = keystone.service_catalog.url_for(service_type='image', AttributeError: 'Client' object has no attribute 'service_catalog' I wouldn't be surprised if this is due to a change in python-keystoneclient. Dolph, was anything changed recently that might have produced this failure? Thanks, -jay -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Regarding Tempest for Integration testing of Openstack Environment
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 are couple of tests in network directory but there are no such tests in stable/essex. Please explain little bit about purpose of these tests. Actually I want to test Quantum networks. Will these tests in Tempest master be sufficient for that ?? Thanks and Regards, Girija Sharan Singh Tempest stable/essex is tracking the stable/essex releases of the projects being tested. It is basically the state of tempest as of when essex was released with a few updates after that. The main line of tempest work since then has been on master which is why there are a lot more tests. You should use master. A number of people are working on tempest/quantum testing. There was a discussion a week or two ago based on this http://etherpad.openstack.org/quantum-tempest. I suggest you coordinate with those folks so as to not duplicate effort. -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Proposals for the Design Summit QA track
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 propose a session topic, but are not going to be at the summit, please contact me. Remember that these sessions are not presentations with slides, but are intended to be discussions of current or future QA-related work or processes. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] PyVows proof of concept
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 issue as a tempest issue and working with them, and their proposal, could make things much easier for us IMO. -David On 9/27/2012 8:10 PM, Daryl Walleck wrote: I agree on the issue with the output from generated tests. That is troublesome, but from what I've seen in the source code, probably something that could be remedied. It's also very generous in it's parallel execution which is fine client-side, but can overwhelm a test environment since there's no configuration to throttle back the number of tests being executed at a time. Unfortunately I haven't seen a Python test runner that meets all the criteria that I'd like to have, thus this and other little proof of concepts I've been tossing around to see if any better approaches are out there. 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 Jaroslav Henner [jhen...@redhat.com] Sent: Monday, September 24, 2012 7:28 AM To: openstack-qa-team@lists.launchpad.net Subject: [Openstack-qa-team] PyVows proof of concept In reply to: https://lists.launchpad.net/openstack-qa-team/msg00236.html, which didn't came to my mailbox for some reason (attachment?) I tried pyVows myself. I kinda liked the concept, but I didn't like the way it is reporting to JUnit format XML when using generative testing: http://heynemann.github.com/pyvows/#-using-generative-testing In Jenkins, it looked like: Test Result : Add - should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed The parameters to the testing method are important when using generative testing, so I think they should be included in the name of the test. But some funny characters like ()%* I don't remember which are causing problems in Jenkins. I was investigating some problems with them months ago with some other testing framework. I don't know how to address this problem. It may be worthy to consider making some Robot framework outputs plugin if generative testing is needed, or use Robot Framework https://wiki.jenkins-ci.org/display/JENKINS/Robot+Framework+Plugin J.H. -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] PyVows proof of concept
Agreed. Daryl, is there a list of these issues some where? On 9/27/2012 10:54 PM, Daryl Walleck wrote: I'm certainly all for anything that makes things easier. However, I do want to make sure that if we migrate runners, we should make sure that the new implementation solves all the issues 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, September 27, 2012 8:11 PM To: openstack-qa-team@lists.launchpad.net Subject: Re: [Openstack-qa-team] PyVows proof of concept 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 issue as a tempest issue and working with them, and their proposal, could make things much easier for us IMO. -David On 9/27/2012 8:10 PM, Daryl Walleck wrote: I agree on the issue with the output from generated tests. That is troublesome, but from what I've seen in the source code, probably something that could be remedied. It's also very generous in it's parallel execution which is fine client-side, but can overwhelm a test environment since there's no configuration to throttle back the number of tests being executed at a time. Unfortunately I haven't seen a Python test runner that meets all the criteria that I'd like to have, thus this and other little proof of concepts I've been tossing around to see if any better approaches are out there. 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 Jaroslav Henner [jhen...@redhat.com] Sent: Monday, September 24, 2012 7:28 AM To: openstack-qa-team@lists.launchpad.net Subject: [Openstack-qa-team] PyVows proof of concept In reply to: https://lists.launchpad.net/openstack-qa-team/msg00236.html, which didn't came to my mailbox for some reason (attachment?) I tried pyVows myself. I kinda liked the concept, but I didn't like the way it is reporting to JUnit format XML when using generative testing: http://heynemann.github.com/pyvows/#-using-generative-testing In Jenkins, it looked like: Test Result : Add - should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed should_be_numeric 0 msPassed The parameters to the testing method are important when using generative testing, so I think they should be included in the name of the test. But some funny characters like ()%* I don't remember which are causing problems in Jenkins. I was investigating some problems with them months ago with some other testing framework. I don't know how to address this problem. It may be worthy to consider making some Robot framework outputs plugin if generative testing is needed, or use Robot Framework https://wiki.jenkins-ci.org/display/JENKINS/Robot+Framework+Plugin J.H. -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Ubuntu Cloud Archive information
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 eg.[1]. So trying to figure out where to submit bugs for these and also where the sources are for these packages so I can fix them. You are doing it in the right place, please submit any bugs that you find in launchpad. Doe anyone know anything about these packages? What do you want to know? Chuck, we have been testing a system with ppa:openstack-ubuntu-testing/folsom-trunk-testing and I have two questions: 1. When will the release version of Folsom be available using the method described in https://wiki.ubuntu.com/ServerTeam/CloudArchive? 2. Will it be possible to upgrade a system using the test ppa to the final release in the CloudArchive (and, if so, how)? Thanks, David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] What is going on with test_server_*_ops?
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 not failing the tempest build? Looking at the transcript of a recent successful build I don't see any evidence that this test is running but I don't know why that would be. -David == ERROR: test suite for class 'tempest.tests.compute.test_server_basic_ops.TestServerBasicOps' -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/suite.py, line 208, in run self.setUp() File /usr/lib/python2.7/dist-packages/nose/suite.py, line 291, in setUp self.setupContext(ancestor) File /usr/lib/python2.7/dist-packages/nose/suite.py, line 314, in setupContext try_run(context, names) File /usr/lib/python2.7/dist-packages/nose/util.py, line 478, in try_run return func() File /opt/stack/tempest/tempest/test.py, line 39, in setUpClass cls.manager = cls.manager_class() File /opt/stack/tempest/tempest/manager.py, line 96, in __init__ self.image_client = self._get_image_client() File /opt/stack/tempest/tempest/manager.py, line 138, in _get_image_client endpoint = keystone.service_catalog.url_for(service_type='image', AttributeError: 'Client' object has no attribute 'service_catalog' -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] What is going on with test_server_*_ops?
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 Client object does not have a service_catalog object like the error says. So why is this not failing the tempest build? Looking at the transcript of a recent successful build I don't see any evidence that this test is running but I don't know why that would be. -David == ERROR: test suite forclass 'tempest.tests.compute.test_server_basic_ops.TestServerBasicOps' -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/suite.py, line 208, in run self.setUp() File /usr/lib/python2.7/dist-packages/nose/suite.py, line 291, in setUp self.setupContext(ancestor) File /usr/lib/python2.7/dist-packages/nose/suite.py, line 314, in setupContext try_run(context, names) File /usr/lib/python2.7/dist-packages/nose/util.py, line 478, in try_run return func() File /opt/stack/tempest/tempest/test.py, line 39, in setUpClass cls.manager = cls.manager_class() File /opt/stack/tempest/tempest/manager.py, line 96, in __init__ self.image_client = self._get_image_client() File /opt/stack/tempest/tempest/manager.py, line 138, in _get_image_client endpoint = keystone.service_catalog.url_for(service_type='image', AttributeError: 'Client' object has no attribute 'service_catalog' I wouldn't be surprised if this is due to a change in python-keystoneclient. Dolph, was anything changed recently that might have produced this failure? Thanks, -jay That is probably so but even when that is verified, I am still concerned that I see this with a fresh checkout of devstack/tempest but this is not failing jenkins runs. How could that happen? -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Need to rebase
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 More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Nova] Create multiple instances in one request
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 they are not documented by 'nova help boot'. Beats me why this is the case... -David On 8/7/2012 1:47 PM, Patrick Petit wrote: Dear All, Looking into the details of the request_spec part of a RPC message ensuing a nova boot command. There is a 'num_instances' : 1 property that implies the value could be different than one (default) even though there is no cardinality parameter in nova boot nor in the API (unless I missed something big). So, I am curious to know: why is it there if we cannot create more than one instance at a time through the API, but more importantly is there a (secret) way to set that value different than 1 to tell the scheduler please create multiple instances of that type. Thanks in advance Patrick ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keyring support in openstack
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 applications that have nothing to do with OpenStack at all. The proposed behavior is biased towards a very simple use case of a single user with a password manually invoking commands at the shell. It is really up to the administrator of a machine with the client installed what the security policy should be. As Doug suggested, this change is a very small piece of an overall security architecture which is not well spelled out here. If we really want to go down this road there should be an environment variable that can be set to turn off this behavior for applications that do not want it. -David On 7/30/2012 9:31 AM, Doug Hellmann wrote: On Sun, Jul 29, 2012 at 1:37 AM, Bhuvaneswaran A bhu...@apache.org mailto:bhu...@apache.org wrote: Team, As per patch https://review.openstack.org/#/c/9497/ we are adding keyring support for openstack client. If password is not specified in command line or environment variable, the user is prompted to enter password. During this time, the password is stored in keyring. During next time, the password is read from keyring, instead of prompt. It is true, if password is not specified in command line or environment variable. This behavior is documented in this wiki page: http://wiki.openstack.org/KeyringSupport If you have any comments, please let us know. You've already answered several of my questions on the ticket, but I still have some usability concerns. How does the keyring system support a single person logging in using multiple user accounts? For example, if I have an admin account and a regular user, how do I switch between them based on the operations I need to perform? Is there a way to disable the behavior of having a password saved to a keyring for a particular user, without uninstalling the python-keyring package (and therefore disabling keyring support for all users)? The wiki mentions the password being saved using keyring.backend.UncryptedFileKeyring. Does that mean the password is saved in cleartext? Is the file protected in some way besides filesystem permissions? The mention of one backend implies that there are others. Should we give users a way to choose the backend, in case they have a preference? How does the use of the keyring affect scripting using the command line tool? Can a script access the keyring, or does it need to use the other options? In one review comment you mention a few desktop apps that know how to manipulate the keyring to manage its contents. What about remote access via ssh, where a desktop environment is not available? Does the keyring library include tools for manipulating the file, or do we need to build our own? If so, what tools would be needed? Doug ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Large image snapshots
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 the same with flavor m1.large the resulting image is 10Gb. Is there a way to create snapshots that don't result in huge images? -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
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 perhaps inside the session devoted to this subject which many could not attend. Stepping up a level, it is hard for a project to move from a developer-centric (no real customers) way of doing things to one driven by having real enterprise users/customers. I know this from past experience. At a certain point, we will have to live with APIs or code organizations that are sub-optimal because it is just too much of a burden on real users/operators to change them. Obviously some members of the community believe this tipping point was the Essex release. It is also inevitable that development will slow down by some measures as the cost of regressions rises and what George Reese called technical debt has to be repaid. Going forward, and this may be controversial, I think these kinds of issues would be best addressed by following these measures: 1. Require each blueprint that involves an API change or significant operational incompatibility to include a significant justification of why it is necessary, what the impact would be, and a plan for deprecation/migration. This justification should assume that the remedy will have to be applied to a large, running OpenStack system in its many possible variations, without having to shut down the system for some unknown amount of time. 2. Require such blueprints to be approved by a technical committee that includes a significant representation of users/operators. The tradeoffs can be difficult and need to be discussed. 3. The technical committee should declare that the bar for incompatible changes is high, and getting higher. Some might argue that this is too much of a burden and takes authority away from PTLs, but I think the statement of stability to the community (and others) would more than compensate for that. -David On 7/16/2012 8:04 AM, Sean Dague wrote: On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote: Excellent points. Let me make the following proposal: 1) Leave the code in nova-volume for now. 2) Document and test a clear migration path to cinder. 3) Take the working example upgrade to the operators list and ask them for opinions. 4) Decide based on their feedback whether it is acceptable to cut the nova-volume code out for folsom. +1 -Sean ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
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 may be the same entity. It would be really nice if when an application fires up an instance that enters the error state, there was an api that could get the reason why it failed with as much information as the OpenStack code that set the instance state to ERROR had. If we are concerned that such information is sensitive and a public provider might not want to give it all to users, this could be an admin-only API. There are many variations of how the information is controlled. -David If we are concerned that a public provider might not want to give some information to users, this could be an admin-only API. On 6/29/2012 11:40 AM, Day, Phil wrote: However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? I assume the philosophy is that the API has validated the request as far and it can, and returned any meaningful error messages, etc. Anything that fails past that point is something going wrong from the cloud provider and there is nothing the user could have done to avoid the error, so any additional information won't help them. However on the basis that up-front validation is seldom perfect, and things can change while a request is in flight I think that being able to tell a user that, for example, their request failed because the image was deleted before it could be downloaded would be useful. One approach might be to make the task_state more granular and use that to qualify the error. In general our users have found having the state shown as vm_state (task_state) was useful as it shows progress during things like building. Phil *From:*openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Davis *Sent:* 29 June 2012 12:45 *To:* Eoghan Glynn *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] Nova and asynchronous instance launching Right - examining the current state isn't a good way to determine what happened with one particular request. This is exactly one of the reasons some providers create Jobs for all actions. Checking the resource later to see why something bad happened is fragile since other opertaons might have happened since then, erasing any error message type of state info. And relying on event/error logs is hard since correlating one particular action with a flood of events is tricky - especially in a multi-user environment where several actions could be underway at once. If each action resulted in a Job URI being returned then the client can check that Job resource when its convinient for them - and this could be quite useful in both happy and unhappy situations. And to be clear, a Job doesn't necessarily need to be a a full new resource, it could (under the covers) map to a grouping of event logs entries but the point is that from a client's perspective they have an easy mechanism (e.g. issue a GET to a single URI) that returns all of the info needed to determine what happened with one particular operation. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com mailto:d...@us.ibm.com The more I'm around some people, the more I like my dog. *Eoghan Glynn egl...@redhat.com mailto:egl...@redhat.com* 06/29/2012 06:00 AM To Doug Davis/Raleigh/IBM@IBMUS cc openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com Subject Re: [Openstack] Nova and asynchronous instance launching Note that I do distinguish between a 'real' async op (where you really return little more than a 202) and one that returns a skeleton of the resource being created - like instance.create() does now. So the latter approach at least provides a way to poll on the resource status, so as to figure out if and when it becomes usable. In the happy-path, eventually the instance status transitions to ACTIVE and away we go. However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? For example even just an indication that failure occurred in the scheduler (e.g. resource starvation) or on the target compute node. Is the thought that such information may be operationally sensitive, or just TMI for a typical cloud user? Cheers, Eoghan ___ Mailing list:
Re: [Openstack-qa-team] Issues with soft reboot
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 6/19/2012 11:05 AM, Daryl Walleck wrote: Hi David, From a time perspective I see what you're saying. However, there's an important bit of functionality that is getting tested here: the fact that the soft reboot works regardless of hyper visor. I've always aimed to make Tempest hyper visor agnostic, and I would be hesitant to skip a valid test case. I think it's at least worth noting down as something we can revisit later, but I think there are other areas we can improve performance in first. Daryl Sent from my iPad On Jun 19, 2012, at 8:01 AM, David Kranzdavid.kr...@qrclab.com wrote: To help with the effort of making the Tempest suite run faster, we should avoid or skip the use of soft reboot in any tests, at least for now. The problem is that, according to Vish, soft reboot requires guest support. If the booted image doesn't have it, compute will wait (two minutes by default), and do a hard reboot. So right now almost all tests that do a soft reboot will take at least 150 seconds or so and will not actually be testing anything useful. There should be a soft reboot test that uses an image with guest support. -David References: https://bugs.launchpad.net/nova/+bug/1013747 https://bugs.launchpad.net/tempest/+bug/1014647 -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-qa-team] wait_for_server_status and Compute API
Thanks, Yun. The problem is that the API calls give you status which is neither task state nor vm state. I think these are the stable states: ACTIVE, VERIFY_RESIZE, STOPPED, SHUTOFF, PAUSED, SUSPENDED, RESCUE, ERROR, DELETED Does that seem right to you, and is there a plan to change that set for Folsom? -David On 6/18/2012 12:51 PM, Yun Mao wrote: Hi Jay et al, there is a patch in review here to overhaul the state machine: https://review.openstack.org/#/c/8254/ All transient state in vm state will be moved to task state. Stable state in task state (RESIZE_VERIFY) will be moved 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 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 states. Am I missing something or do those tests have race condition bugs? No, you are correct, and I have made some comments in recent code reviews to that effect. Here are all the task states: https://github.com/openstack/nova/blob/master/nova/compute/task_states.py Out of all those task states, I believe the only one safe to poll in a wait loop is RESIZE_VERIFY. All the others are prone to state transitions outside the control of the user. For the VM states: https://github.com/openstack/nova/blob/master/nova/compute/vm_states.py I consider the following to be non-racy, quiescent states: ACTIVE DELETED STOPPED SHUTDOFF PAUSED SUSPENDED ERROR I consider the following to be racy states that should not be tested for: MIGRATING -- Instead, the final state should be checked for... RESIZING -- Instead, the RESIZE_VERIFY and RESIZE_CONFIRM task states should be checked I have absolutely no idea what the state termination is for the following VM states: RESCUED -- is this a permanent state? Is this able to be queried for in a consistent manner before it transitions to some further state? SOFT_DELETE -- I have no clue what the purpose or queryability of this state is, but would love to know... Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] wait_for_server_status and Compute API
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 states. Am I missing something or do those tests have race condition bugs? -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] wait_for_server_status and Compute API
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
are referring to here? Want to make sure, since the semantics and
tenses of the power, VM, and task states are a bit inconsistent.
Best,
-jay
-
For a black-box test what we have is 'status', which is neither vm-state
not task state. I believe 'status' contains the values of the
attributes in the below code. I am going to add an assertion to
wait_for_server_status that will fail if you give it an ephemeral state.
From this list and the comments of Daryl and Jay, I propose the list of
allowed states for this check:
ACTIVE, VERIFY_RESIZE, STOPPED, SHUTOFF, PAUSED, SUSPENDED, RESCUE,
ERROR, DELETED
Any comments?
From nova/nova/api/openstack/common.py:
_STATE_MAP = {
vm_states.ACTIVE: {
'default': 'ACTIVE',
task_states.REBOOTING: 'REBOOT',
task_states.REBOOTING_HARD: 'HARD_REBOOT',
task_states.UPDATING_PASSWORD: 'PASSWORD',
task_states.RESIZE_VERIFY: 'VERIFY_RESIZE',
},
vm_states.BUILDING: {
'default': 'BUILD',
},
vm_states.REBUILDING: {
'default': 'REBUILD',
},
vm_states.STOPPED: {
'default': 'STOPPED',
},
vm_states.SHUTOFF: {
'default': 'SHUTOFF',
},
vm_states.MIGRATING: {
'default': 'MIGRATING',
},
vm_states.RESIZING: {
'default': 'RESIZE',
task_states.RESIZE_REVERTING: 'REVERT_RESIZE',
},
vm_states.PAUSED: {
'default': 'PAUSED',
},
vm_states.SUSPENDED: {
'default': 'SUSPENDED',
},
vm_states.RESCUED: {
'default': 'RESCUE',
},
vm_states.ERROR: {
'default': 'ERROR',
},
vm_states.DELETED: {
'default': 'DELETED',
},
vm_states.SOFT_DELETE: {
'default': 'DELETED',
},
}
def status_from_state(vm_state, task_state='default'):
Given vm_state and task_state, return a status string.
task_map = _STATE_MAP.get(vm_state, dict(default='UNKNOWN_STATE'))
status = task_map.get(task_state, task_map['default'])
LOG.debug(Generated %(status)s from vm_state=%(vm_state)s
task_state=%(task_state)s. % locals())
return status
def vm_state_from_status(status):
Map the server status string to a vm state.
for state, task_map in _STATE_MAP.iteritems():
status_string = task_map.get(default)
if status.lower() == status_string.lower():
return state
--
Mailing list: https://launchpad.net/~openstack-qa-team
Post to : openstack-qa-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-qa-team
More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] Use of tearDown in tempest
Thanks, Daryl. This is a complicated issue and I will try to spell out my concern more clearly. On 6/1/2012 6:19 PM, Daryl Walleck wrote: Hi David, The per test fixtures are there for two reasons. One - stability. If we were to share one server among the tests, any of the previous tests tainted it or left it in a bad state, the rest of the suite would fail for unclear reasons. The second is for parallel execution. We cannot perform all those actions on a single server at once. These statements are obviously true but I am having trouble interpreting them against your (below) expressed desire to have Tempest be an acceptance test for a production deploy. If a test checked its results in a way that made sure its server was not tainted or left in a bad state, there would be no concern about running other tests on that server. If a test does not do that, then it could pass but also leave its server in a bad state. If we never reuse a server then such failures will never be detected by Tempest. I was really thinking about two things I noticed in the tests: 1. They spend a huge amount of time in server create, delete, resize, rebuild, etc. even though those operations represent a miniscule fraction of the code being tested. 2. There are a lot of tests that take the same path through the code but vary parameters in a way that is not thorough enough to say that an API is fully tested, and that would be better covered by the unit tests that bypass the expensive code that is the same for all the cases. The number of these cases varies widely between the different test classes in Tempest and I am not sure what principles have been used to decide how many variants tempest should have. I certainly agree that we should optimize Tempest as best we can. Tempest is an black-box, integration test suite. In my view, its purpose is to throughly, from end to end, test the integration of OpenStack components. For quick testings, we have unit and component level integration tests. If those suites are lacking, then more effort should be thrown behind those efforts as well. I'm open to making all optimizations where we can, and I think there's still quite a few things we can do. However, what I look for from Tempest is confidence in making a production deploy of OpenStack, and out there are corners I would rather not cut. I personally would not be comfortable delegating tests for basic tasks such as resize, rebuild to run daily. What do you think acceptable run times for a smoke grouping and full regression run should be? Daryl For a full regression it should take as long as it needs to be run after being optimized appropriately. I don't see a shortcut there. I was imagining that a full regression run would happen every day. I don't know enough about the inner workings of Jenkins to say how long a smoke grouping should take but it is not just the time. If we managed to get the time down by massive parallelization, it still might use an unacceptable amount of (real) server resources. I think it would be helpful to agree on: a) How thorough tempest tests should be about variants of arguments for both positive and negative tests in general, for full regression and smoke. b) How (a) might be different for cases 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 define tearDownClass that frees resources allocated in setUpClass. But two of the classes deviate from this. ServerActionsTest uses setUp and tearDown and creates a new server in setUp. I think this means that a new server is created before running each test method. This test is very slow, taking 9 minutes with three hefty compute nodes in a cluster. Many of the methods could reuse the same server and the negative tests don't need to create one at all. Unfortunately I think a lot of that time is spent just doing resize. I think we should consider making this test be nightly-build only. ServerDetailsNegativeTest has methods that create lots of servers and has a tearDown method that deletes them after each test method. That seems unnecessary. This test is very slow, taking 3 minutes on a cluster with three hefty compute nodes. And that is with 15 tests being skipped pending bug fixes. It also has a tearDownClass method that deletes all running servers whether this test created them or not. That seems pretty bad. Why is it doing this? Does any one have any comment about this? -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post
Re: [Openstack] [OpenStack][Nova] deference between live-migration and migrate
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 ·LiveMigration: move a VM form one server to another, VM doesn't appear to reboot, need to specify the destination I propose we extent the Migrate API (thinking about nova CLI here really) to include: ·Optional Flag to force non-live migration, default to live migration ·Optional destination host, by default let the scheduler choose ·Deprecate the existing live migration API and CLI calls What do people think? +1 Keep in mind that we actually have three options: live migration on shared storage live migration without shared storage (block migration) resize/migrate Yun actually suggested that resize/migrate be simplified to do the following instead of scping the file over: * snapshot to glance * boot new image from snapshot This would definitely simplify the code, unfortunately it could have billing/metering repercussions. Vish I don't think it is documented that you need to set up ssh with credentials between compute nodes to make resize and block migration work. I also heard something about there being a more secure way to do this than setting up ssh in this way. What is the officially recommended way to configure compute nodes for these operations? -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Weekly Meeting tomorrow, Thursday, May 31 @ 17:00 UTC
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 - Ravikumar_hp to find good example blueprint for QA functional test plan - jaypipes to write draft email to ML about QA team working with developers on functional test plans for all new feature blueprints. - jaypipes to create Skip Captain duties wiki page and rotation * Blockers preventing work from moving forward - When can the Tempest gate job be turned on? * Outstanding code reviews Review all outstanding code reviews in the queue: https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z * New items for discussion - Status of Swift tests - Making parallel tempest runs really work * Work in progress that will be landing soon - Smoke testing base classes - Swift tests * Open discussion Thanks, -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] Policy for Tests linked to existing Bugs
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: https://github.com/openstack/tempest/blob/master/tempest/tests/test_list_floating_ips.py#L64 skips the test and posts the Bug ID in the message. Do we submit the test for review with the @skip(until Bug #xyz is fixed) decorator applied? This is the choice that I believe is the easiest and simplest. We just need to be vigilant to remove the skips when/if the bug is fixed. -jay Jay, I agree with the idea that we should check the test in anyway. But we have the issue of who remembers to remove the skip decorator when the bug is fixed. Since we are going to be running tempest nightly, I think it might be better to make these tests fail in the absence of the bug rather than being skipped. I think there may already be some cases in Tempest that do this. -David I agree with David, and I prefer that the test failed rather than using skip decorator. - Ravi Ravi, after hearing Jays comments I realized that we can't do this if we are going to use tempest to gate trunk checkins for other projects. If we make the test fail, then it will be impossible for a developer to check in a fix to a bug unless they also change the tempest test. In an ideal world this would be the case, as surely they already do this for unit tests, but I don't think we are ready for that. I thought I sent a message to that effect last week but perhaps it never went through. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
[Openstack] Summary of QA Weekly Status meeting
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 this on to gate checkins to Tempest itself by the end of the day. Thanks to Monty Taylor for his continuing attention to this. We will also be doing a complete tempest run each day to check on other projects and hope that identified bugs can be fixed quickly. We will soon start running the stress tests nightly as well. A set of tempest tests for Swift should be coming online next week. * Decisions made New tempest tests that do not require a lot of changes will be backported to tempest essex/stable. We will do a nightly run to check on changes that are made to other essex/stable branches. A few more changes need to go into tempest stable/diablo but, generally, new tests will not be backported there. We have been focusing on black-box tests to get wide coverage. A lot of progress has been made and we are now going to be looking at white-box tests as well. * Outstanding Reviews Community, please feel free to provide code reviews on outstanding Tempest merge proposals: https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z Thanks! -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] schema and counter definitions
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: On Wed, 2012-05-02 at 10:08 +0200, Loic Dachary wrote: My impression is that the notifications system is intended to cover all billable usage in at least Nova and Glance. It's also my understanding. Regarding swift, how would you suggest we approach the problem ? I see two possible courses: a) directly create something similar to nova http://wiki.openstack.org/SystemUsageData for swift (i.e. a swift blueprint and coding in swift ) so that there is no need to install a metering agent for swift b) create a swift plugin for a metering agent and when it proves useful, port it to swift so that it is integrated and there is no longer a need for a metering agent plugin What do you think ? I've no informed opinion on Swift, but I assume Swift is amenable to work which helps with metering its resources Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Agenda for QA Weekly Status meeting
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 dev-gate-tempest-devstack-vm Jenkins job gating Tempest by end of week * Blockers preventing work from moving forward None * Outstanding code reviews Review all outstanding code reviews in the queue: https://review.openstack.org/#/q/status:open+project:openstack/tempest,n,z * New items for discussion 1. (Jay) Getting some consensus on what precisely a smoke test is and discussing some code Jay will have pushed that cleans up our smoke test abilities. 2. (David) Strategy for maintaining the stable/essex tempest branch: a) How much effort should we put into backports of new tempest tests? b) Should be we gating, or have jenkins jobs for, checkins to stable/essex code? 3. (Ravi) Status of Swift test development for Tempest 4. (Ravi) Freezing Diablo/Stable branch as we have Essex/Stable. 5. (Jay) Can we come to a consensus on the subset of Tempest tests that we recommend to the core projects to gate their trunks? * Open discussion ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Endpoints problems
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: keystone --token ADMIN --endpoint http://192.168.100.142:35357/v2.0 endpoint-create --region RegionOne --service_id=1fd7b5f1add74aa4b6efc514fd153e72 --publicurl=http://192.168.100.142:8774/v2/$(tenant_id)s --adminurl=http://192.168.100.142:8774/v2/$(tenant_id)s --internalurl=http://192.168.100.142:8774/v2/$(tenant_id)s But I'm getting a tenant_id: command not found. When I list the endpoints all my url's are like http://192.168.100.142:8774/v2/s; for the created endpoint. Am I doing something wrong ? Thanks. From: a...@openstack.org Date: Thu, 12 Apr 2012 15:28:21 -0500 Subject: Re: [Openstack] Endpoints problems To: guib...@hotmail.com CC: openstack@lists.launchpad.net Hi Guilherme - Sorry you ran into a doc bug - https://bugs.launchpad.net/openstack-manuals/+bug/977905. Basically, the bug states that the nova endpoint definition should be: keystone --token 012345SECRET99TOKEN012345 --endpoint http://192.168.206.130:35357/v2.0 endpoint-create \ --region RegionOne \ --service_id=abc0f03c02904c24abdcc3b7910e2eed \ --publicurl http://192.168.206.130:8774/v2/$(tenant_id)s http://192.168.206.130:8774/v2/%24%28tenant_id%29s \ --adminurl http://192.168.206.130:8774/v2/$(tenant_id)s http://192.168.206.130:8774/v2/%24%28tenant_id%29s \ --internalurl http://192.168.206.130:8774/v2/$(tenant_id)s http://192.168.206.130:8774/v2/%24%28tenant_id%29s I haven't fixed this yet because I'm not sure if the $(tenant_id)s is literal or which tenant_id specifically to use (the Service tenant for the adminurl possibly)? If someone on the list could offer more input here and on the doc bug it would be greatly appreciated! Anne On Thu, Apr 12, 2012 at 12:25 PM, Guilherme Birk guib...@hotmail.com mailto:guib...@hotmail.com wrote: I'm having problems setting up the nova endpoint. I've followed the manual http://docs.openstack.org/trunk/openstack-compute/install/content/setting-up-tenants-users-and-roles.html, putting the tenant id on the url's, like the manual says to do. But when I try execute nova list I got a malformed url error. When I set the endpoint without the tenant id on the url's I got a 404 error. Anyone having the same problem? I can access the dashboard normally, but I'm unable to retrieve instance list. ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] glance-registry fails to start with latest ubuntu pkgs
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. Dropping
the glance DB (postgreSQL) and recreating it doesn't help. This is
the error...
# cat registry.log
2012-04-13 20:58:13 20717 INFO [sqlalchemy.engine.base.Engine]
SELECT images.created_at AS images_created_at, images.updated_at AS
images_updated_at, images.deleted_at AS images_deleted_at,
images.deleted AS images_deleted, images.id http://images.id AS
images_id, images.name http://images.name AS images_name,
images.disk_format AS images_disk_format, images.container_format AS
images_container_format, images.size AS images_size, images.status AS
images_status, images.is_public AS images_is_public, images.location
AS images_location, images.checksum AS images_checksum,
images.min_disk AS images_min_disk, images.min_ram AS images_min_ram,
images.owner AS images_owner, images.protected AS images_protected
FROM images
LIMIT %(param_1)s
2012-04-13 20:58:13 20717 INFO [sqlalchemy.engine.base.Engine]
{'param_1': 1}
2012-04-13 20:58:13 20717 INFO [sqlalchemy.engine.base.Engine]
ROLLBACK
2012-04-13 20:58:13 20717ERROR [glance.registry.db.api]
(ProgrammingError) relation images does not exist
LINE 2: FROM images
^
'SELECT images.created_at AS images_created_at, images.updated_at AS
images_updated_at, images.deleted_at AS images_deleted_at,
images.deleted AS images_deleted, images.id http://images.id AS
images_id, images.name http://images.name AS images_name,
images.disk_format AS images_disk_format, images.container_format AS
images_container_format, images.size AS images_size, images.status AS
images_status, images.is_public AS images_is_public, images.location
AS images_location, images.checksum AS images_checksum,
images.min_disk AS images_min_disk, images.min_ram AS images_min_ram,
images.owner AS images_owner, images.protected AS images_protected
\nFROM images \n LIMIT %(param_1)s' {'param_1': 1}
2012-04-13 20:58:13 20717ERROR [glance.registry.db.api] Could not
ensure database connection and consistency. Ensure database
configuration and permissions are correct and database has been
migrated since last upgrade by running 'glance-manage db_sync'
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] A Tempest run results
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. == FAIL: The list of images should contain only images with the provided status -- Traceback (most recent call last): File /cygdrive/c/source/tempest/tempest/tests/test_list_images.py, line 98, in test_list_images_filter_by_status self.assertTrue(any([i for i in images if i['id'] == self.image2_id])) AssertionError: False is not True == FAIL: Detailed list of all images should only contain images -- Traceback (most recent call last): File /cygdrive/c/source/tempest/tempest/tests/test_list_images.py, line 190, in test_list_images_with_detail_filter_by_status self.assertTrue(any([i for i in images if i['id'] == self.image2_id])) AssertionError: False is not True -- Ran 150 tests in 1118.289s FAILED (SKIP=22, failures=2) On 4/13/2012 12:21 PM, Daryl Walleck wrote: Speaking to this: - ERROR: An update server request for another user's server should fail seems to be raised because it raises InstanceNotFound and returns a 500 HTTP error code. If this is occurring, this is a Nova defect/regression. No AuthZ test should ever be failing with a 500. That means Nova did not handle an internal exception well. Daryl On Apr 13, 2012, at 4:24 AM, Julien Danjou wrote: Hello, We ran tempest against our platform these last days. It is running OpenStack Essex-4. I found a number of issues, some of them I reported as bug reports: https://bugs.launchpad.net/tempest/+bug/979728 https://bugs.launchpad.net/tempest/+bug/978932 https://bugs.launchpad.net/tempest/+bug/978958 Some other tests failed, but it's more than likely than this has been fixed in the final Essex milestone: - ERROR: An update server request for another user's server should fail seems to be raised because it raises InstanceNotFound and returns a 500 HTTP error code. - ERROR: The list of flavors should start from the provided marker This seems to be bug #956096 - ERROR: test suite forclass 'tempest.tests.test_volumes_list.VolumesTest' the tenants used have 0 volume quota authorized - FAIL: The list of images should contain only images with the provided status This is likely to be bug #943259 Regards, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] I18n issue for OpenStack
Both points of view being expressed about this with respect to log error messages are valid and need to be accommodated. An answer, as was suggested a while back, is for error messages to have two parts: 1. A locale-independent part that can be used for searches or understood by developers who get logs as parts of bug reports. 2. A localized part that lets operators determine if the problem is their issue or an OpenStack bug to be reported. The current English string would serve the first role, and the logging code could be changed to also emit the localized string if available. I would argue for this only in the case of ERROR messages and not DEBUG. While on the subject of logs, it would be good to agree on what actions should cause errors in logs to appear. Ideally, they would only occur if an OpenStack bug was detected (out-of-bounds array ref, etc.) or some 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 9:06 AM, Sheng Bo Hou wrote: Dear OpenStack friends, It will be happy and great for our OpenStack community to see this open project open to more market all over the world. In China, OpenStack community is very active. I heard many Chinese engineers talking about their wish to have a Chinese versioned openStack, including documentation's, manuals, user interfaces, error messages, etc in OpenStack meet-ups. I have many European friends and also Danish friends, since I used to do my university there. They all spoke perfect English, which made me admire, cos they were linguists in my point of view. Oriental languages are different. They are too far from the western lingual system. In China, there are many talented engineers, who are not that kind of linguists, but they are lover of open source. I think it is amazing to open the door to them. In China, it is very appreciated for software to be localized as much as possible. I used to google or baidu(a famous Chinese search engine) error messages and logs in Chinese for other software, though it is not Apache. I found a lot of useful references in Chinese, because it has been localized. If it is not localized well first, of course it does not have the google or yahoo ability to search.:-) So far I am rather grateful for all the messages following this i18 issue. Thank you so much. Best wishes. Vincent Hou (???) Software Engineer, Standards Growth Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 *Soren Hansen so...@linux2go.dk* Sent by: openstack-bounces+sbhou=cn.ibm@lists.launchpad.net 2012-04-12 19:50 To Hua ZZ Zhang/China/IBM@IBMCN cc openstack@lists.launchpad.net, Thierry Carrez thie...@openstack.org, openstack-bounces+zhuadl=cn.ibm@lists.launchpad.net Subject Re: [Openstack] I18n issue for OpenStack Don't get me wrong.. I'd be happy to have the various openstack clients offer localised error messages. I'd also encourage a centralised effort to collect these translationns (so that all the various language bindings will use the same localised error messages). On the server, though, I believe we should stick to English and perhaps have every error message include a link (e.g. http://docs.openstack.doc/exception/NoNetworksDefinedException) to a localised docs site. I think losing the ability to search the web for error messages would be a major loss. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Ops] OpenStack and Operations: Input from the Wild
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 monitoring system should be part of core OpenStack, it is the core architects who really know what needs to be checked to ensure that a system is healthy. There are various sets of poking at ports, process lists and so on that Crowbar, Zenoss, etc. set up but it would be a big improvement for deployers if each openstack service provided healthcheck apis based on expert knowledge of what is supposed to be happening inside. That would also insulate deployers from changes in the code that might impact what it means to be running properly. Looking forward to the discussion. -David On 4/6/2012 1:06 AM, Andrew Clay Shafer wrote: Interested in devops. Off the top of my head. live upgrades api queryable indications of cluster health api queryable cluster version and configuration info enabling monitoring as a first class concern in OpenStack (either as a cross cutting concern, or as it's own project) a framework for gathering and sharing performance benchmarks with architecture and configuration On Thu, Apr 5, 2012 at 1:52 PM, Duncan McGreggor dun...@dreamhost.com mailto:dun...@dreamhost.com wrote: For anyone interested in DevOps, Ops, cloud hosting management, etc., there's a proposed session we could use your feedback on for topics of discussion: http://summit.openstack.org/sessions/view/57 Respond with your thoughts and ideas, and I'll be sure to add them to the list. Thanks! d ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack immaturity
+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 happen if the issue is always punted to the end of a release cycle. The way to do this is to create a test very early in Folsom that demonstrates how a real large-scale style deployment can be upgraded to a new version containing no code changes. Any future change that breaks that test must be evaluated to compare the value of the change against whatever upgrade pain will be caused. In terms of real deployments, this issue scares me more than the fact that there are bugs. There will always be bugs. But we can't have it be tricky and risky to deploy the fixes. -David On 4/4/2012 2:30 PM, Tim Bell wrote: Essex is a key release in this respect. With the excellent work done by the developers, testers and packaging teams, OpenStack is much better positioned than with Diablo. As the work proceeds on Folsom, back porting critical bugs and planning for a smooth migration path for production sites will become factors in keeping the early adopters enthusiastic. These are the user stories that will drive the next wave of OpenStack growth as much as expanding the feature set. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Dashboard VNC Console failed to connect to server
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 root@xg06:~/noVNC# nova get-vnc-console test novnc +---+---+ | Type | Url| +---+---+ | novnc | http://172.18.0.146:6080/vnc_auto.html?token=43971233-a806-4f01-96b1-8861c1dc7410 | +---+---+ but when I browse to that I get this from novnc log, and an error banner with Websock error: [Object Event] If I do the same thing against devstack the log is different and it works. Any help would be appreciated. Also, this stuff seems only semi-official with references to cloudbuilders git repos. Is it officially part of Essex? -David multinode package deploy + noVNC from git 1: 172.17.1.170: GET /vnc_auto.html?token=43971233-a806-4f01-96b1-8861c1dc7410 HTTP/1.1 200 - 2: 172.17.1.170: new handler Process 3: 172.17.1.170: new handler Process 2: 172.17.1.170: GET /include/plain.css HTTP/1.1 200 - 3: 172.17.1.170: GET /include/vnc.js HTTP/1.1 200 - 4: 172.17.1.170: new handler Process 5: 172.17.1.170: new handler Process 6: 172.17.1.170: new handler Process 4: 172.17.1.170: GET /include/util.js HTTP/1.1 200 - 7: 172.17.1.170: new handler Process 5: 172.17.1.170: GET /include/webutil.js HTTP/1.1 200 - 8: 172.17.1.170: new handler Process 6: 172.17.1.170: GET /include/logo.js HTTP/1.1 200 - 7: 172.17.1.170: GET /include/base64.js HTTP/1.1 200 - 8: 172.17.1.170: GET /include/websock.js HTTP/1.1 200 - 9: 172.17.1.170: new handler Process 10: 172.17.1.170: new handler Process 9: 172.17.1.170: GET /include/des.js HTTP/1.1 200 - 11: 172.17.1.170: new handler Process 12: 172.17.1.170: new handler Process 10: 172.17.1.170: GET /include/input.js HTTP/1.1 200 - 11: 172.17.1.170: GET /include/display.js HTTP/1.1 200 - 12: 172.17.1.170: GET /include/rfb.js HTTP/1.1 200 - 13: 172.17.1.170: new handler Process DIFFERENCE STARTS HERE 14: 172.17.1.170: new handler Process 13: 172.17.1.170: Python = 2.6 and numpy module is required for HyBi-07 or greater 14: 172.17.1.170: GET /favicon.ico HTTP/1.1 200 - devstack: works 1: 172.17.1.170: GET /vnc_auto.html?token=e64e682e-5c69-42dd-8d78-01537b3d3223 HTTP/1.1 200 - 2: 172.17.1.170: new handler Process 3: 172.17.1.170: new handler Process 2: 172.17.1.170: GET /include/plain.css HTTP/1.1 200 - 3: 172.17.1.170: GET /include/vnc.js HTTP/1.1 200 - 4: 172.17.1.170: new handler Process 5: 172.17.1.170: new handler Process 6: 172.17.1.170: new handler Process 4: 172.17.1.170: GET /include/util.js HTTP/1.1 200 - 7: 172.17.1.170: new handler Process 5: 172.17.1.170: GET /include/webutil.js HTTP/1.1 200 - 8: 172.17.1.170: new handler Process 6: 172.17.1.170: GET /include/logo.js HTTP/1.1 200 - 9: 172.17.1.170: new handler Process 7: 172.17.1.170: GET /include/base64.js HTTP/1.1 200 - 8: 172.17.1.170: GET /include/websock.js HTTP/1.1 200 - 9: 172.17.1.170: GET /include/des.js HTTP/1.1 200 - 10: 172.17.1.170: new handler Process 11: 172.17.1.170: new handler Process 12: 172.17.1.170: new handler Process 11: 172.17.1.170: GET /include/display.js HTTP/1.1 200 - 10: 172.17.1.170: GET /include/input.js HTTP/1.1 200 - 12: 172.17.1.170: GET /include/rfb.js HTTP/1.1 200 - 13: 172.17.1.170: new handler Process 13: 172.17.1.170: Plain non-SSL (ws://) WebSocket connection 13: 172.17.1.170: Version hybi-08, base64: 'True' 13: connecting to: 127.0.0.1:5900 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Dashboard VNC Console failed to connect to server
Thanks, Anthony. All is well now. Presumably once this feature is really in essex there will be a novnc package that will take care of the numpy dependency when it is installed. -David On 3/30/2012 2:23 PM, Anthony Young wrote: I've proposed doc changes that add a FAQ and also remove 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 wrote: 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 root@xg06:~/noVNC# nova get-vnc-console test novnc +---+---+ | Type |Url | +---+---+ | novnc | http://172.18.0.146:6080/vnc_auto.html?token=43971233-a806-4f01-96b1-8861c1dc7410 | +---+---+ but when I browse to that I get this from novnc log, and an error banner with Websock error: [Object Event] If I do the same thing against devstack the log is different and it works. Any help would be appreciated. Also, this stuff seems only semi-official with references to cloudbuilders git repos. Is it officially part of Essex? -David multinode package deploy + noVNC from git 1: 172.17.1.170 http://172.17.1.170: GET /vnc_auto.html?token=43971233-a806-4f01-96b1-8861c1dc7410 HTTP/1.1 200 - 2: 172.17.1.170 http://172.17.1.170: new handler Process 3: 172.17.1.170 http://172.17.1.170: new handler Process 2: 172.17.1.170 http://172.17.1.170: GET /include/plain.css HTTP/1.1 200 - 3: 172.17.1.170 http://172.17.1.170: GET /include/vnc.js HTTP/1.1 200 - 4: 172.17.1.170 http://172.17.1.170: new handler Process 5: 172.17.1.170 http://172.17.1.170: new handler Process 6: 172.17.1.170 http://172.17.1.170: new handler Process 4: 172.17.1.170 http://172.17.1.170: GET /include/util.js HTTP/1.1 200 - 7: 172.17.1.170 http://172.17.1.170: new handler Process 5: 172.17.1.170 http://172.17.1.170: GET /include/webutil.js HTTP/1.1 200 - 8: 172.17.1.170 http://172.17.1.170: new handler Process 6: 172.17.1.170 http://172.17.1.170: GET /include/logo.js HTTP/1.1 200 - 7: 172.17.1.170 http://172.17.1.170: GET /include/base64.js HTTP/1.1 200 - 8: 172.17.1.170 http://172.17.1.170: GET /include/websock.js HTTP/1.1 200 - 9: 172.17.1.170 http://172.17.1.170: new handler Process 10: 172.17.1.170 http://172.17.1.170: new handler Process 9: 172.17.1.170 http://172.17.1.170: GET /include/des.js HTTP/1.1 200 - 11: 172.17.1.170 http://172.17.1.170: new handler Process 12: 172.17.1.170 http://172.17.1.170: new handler Process 10: 172.17.1.170 http://172.17.1.170: GET /include/input.js HTTP/1.1 200 - 11: 172.17.1.170 http://172.17.1.170: GET /include/display.js HTTP/1.1 200 - 12: 172.17.1.170 http://172.17.1.170: GET /include/rfb.js HTTP/1.1 200 - 13: 172.17.1.170 http://172.17.1.170: new handler Process DIFFERENCE STARTS HERE 14: 172.17.1.170 http://172.17.1.170: new handler Process 13: 172.17.1.170 http://172.17.1.170: Python = 2.6 and numpy module is required for HyBi-07 or greater 14: 172.17.1.170 http://172.17.1.170: GET /favicon.ico HTTP/1.1 200 - devstack: works 1: 172.17.1.170 http://172.17.1.170: GET /vnc_auto.html?token=e64e682e-5c69-42dd-8d78-01537b3d3223 HTTP/1.1 200 - 2: 172.17.1.170 http://172.17.1.170: new handler Process 3: 172.17.1.170 http://172.17.1.170: new handler Process 2: 172.17.1.170 http://172.17.1.170: GET /include/plain.css HTTP/1.1 200 - 3: 172.17.1.170 http://172.17.1.170: GET /include/vnc.js HTTP/1.1 200 - 4: 172.17.1.170 http://172.17.1.170: new handler Process 5: 172.17.1.170 http://172.17.1.170: new handler Process 6: 172.17.1.170 http://172.17.1.170: new handler Process 4: 172.17.1.170 http://172.17.1.170: GET /include/util.js HTTP/1.1 200 - 7: 172.17.1.170 http://172.17.1.170: new handler Process 5: 172.17.1.170 http://172.17.1.170: GET /include/webutil.js HTTP/1.1 200 - 8: 172.17.1.170 http://172.17.1.170: new handler Process 6: 172.17.1.170 http://172.17.1.170: GET /include/logo.js HTTP/1.1 200 - 9: 172.17.1.170 http
Re: [Openstack] Performance diagnosis of metadata query
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 proving contentious); it will have a configurable log level to allow for future improvements, and one of the things I'd like to do is add later is something like a stack trace on 'problematic' SQL (large row count, long query time). But that'll be in Folsom, or in G if we don't get logging into Essex. In the meantime, it's probably not too hard to follow the code and infer where the calls are coming from. In the full log, there's a bit more context, and I've probably snipped some of that out; in this case the relevant code is get_metadata in the compute API service and get_instance_nw_info in the network service. Regardless, large table scans should be eliminated, especially if the table is mostly read, as the hit on an extra index on insert will be completely offset by the speedups on select. Agreed - some of these problems are very clear-cut! It does frustrate me that we've done so much programming work, but then not do the simple stuff at the end to make things work well. It feels a bit like shipping we're shipping C code which we've compiled with -O0 instead of -O3. Well, in a project with the style of fixed-date release (short-duration train-model) that openstack has, I think we have to accept that there will never be time to do anything except fight critical bugs at the end. At least not until the project code is much more mature. In projects I have managed we always allocated time at the *beginning* of a release cycle for fixing some backlogged bugs and performance work. There is less pressure and the code is not yet churning. It is also important to have performance benchmark tests to make sure new features do not introduce performance regressions. -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] is this a bug in milestone-proposed keystone ? (cannotget endpoint-list, nor create endpoint)
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 there a good reason? Can this be sorted out so there is
only one documented way to do this?
-David
On 3/26/2012 7:25 AM, Andiabes wrote:
Can you include your config?
The behavior you're describing seems to be consistent with a missing
backers configuration ...
Something like:
[identity]
driver = keystone.identity.backends.sql.Identity
[catalog]
driver = keystone.catalog.backends.sql.Catalog
Also, where/how are you installing?
On Mar 26, 2012, at 6:56 AM, Mandar Vaze mandar.v...@vertex.co.in
mailto:mandar.v...@vertex.co.in wrote:
I'm also getting the same error on latest master branch (updated today)
Using setup created by devstack
-Mandar
*From:*openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
[mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net mailto:vertex.co...@lists.launchpad.net]
*On Behalf Of *.?o 0 O??
*Sent:* Monday, March 26, 2012 12:45 PM
*To:* Pierre Amadio
*Cc:* openstack
*Subject:* Re: [Openstack] is this a bug in milestone-proposed
keystone ? (cannotget endpoint-list, nor create endpoint)
hi,
I don't know if it is a bug but I come across the same problem and
wondering how to solve it.
-- Original --
*From: * Pierre Amadiopierre.ama...@canonical.com
mailto:pierre.ama...@canonical.com;
*Date: * Sun, Mar 25, 2012 04:35 AM
*To: * openstackopenstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net;
*Subject: * [Openstack] is this a bug in milestone-proposed keystone
? (cannotget endpoint-list, nor create endpoint)
Hi there !
I wanted to give a try to the milestone-proposed branch of keystone and
got stuck quite fast.
I am not sure if i hit a bug and should report it, or if i'm doing
something wrong.
With previous version of keystone (read packaged on ubuntu precise), i
was able to create endpoint the following way once keystone has been
installed:
1) setting some env variables:
export KEYSTONE_IP=192.168.122.102 # IP of your keystone API server
export SERVICE_ENDPOINT=http://$KEYSTONE_IP:35357/v2.0/
export SERVICE_TOKEN=999888777666
export NOVA_PUBLIC_URL=http://$NOVA_IP:8774/v1.1/%(tenant_id)s
http://$NOVA_IP:8774/v1.1/%%28tenant_id%29s
export NOVA_ADMIN_URL=$NOVA_PUBLIC_URL
export NOVA_INTERNAL_URL=$NOVA_PUBLIC_URL
2) creating services:
keystone service-create --name nova --type compute --description
'OpenStack Compute Service'
keystone service-create --name swift --type object-store --description
'OpenStack Storage Service'
keystone service-create --name glance --type image --description
'OpenStack Image Service'
keystone service-create --name keystone --type identity --description
'OpenStack Identity Service'
3) creating an endpoint for those services, starting with the compute
service:
ID=$(keystone service-list | grep -i compute | awk '{print $2}')
keystone endpoint-create --region RegionOne --service_id $ID --publicurl
$NOVA_PUBLIC_URL --adminurl $NOVA_ADMIN_URL --internalurl
$NOVA_INTERNAL_URL
When i run this command with milestone-proposed, i experience the
following:
No handlers could be found for logger keystoneclient.client
The action you have requested has not been implemented. (HTTP 501)
Strangely enough, i experience a similar error message when running a
simple keystone endpoint-list whereas command such as keystone
user-list works all right.
here is what i have in the keystone logs when trying endpoint-list:
2012-03-24 20:30:09DEBUG [routes.middleware] Matched GET /endpoints
2012-03-24 20:30:09DEBUG [routes.middleware] Route path:
'{path_info:.*}', defaults: {'controller':
keystone.contrib.admin_crud.core.CrudExtension object at 0x2b215d0}
2012-03-24 20:30:09DEBUG [routes.middleware] Match dict:
{'controller': keystone.contrib.admin_crud.core.CrudExtension object at
0x2b215d0, 'path_info': '/endpoints'}
2012-03-24 20:30:09DEBUG [routes.middleware] Matched GET /endpoints
2012-03-24 20:30:09DEBUG [routes.middleware] Route path:
'/endpoints', defaults: {'action': u'get_endpoints', 'controller':
keystone.catalog.core.EndpointController object at 0x2b21210}
2012-03-24 20:30:09DEBUG [routes.middleware] Match dict: {'action':
u'get_endpoints', 'controller':
keystone.catalog.core.EndpointController object at 0x2b21210}
2012-03-24 20:30:09DEBUG [keystone.common.wsgi] arg_dict: {}
2012-03-24 20:30:09 WARNING [keystone.common.wsgi] The action you have
requested has not been implemented.
2012-03-24 20:30:09DEBUG [keystone.common.wsgi]
RESPONSE HEADERS
2012-03-24 20:30:09DEBUG [keystone.common.wsgi] Content-Type =
Re: [Openstack] is this a bug in milestone-proposed keystone ? (cannotget endpoint-list, nor create endpoint)
Thanks for the explanation. But I am still a little confused about the
point of the templates. Having two implementations, one simple and one
less simple, is not simpler than having only one. You still need to user
the CLI for user, roles, etc. so having a different mechanism for
endpoints does not seem simple. With regard to performance, won't these
endpoint values be changing infrequently and so any reasonable caching
strategy would give good performance? Or am I missing something?
-David
On 3/26/2012 1:39 PM, Dolph Mathews wrote:
I think I'm to blame (apologies!) for suggesting that one driver was
preferred over the other (that was my understanding a few weeks ago,
based on test coverage). However, test coverage has since improved and
I think people are having good experience with the SQL driver.
The two methods are *not* functionally identical. The file-based
driver is simple and high-performance, and the sql-based driver
provides flexibility and API/CLI administration.
I've just proposed a review to clarify each option in the
http://keystone.openstack.org/configuration.html docs:
https://review.openstack.org/#change,5820
As well as a separate review 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 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 there a good reason?
Can this be sorted out so there is only one documented way to do this?
-David
On 3/26/2012 7:25 AM, Andiabes wrote:
Can you include your config?
The behavior you're describing seems to be consistent with a
missing backers configuration ...
Something like:
[identity]
driver = keystone.identity.backends.sql.Identity
[catalog]
driver = keystone.catalog.backends.sql.Catalog
Also, where/how are you installing?
On Mar 26, 2012, at 6:56 AM, Mandar Vaze
mandar.v...@vertex.co.in mailto:mandar.v...@vertex.co.in wrote:
I’m also getting the same error on latest master branch (updated
today)
Using setup created by devstack
-Mandar
*From:*openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
[mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
mailto:vertex.co...@lists.launchpad.net] *On Behalf Of *.?o 0 O??
*Sent:* Monday, March 26, 2012 12:45 PM
*To:* Pierre Amadio
*Cc:* openstack
*Subject:* Re: [Openstack] is this a bug in milestone-proposed
keystone ? (cannotget endpoint-list, nor create endpoint)
hi,
I don't know if it is a bug but I come across the same problem
and wondering how to solve it.
-- Original --
*From: * Pierre Amadiopierre.ama...@canonical.com
mailto:pierre.ama...@canonical.com;
*Date: * Sun, Mar 25, 2012 04:35 AM
*To: * openstackopenstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net;
*Subject: * [Openstack] is this a bug in milestone-proposed
keystone ? (cannotget endpoint-list, nor create endpoint)
Hi there !
I wanted to give a try to the milestone-proposed branch of
keystone and
got stuck quite fast.
I am not sure if i hit a bug and should report it, or if i'm doing
something wrong.
With previous version of keystone (read packaged on ubuntu
precise), i
was able to create endpoint the following way once keystone has been
installed:
1) setting some env variables:
export KEYSTONE_IP=192.168.122.102 # IP of your keystone API server
export SERVICE_ENDPOINT=http://$KEYSTONE_IP:35357/v2.0/
export SERVICE_TOKEN=999888777666
export NOVA_PUBLIC_URL=http://$NOVA_IP:8774/v1.1/%(tenant_id)s
http://$NOVA_IP:8774/v1.1/%%28tenant_id%29s
export NOVA_ADMIN_URL=$NOVA_PUBLIC_URL
export NOVA_INTERNAL_URL=$NOVA_PUBLIC_URL
2) creating services:
keystone service-create --name nova --type compute --description
'OpenStack Compute Service'
keystone service-create --name swift --type object-store
--description
'OpenStack Storage Service'
keystone service-create --name glance --type image --description
'OpenStack Image Service'
keystone service-create --name keystone --type identity
--description
'OpenStack Identity Service'
3) creating an endpoint for those services, starting with the
compute
service:
ID=$(keystone service-list | grep -i compute | awk '{print $2}')
keystone endpoint-create --region
Re: [Openstack-qa-team] New tempest failure
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 (NotFound) is expected by Tempest. Has any one
seen this? This test was passing fairly recently...
-David
==
ERROR: Negative test: The server rebuild for a non existing server
should not
--
Traceback (most recent call last):
File
/cygdrive/c/source/tempest/tempest/tests/test_server_actions.py, line
158, in test_rebuild_nonexistant_server
adminPass='rebuild')
File
/cygdrive/c/source/tempest/tempest/services/nova/json/servers_client.py,
line 217, in rebuild
self.headers)
File /cygdrive/c/source/tempest/tempest/common/rest_client.py, line
100, in post
return self.request('POST', url, headers, body)
File /cygdrive/c/source/tempest/tempest/common/rest_client.py, line
136, in request
raise exceptions.BadRequest(resp_body['badRequest']['message'])
BadRequest: Bad request
Details: Bad request
Details: Invalid imageRef provided.
begin captured logging
tempest.common.rest_client: ERROR: Request URL:
http://172.18.0.146:8774/v2/30db781b8c044409810ab5bdcd175968/servers/999/action
tempest.common.rest_client: ERROR: Request Body: {rebuild:
{personality: [{path: /etc/rebuild.txt, contents:
VGVzdCBzZXJ2ZXIgcmVidWlsZC4=}], metadata: {rebuild: server},
name: server93407542699, imageRef:
346f4039-a81e-44e0-9223-4a3d13c907, adminPass: rebuild}}
tempest.common.rest_client: ERROR: Response Headers: {'date': 'Fri, 23
Mar 2012 15:42:43 GMT', 'status': '400', 'content-length': '70',
'content-type': 'application/json; charset=UTF-8',
'x-compute-request-id': 'req-67ec2a25-0ed9-4451-ba01-ee247df51f09'}
tempest.common.rest_client: ERROR: Response Body: {u'badRequest':
{u'message': u'Invalid imageRef provided.', u'code': 400}}
- end captured logging
Looking into the Nova codebase, the only place that Invalid imageRef
was used is this block of code:
def _image_uuid_from_href(self, image_href):
# If the image href was generated by nova api, strip image_href
# down to an id and use the default glance connection params
image_uuid = image_href.split('/').pop()
if not utils.is_uuid_like(image_uuid):
msg = _(Invalid imageRef provided.)
raise exc.HTTPBadRequest(explanation=msg)
return image_uuid
So, it seems that the utils.is_uuid_like() does not think that
346f4039-a81e-44e0-9223-4a3d13c907 looks like a UUID :)
The method looks like this:
def is_uuid_like(val):
For our purposes, a UUID is a string in canonical form:
----
try:
uuid.UUID(val)
return True
except (TypeError, ValueError, AttributeError):
return False
After trying this in a Python interpreter:
jpipes@uberbox:~/repos/nova$ python
Python 2.7.2+ (default, Oct 4 2011, 20:06:09)
[GCC 4.6.1] on linux2
Type help, copyright, credits or license for more information.
import uuid
def is_uuid_like(val):
... For our purposes, a UUID is a string in canonical form:
...
... ----
...
... try:
... uuid.UUID(val)
... return True
... except (TypeError, ValueError, AttributeError):
... return False
...
print is_uuid_like(346f4039-a81e-44e0-9223-4a3d13c907)
False
Could it be that you incorrectly copy-pasted the image UUID into your
tempest.conf?
Best,
-jay
--
Mailing list: https://launchpad.net/~openstack-qa-team
Post to : openstack-qa-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-qa-team
More help : https://help.launchpad.net/ListHelp
[Openstack] Warning to new Essex users
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 : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Cleaning nova database
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 understand that this means the instances have been deleted as far as the hypervisor is concerned, but nova still thinks they are there. I found the offending instances in the database and they were still listed as in the active state even though they had a deletion date recorded. I tried to delete them but was unable due to a foreign key error with virtual_interfaces. I could play around with deleting various things from the database but there are real users. Is their a documented way to clean up the state of the nova database in such situations? It seems like a bug that the database could get into this state. Also, it seems that deleted instances are never removed from the database. Is that a bug? -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cleaning nova database
The users are using nova CLI, not euca. The 'deleted' field is already 1. The delete fails because the id is a foreign key in the virtual_interfaces table. The question is how to excise an instance from the database without screwing anything up. Here is the whole row, which has a few unexpected values for a deleted instance, and the error. I am trying to determine if a bug should be filed. Of course I cannot reproduce this. SQL query: DELETE FROM `nova`.`instances` WHERE `instances`.`id` =155 MySQL said: Documentation #1451 - Cannot delete or update a parent row: a foreign key constraint fails (`nova`.`virtual_interfaces`, CONSTRAINT `virtual_interfaces_ibfk_1` FOREIGN KEY (`instance_id`) REFERENCES `instances` (`id`)) created_at: 2012-01-26 21:31:44 updated_at: 2012-02-27 22:35:24 deleted_at: 2012-02-27 22:35:35 deleted: 1 id: 155 user_id: xx project_id: test image_ref: 51 kernel_id: 7 ramdisk_id: launch_index: 0 key_name: li key_data: ssh-rsa B3NzaC1yc2EDAQABgQCywTW0xypa949d2U5RBjTU9ip9yGapOy/9HwcRL5fgQh0EApVB5eUT7Pg3NgtB1AAVnsvNBguCRNmRzHwu2/kGc8AYNJEwgVGvR8eArrRltV7JriYxtC7/LirHM5EjdJ5paYKGOQAleb5fpfjlYuHd4H8RkYqcBRcriNzmGlJNPQ== nova@xg03\n power_state: 5 vm_state: active memory_mb: 2048 vcpus: 1 local_gb: 20 hostname: testworker2 host: xg01 user_data: reservation_id: r-u29wsnpn launched_at: 2012-02-23 16:08:37 display_name: testworker2 display_description: testworker2 locked: 0 launched_on: xg01 instance_type_id: 5 uuid: 36741362-b755-4aff-a6c4-7b292acfda0b root_device_name: /dev/vda config_drive: task_state: rebooting default_local_device: /dev/vdb On 3/20/2012 11:27 AM, Leandro Reox wrote: I think that the quick solution is set deteled to 1 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, 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 understand that this means the instances have been deleted as far as the hypervisor is concerned, but nova still thinks they are there. I found the offending instances in the database and they were still listed as in the active state even though they had a deletion date recorded. I tried to delete them but was unable due to a foreign key error with virtual_interfaces. I could play around with deleting various things from the database but there are real users. Is their a documented way to clean up the state of the nova database in such situations? It seems like a bug that the database could get into this state. Also, it seems that deleted instances are never removed from the database. Is that a bug? -David ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cleaning nova database
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 when there are real users. One thing I have done in past projects is to have an email address where people are encouraged to report 'incidents' like this. Investigation and creation of a proper bug report can be dangerous and/or a lot of work but we could encourage operators of real systems to just email these problems even if they don't have time to investigate. That could help find problems that are appearing in the field but don't get picked up in unit tests and such. I will file a bug about the bad state. -David On 3/20/2012 11:29 AM, Jay Pipes wrote: Also, it seems that deleted instances are never removed from the database. Is that a bug? No, it's not a bug. But was is a bug is ACTIVE status instances that are deleted. Another issue right now is that Essex has moved on and much of the code involved in this stuff is substantially different in trunk. We first need to identify whether this issue exists in trunk today, and if so, patch trunk and then backport a patch to Diablo... Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
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 is not available. Devstack was a huge step forward in essex because it allowed people who already understood the differences between single and multi-node to understand and cope with the incompatible changes to the components in a way that was known (mostly) to be working. I would guess that for every person brave enough to publish their struggles on this list, there are many more who do not. The only ways I know to deal with this are: 1. More stability. Fewer incompatible changes. This will come over time. 2. Require blueprints, tagged as such, for every API and configuration change. Maintain a highly visible list. The other is longer release cycles with longer freeze periods but that is not going to happen. -David On 3/20/2012 2:57 PM, Michael Pittaro wrote: Is Devstack helpful? I'm sure it is, but for developers only. It's just bad to think about it as self-documenting Openstack, or to think that it's the solution for everything. It has never been its purpose, and it isn't taking that path, and thinking that it does is a huge mistake. Hoping that I will be heard and understood, Thomas Goirand (zigo) I think you have hit the real issue of documentation right here. Devstack has become a lightning rod for install and configuration problems. However, I think the real problem is lack of detailed configuration and installation information - for development, packagers, and real world installations. devstack is just not appropriate as a complete replacement for documentation and dependencies. Install and configuration documentation is an area we need to focus on more, and it will need much more community involvement to really make a difference. The situation is currently much better than it was back in September 2011, so progress _is_ being made. Having said that, the Devstack-Py [1] is an alternative project which is progressing along nicely. It is intended to support multiple distributions, with a focus on developer installs. Not 100% there yet for all scenarios, but usable and definitely more hackable. [1] https://launchpad.net/devstackpy Mike ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Installation Woes - Need re-assurance and help.
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 fixes the problem after upgrading the upstart package: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/935585 -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Help, How to restore existing vms after host reboot?
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 comment. More generally, I haven't seen much documentation in nova about how to deal with various failure scenarios. There is a lot more information about this for Swift and there were some sessions at the last design summit that provided a lot of useful information about the mechanics of operating a real Swift cluster. I think such a session for nova at the upcoming summit would be very useful as well. -David On 3/12/2012 10:14 AM, Christian Wittwer wrote: You can let nova-compute start the instances after a host reboot. --start_guests_on_host_boot --resume_guests_state_on_host_boot 2012/3/10 Vishvananda Ishaya vishvana...@gmail.com: I think that this branch should make reboot work: https://review.openstack.org/#change,5177 It looks like we should also make sync_power_states run more frequently. It currently runs every 6 minutes by default. On Mar 8, 2012, at 6:27 PM, DeadSun wrote: As we all know, if host reboot since of some failure or hardware problem, the vms will actually shutoff. But after host up, info in nova db show vm state are active, and using nova list return the same. Now how to start the vms. In Daiblo, I always just using nova reboot, it works.But in essex version, it seems cannot use nova reboot in an inactive domain. I see there is nova host-action command, but it not always make vm start. Another way, I can use virsh start a domain, but if the vm attach a volume, it doesn't work. nova volume-detach cannot detach a volume in an inactive domain. Is there a normal way to resolve this case? -- 非淡薄无以明志，非宁静无以致远 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Random libvirt hangs
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 not, but rebooting the compute node and then the vm does. I just heard from people in my company operating another cluster (essex/kvm) that they have also seen this. I filed a bug about a month ago https://bugs.launchpad.net/nova/+bug/931540 Has any one been running a kvm cluster for a long time with real users and never seen this issue? -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Tempest stable/diablo status
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 with the current broken diablo behavior so that they will fail, and can be changed, when/if the bugs are ever fixed. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex-4 milestone proposed candidates
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 answer different if the diablo cluster is not using keystone? -David On 2/29/2012 6:15 AM, Thierry Carrez wrote: Hi everyone, Milestone-proposed branches were just created for Keystone, Glance, Nova and Horizon in preparation for the essex-4 milestone delivery on Thursday. Please test proposed deliveries to ensure no critical regression found its way in. Milestone-critical fixes will be backported to the milestone-proposed branch until final delivery of the milestone, and will be tracked using the essex-4 milestone targeting. Links: for PROJ in ['keystone', 'nova', 'glance', 'horizon']: Milestone-critical bugs: https://launchpad.net/PROJ/+milestone/essex-4 Branch at: https://github.com/openstack/PROJ/tree/milestone-proposed Proposed tarballs at: http://PROJ.openstack.org/tarballs/ (Look for the most recent PROJ-2012.1~e4*.tar.gz build) You can also test the glance, nova and python-novaclient candidates on Ubuntu by enabling the new common ppa:~openstack-ppa/milestone-proposed The current plan is to deliver Essex-4 Thursday morning, US time. The development focus now switched completely from feature development to preparation of final release candidates. Release-blocking bugs will be listed on https://launchpad.net/PROJ/+milestone/essex-rc1. Once we get a valid release candidate, Folsom development will be open. Cheers, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] running Tempest continuously in the openstack project?
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 AM, James E. Blair wrote: Indeed, as soon as someone says I have Tempest working on a system configured by devstack with a repeatable process, here's how I did it... we'll start running it in Jenkins. But so far I've heard from the Tempest developers that it's not quite ready yet. That would be correct. Still work needed to get things working more consistently. How can I help with this effort? Who should I contact? Right now I'm having trouble setting up running the tests against devstack (a configuration problem on my part I suppose, but I blame it on the lack of documentation). -Ionuț ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] running Tempest continuously in the openstack project?
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 into anything though, please make a report to the Tempest project and I'll have a look. Daryl, devstack has a script (tools/configure_tempest.sh) that is meant to transfer the devstack settings to tempest.conf. It edits tempest.conf.sample so it should just need to know the attribute names for the settings. Let me know if there is more that devstack needs to do to set up tempest. dt It would be helpful to have a NORATELIMIT variable that could be set in localrc. -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] Tempest tests almost passing against devstack
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 well. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] running Tempest continuously in the openstack project?
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 yet... -David On 2/22/2012 9:12 AM, Ionuț Arțăriși wrote: Hello, I'm trying to get started with Tempest and I would really like to be able to see a running setup somewhere. I'm getting a lot of tests failing and I don't know if it's because of my setup or because of bugs in Tempest or incompatibilities with the current code in the other components. I looked at Jenkins, but it seems there are only two tasks related to Tempest there, testing for git-merge and pep8. Does the OpenStack project actively run the full Tempest test suite anywhere? It would be great if anyone can offer a working configuration or at least say if they have Tempest running successfully against which versions of nova, glance, swift etc. Thanks, Ionuț ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Question on i8ln?
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 of the bug databases. -David On 2/20/2012 10:41 AM, Ahn, Jaesuk wrote: We have a small discussion at OpenStack Korea Community about logging in local language. Most of participants said that they prefers having logging message in English only. Reasons are: 1. Logging messages are searchable keywords. Having a single entry point for searching is important. 2. Keeping the exact translation for logging message is very important for the localization. It is not an easy task to do. Suggestions are: - It would be helpful if we can have a place (website) to look-up for the translation. - It would be good if each error message has corresponding error code, and a look-up website to search for localized translation with the error-code. - It is also possible that we can have an option to generate localized error message along with original English message. - Having an official website to put feedback, related information, possible cause of error message in various languages is more important than having translated logging message. This is just an opinion from small set of developers in Korea Community. We are happy to join a discussion on this subject at Folsom design summit, or we can try to gather much broader consensus on this subject within Korea Community. Cheers, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack-qa-team] Tempest and diablo-stable
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 not sure if this is the right approach. Was there a discussion and/or decision about whether specific return codes are part of the API or not? This is critical to understanding how the tests should be written. -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
[Openstack] Flavor change in Essex?
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 | ++---+---+--+--+---+-+ | 1 | m1.tiny | 512 | | 0| 1 | 1.0 | | 2 | m1.small | 2048 | | 10 | 1 | 1.0 | | 3 | m1.medium | 4096 | | 10 | 2 | 1.0 | | 4 | m1.large | 8192 | | 10 | 4 | 1.0 | | 5 | m1.xlarge | 16384 | | 10 | 8 | 1.0 | ++---+---+--+--+---+-+ and this in Diablo: ++---+---+--+--+---+-+ | ID |Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor | ++---+---+--+--+---+-+ | 1 | m1.tiny | 512 | 0| 0| 1 | | | 2 | m1.small | 2048 | 0| 20 | 1 | | | 3 | m1.medium | 4096 | 0| 40 | 2 | | | 4 | m1.large | 8192 | 0| 80 | 4 | | | 5 | m1.xlarge | 16384 | 0| 160 | 8 | | ++---+---+--+--+---+-+ Note that Local_GB changed from 0,20,40,80,160 to 0,10,10,10,10. These values are coming straight from the API call. Is this a bug or a deliberate change? -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Flavor list changed in Essex
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 | ++---+---+--+--+---+-+ | 1 | m1.tiny | 512 | | 0| 1 | 1.0 | | 2 | m1.small | 2048 | | 10 | 1 | 1.0 | | 3 | m1.medium | 4096 | | 10 | 2 | 1.0 | | 4 | m1.large | 8192 | | 10 | 4 | 1.0 | | 5 | m1.xlarge | 16384 | | 10 | 8 | 1.0 | ++---+---+--+--+---+-+ and this in Diablo: ++---+---+--+--+---+-+ | ID |Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Factor | ++---+---+--+--+---+-+ | 1 | m1.tiny | 512 | 0| 0| 1 | | | 2 | m1.small | 2048 | 0| 20 | 1 | | | 3 | m1.medium | 4096 | 0| 40 | 2 | | | 4 | m1.large | 8192 | 0| 80 | 4 | | | 5 | m1.xlarge | 16384 | 0| 160 | 8 | | ++---+---+--+--+---+-+ Note that Local_GB changed from 0,20,40,80,160 to 0,10,10,10,10. These values are coming straight from the API call. Is this a bug or a deliberate change? -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Live migration with mult_host - only ugly approach?
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 right, is there (or will there be) an officially documented way to to this, either for diablo or essex? -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-qa-team] Getting rid of bad vms
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 -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
[Openstack] Problem with meeting logs?
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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] No /etc/nova/nova.conf
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 nova.conf is just one small piece. The current situation is confusing to new users and makes it more difficult for old users to try new versions of OpenStack in real environments. I realize this is a difficult issue because different distros do the packaging differently. -David On 1/24/2012 2:19 PM, Jesse Andrews wrote: There have been conversations about changing that. That nova should use /etc/nova/nova.conf Thoughts? On Tue, Jan 24, 2012 at 10:40 AM, Jorge Luiz Correacorre...@gmail.com wrote: When using Devstack the files are written to /opt/stack/component. So, you can find nova.conf in /opt/stack/nova/bin/. Regards. On Tue, Jan 24, 2012 at 3:48 PM, Joe Smithianjoe.smith...@gmail.com wrote: Hi All, I installed OpenStack using devsatck script (http://devstack.org/) on Ubuntu 11.10. Installation was successful but there is no /etc/nova/ directory and It looks like that devstack script doesn't install all the nova services. Should I install them manually as described in the getting started documents? All the openStack are installed at /opt/stack/. Should I create symbolic link at /etc/nova? Thanks Joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- - MSc. Correa, J.L. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Providing packages for stable releases of OpenStack
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 of value in using the same installation mechanism for QA as for production. This, for us, is the main issue. We use devstack for various things but unfortunately install from source is very different from install for production, more so in python/openstack than some other technologies. When we are testing a new build to see whether a problem was fixed or a new feature is working we just want to change the pointer to the ppa. I understand that if some source change induces the need for a packaging change then an auto-created ppa will stop working. It is also true that creating packages as part of a build process may end up favoring some packaging system over another. Still, I don't think that is a reason to force users to have their own (or, cringe, manual) processes to create packages that can feed into a test-for-production environment when jenkins can just do it for a few popular systems. -David ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] swift account not found
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 after creating and configuring all nodes, when i want to check that swift works, I execute this command : swift -A https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0 -U system:root -K testpass stat but I have an error : Account not found I followed this site step by step : http://swift.openstack.org/howto_installmultinode.html Can any one please help me Thanks in advance for any help Best regards Khaled ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone versioning and tarballs
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: https://github.com/openstack/keystone/commit/2bb474331d73e7c6d2a507cb097c50cfe65ad6b6 This commit is required for the ec2 api to work with keystone. Seems like we need to move the tag or create a keystone/stable branch and pull this in. Vish On Oct 24, 2011, at 12:03 AM, Mark McLoughlin wrote: Hey, I just noticed a few things when reviewing the Fedora packaging of keystone: - There's no diablo release tarball on https://launchpad.net/keystone like other projects - The 2011.3 tag in git has version=1.0 in setup.py. Which versioning scheme is keystone going to follow? - The version in master is non-numeric 'essex' rather than e.g. 2011.3 or 1.1 Thanks, Mark. ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone and euca-tools
OK, thanks. I guess that was a problem I was going to run into next. But how do you generate the EC2_* shell variables that euca tools need when using keystone? With the old nova auth this was done with 'nova-manage project zipfile' but that does not work with keystone because there are no longer users in the nova database. Am I missing something? -David On 10/13/2011 9:21 AM, Akira Yoshiyama wrote: Hi, We are testing nova, glance, swift and keystone of diablo release now. You can use nova + keystone with euca-tools if you applied a patch for two bugs in keystone/middleware/ec2_token.py that I reported. But there is no official keystone fileter for swift3 (S3 API for swift). So, you can't use swift + keystone with euca-tools. Today I wrote a s3-token keystone filter and patches for keystone and swift3. We can upload images to keystoned swift with euca-upload-bundle. 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 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 there, or is their going to be, a way to use euca-tools with keystone in place? ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone and euca-tools
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 there, or is their going to be, a way to use euca-tools with keystone in place? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
