Re: [openstack-dev] heat run_tests.sh fails with one huge line of output
Hi Mike, Looks like you have some syntax error for some accidental reason. Could you please do the following: 0) install flake8; 1) run ./run_tests.sh -p pep8.log into your Heat directory; 2) Attach to the letter and send it to the list. Thank you, Alexander 2014-02-17 1:20 GMT+04:00 Mike Spreitzer mspre...@us.ibm.com: Kevin, I changed no code, it was a fresh DevStack install. Robert Collins robe...@robertcollins.net wrote on 02/16/2014 05:33:59 AM: A) [fixed in testrepository trunk] the output from subunit.run discover --list is being shown verbatim when an error happens, rather than being machine processed and the test listings elided. To use trunk - in your venv: bzr branch lp:testrepository pip install testrepository B) If you look at the end of that wall of text you'll see 'Failed imports' in there, and the names after that are modules that failed to import - for each of those if you try to import it in python, you'll find the cause, and there's likely just one cause. Thanks Robert, I tried following your leads but got nowhere, perhaps I need a few more clues. I am not familiar with bzr (nor baz), and it wasn't obvious to me how to fit that into my workflow --- which was: (1) install DevStack (2) install libmysqlclient-dev (3) install flake8 (4) cd /opt/stack/heat (5) ./run_tests.sh I guessed that your (A) would apply if I use a venv and go between (1) the `python tools/install_venv.py` inside run_tests.sh and (2) the invocation inside run_tests.sh of its run_tests function. So I manually invoked `python tools/install_venv.py`, then entered that venv, then issued your commands of (A) (discovered I needed to install bzr and did so), then exited that venv, then invoked heat's `run_tests -V -u` to use the venv thus constructed. It still produced one huge line of output. Here I attach a typescript of that: You will see that the huge line still ends with something about import error, and now lists one additional package --- heat.tests.test_neutron_firewalld. I then tried your (B), testing manual imports. All worked except for the last, which failed because there is indeed no such thing (why is there a spurrious 'd' at the end of the package name?). Here is a typescript of that: Thanks, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][glance] bp: glance-snapshot-tasks
Hi Josh, I think u are referring to the following: https://blueprints.launchpad.net/nova/+spec/glance-snapshot-tasks Yes, you're right. Can u describe the #2 part in more detail. Do some of the drivers already implement these new steps? I've mostly investigated snapshot method in libvirt driver and quick overview showed that such splitting scheme fits to all vendor-specific drivers, except Docker (it somehow connects the Glance service outside the driver). The global goal is to make snapshot implementation a bit robust, more resumable. I think two of four steps are quite expensive: making snapshot and especially uploading image to the Glance. Splitting snapshot to more atomic actions we can handle such situations in place without repetition of the whole heavy snapshot operation. Step further and we probably would implement resumable uploading to the Glance. But anyway right now there is a huge theme about common API for drivers and I would like to hear some thoughts from nova driver team. Thanks, Alexander ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] bp: glance-snapshot-tasks
Hi, A blue print was created and Joshua even wrote quite huge text. Right now this BP in Drafting stage, so I want to bring this BP to life and continue working on the topic. I even tried to make some changes without approvement (only just as experiment) and got negative feedbacks. These steps I did when tried to implement this BP: 1) Moved snapshot functionality from Compute to Conductor (as I understood it's the best place for such things, need clarification); Even this step should be done in two steps: a) Add snapshot_instance() method to Conductor that just calls the same method from Compute; b) After that move all error-handling / state transition / etc logic from Compute to Conductor. Compute exposes API for drivers (see step 2); 2) The hardest part is a common, convenient, complete API for drivers. Most drivers do almost the same things in the snapshot method: a) Goes to Glance and registers new image there; b) Makes snapshot; c) Downloads the image to the Glance; d) Clean temporary files; I would really appreciate any thoughts and questions. Thanks, Alexander ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
