| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 12:45:07 | jaypipes | cdent: didn't know I could do that. | |
| 12:45:36 | cdent | it just falls out of the nature of json path '$' is 'everything' | |
| 12:45:43 | jaypipes | cdent: that would work. though a little hackery would allow one to remove the need for the $: | |
| 12:46:14 | jaypipes | cdent: if, say, Gabbit saw a "response_yaml_exact" tag in the gabbit. | |
| 12:46:55 | cdent | jaypipes: if you read around in that thread, especially the message I linked to, there's some discussion on options for how to do it. A little more discussino ought to lead to some reasonable outcomes | |
| 12:47:31 | cdent | the main thrust of the thread is to be able to read in files that are the json, but it's the same deal in the abstract | |
| 12:47:49 | bauzas | cdent: out of curiosity because I had the problem on Monday, how can I introspect a gabbi functional test? | |
| 12:48:50 | cdent | bauzas: depends on the kind of introspection you want to be doing, but you can make an individual test 'verbose' with 'verbose: True' but frequently the output will be swallowed, depending on the environment | |
| 12:49:03 | cdent | another option is to add a response_strings:\n- something that won't match | |
| 12:49:10 | cdent | and then it will fail and you can see the response | |
| 12:49:14 | bauzas | cdent: basically debugging | |
| 12:49:19 | bauzas | ie. pdb'ing | |
| 12:49:34 | bauzas | since tox can't do that, I generally use testtools.run directly | |
| 12:50:08 | bauzas | but since placement tests are generated by an helper, I can't directly use it | |
| 12:50:26 | bauzas | because testtools.run can't find the test I wanted to debug | |
| 12:50:36 | cdent | subunit.run can | |
| 12:51:16 | bauzas | a-ha! | |
| 12:51:51 | bauzas | at least "python -m testtools.run discover --load-list my-list" is not possible | |
| 13:04:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Always refresh cache when checking extensions https://review.openstack.org/480674 | |
| 13:04:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add '_has_dns_extension' function https://review.openstack.org/480675 | |
| 13:04:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use dns_domain value from neutron in os-vif wiring https://review.openstack.org/480676 | |
| 13:04:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: metadata: Don't use nova-net DNS values with neutron https://review.openstack.org/480616 | |
| 13:12:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: metadata: Don't use nova-net DNS values with neutron https://review.openstack.org/480616 | |
| 13:16:14 | stephenfin | mriedem, sean-k-mooney: Could either of you explain to me how 'os_vif.objects.network.Network' relates to 'nova.network.model.Network'? | |
| 13:16:57 | stephenfin | sorry - jaypipes ^ | |
| 13:17:10 | stephenfin | I thought we were using the former in [1], but it seems we're not. What's the whole point of the os_vif version if we define our own model? [1] https://review.openstack.org/#/c/480676/ | |
| 13:17:34 | jaypipes | stephenfin: the idea is to eventually get rid of the nova model. | |
| 13:17:46 | jaypipes | stephenfin: and have Neutron just return a serialized os-vif object. | |
| 13:18:04 | jaypipes | stephenfin: we're gradually getting there. but will be a while before we do. | |
| 13:18:20 | stephenfin | jaypipes: I'm guessing that means the 'neutron.objects.network.Network' model will go away then too? | |
| 13:18:22 | stephenfin | Ideally | |
| 13:18:52 | jaypipes | stephenfin: well, that may store some internal (to Neutron) stuff, so not sure... | |
| 13:18:58 | stephenfin | Well, maybe not, but neutron will translate 'neutron.objects.network.Network' -> 'os_vif.objects.network.Network' for sending over the wire | |
| 13:19:08 | jaypipes | stephenfin: os-vif objects are intended to be the shared model between nova and neutron. | |
| 13:19:17 | jaypipes | stephenfin: ya, zactly. | |
| 13:20:51 | cdent | bauzas: you can do something like the following. part of the trick is getting the name of the test right in the face of your discover path: | |
| 13:20:56 | cdent | .tox/functional/bin/python -m subunit.run discover -v nova/tests/functional/api/openstack/placement --load-list <(echo test_placement_api.allocations_check_usages.test_request) | subunit-trace | |
| 13:21:26 | stephenfin | jaypipes: Gotcha. Thanks for the info :) | |
| 13:22:52 | bauzas | cdent: okay | |
| 13:23:21 | bauzas | I need to look more at the subunit framework | |
| 13:23:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Store dns_domain value from neutron https://review.openstack.org/480676 | |
| 13:23:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: metadata: Don't use nova-net DNS values with neutron https://review.openstack.org/480616 | |
| 13:23:42 | cdent | that works for testtools.run as well. if you s/subunit/testtools/ is all good | |
| 13:23:52 | cdent | (and get rid of subunit-trace) | |
| 13:25:03 | cdent | bauzas: then I guess you'd hork pdb in there somewhere. What would your normal of doing that be? | |
| 13:25:49 | bauzas | I usually pdb.set_trace() somewhere and then I just python -m testtools.run the UT I wanna check | |
| 13:27:19 | stephenfin | bauzas: RE: https://review.openstack.org/#/c/391060, I'm going to leave that til mriedem and melwitt come back to it, as they'd similar feedback and it's unchanged since | |
| 13:34:00 | cdent | bauzas: heh, turns out I wrote a faq about this a while ago: https://gabbi.readthedocs.io/en/latest/faq.html#is-gabbi-only-for-testing-python-based-apis | |
| 13:34:13 | cdent | whoops, wrong link: https://gabbi.readthedocs.io/en/latest/faq.html#how-do-i-run-just-one-test | |
| 13:37:07 | jaypipes | tox -efunctional && ./jay-get-breakfast.bash | |
| 13:37:29 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 13:48:49 | bauzas | stephenfin: fair enough | |
| 13:49:27 | bauzas | cdent: cool, I looked at the gabbi docs, but didn't find it | |
| 13:50:02 | ildikov | jaypipes: it could almost include breakfast and lunch... :) | |
| 13:51:11 | dansmith | jaypipes: that will get breakfast after the run, I think you want (tox -e functional&); ./jay-get-breakfast.sh | |
| 14:00:15 | mriedem | stephenfin: what happened to sfinucan? | |
| 14:01:21 | stephenfin | mriedem: I wanted cross-promotional, deal mechanics, revenue streams, jargon synergy | |
| 14:01:36 | stephenfin | i.e. I use 'stephenfin' everywhere else and wanted to switch here too | |
| 14:01:52 | mriedem | gah | |
| 14:02:56 | stephenfin | plus there's an 'e' missing from 'sfinucan' which has resulted in more than one incorrectly addressed email | |
| 14:03:01 | cdent | I'm suffering from brand dilution with this cdent/anticdent thing | |
| 14:03:25 | stephenfin | (that is also my Red Hat email alias, but not for long) | |
| 14:03:30 | mriedem | dansmith: i'm in a quandary if you have 5 minutes | |
| 14:03:53 | mriedem | otherwise i shall take it to the ML | |
| 14:03:57 | dansmith | mriedem: okay | |
| 14:04:08 | stephenfin | cdent: You should hire Liz Lemon - she's much better than me at this stuff https://www.youtube.com/watch?v=aocZo3oeNxw | |
| 14:04:39 | mriedem | dansmith: the extend volume change in nova - https://review.openstack.org/#/c/454322/ - i started writing a tempest test for that yesterday, since there is also a cinder change, | |
| 14:04:53 | mriedem | the user (non-admin) can extend their volume in cinder, so like 1G->2G, | |
| 14:04:59 | cdent | stephenfin: she's probably busy | |
| 14:05:07 | mriedem | cinder will call the os-server-external-events API telling nova the volume attached to a server was resized, | |
| 14:05:21 | mriedem | we send that down to the compute to fiddle the os-brick bits (i'm channeling johnthetubaguy-speak here) | |
| 14:05:31 | mriedem | "fiddling bits" is a british term right? | |
| 14:05:47 | dansmith | mriedem: I believe it is yes | |
| 14:05:54 | mriedem | so i asked that an instance action get tracked on the nova side since this is all async, | |
| 14:05:57 | mriedem | that's done, all well and good, | |
| 14:06:00 | edleafe | stephenfin: I settled on 'edleafe' long ago for all my accounts. Not enough brain cells to keep track of different handles | |
| 14:06:12 | mriedem | problem comes in on the api user side trying to sort out when the actual operation is done on the nova side, | |
| 14:06:18 | edleafe | stephenfin: plus all the branding synergy, of course | |
| 14:06:29 | mriedem | i was relying on the instance action events in tempest - however, the events are only shown for admin users | |
| 14:06:30 | stephenfin | edleafe: Yup, my problem exactly. Plus it helps with branding | |
| 14:06:32 | stephenfin | jinx :) | |
| 14:06:43 | edleafe | :) | |
| 14:06:47 | mriedem | so we can get tempest to work since we have admin and non-admin creds, but that's a hack, | |
| 14:06:57 | mriedem | so i was thinking, we should probably set a task_state on the instance in this case, | |
| 14:07:05 | dansmith | mriedem: UGH | |
| 14:07:09 | mriedem | so the api user can poll the task state change to know when the nova side is done | |
| 14:07:11 | mriedem | i know | |
| 14:07:27 | dansmith | mriedem: that's not really what task_state is for, IMHO, so it would be a bad choice | |
| 14:07:47 | mriedem | well, unless there is something else, it's task_state or instance actions, | |
| 14:07:47 | dansmith | that and it will lock us from doing anything like a shutdown or something if that gets hung | |
| 14:07:48 | dansmith | which is fairly icky | |
| 14:07:52 | mriedem | and as noted, the action events are admin-only | |
| 14:07:59 | mriedem | well, | |
| 14:08:01 | dansmith | well, vm_state has fewer issues with that, | |
| 14:08:08 | dansmith | but I'm loathe to alter any of them really | |
| 14:08:13 | mriedem | i considered that an upside - that someone can't stop your instance while it's having the volume extended | |
| 14:08:26 | mriedem | but, | |
| 14:08:35 | dansmith | so they can see the action but not the events? | |
| 14:08:41 | mriedem | we also can't accept the call from cinder if the task_state is already set either, b/c we'd get UnexpectedTaskStateERror | |
| 14:08:45 | mriedem | dansmith: correct | |