| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 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 | |
| 14:09:02 | mriedem | https://review.openstack.org/#/c/480792/ | |
| 14:09:03 | dansmith | mriedem: does the action get the finish_time set when it's done? | |
| 14:09:07 | mriedem | nope | |
| 14:09:09 | mriedem | that's on the event | |
| 14:09:19 | dansmith | mriedem: not according to the object model | |
| 14:09:21 | sean-k-mooney | stephenfin: os_vif.objects.network.Network is used to pass info the os-vif plugins about the network such as mtu, it is created from nova.network.model.Network. nova.network.model.Network is used to pass network related info that will be needed to influenc the libvirt xml generation. you only need to modify nova.network.model.Network so that you can populate the metatda for cloud init | |
| 14:09:47 | dansmith | mriedem: https://github.com/openstack/nova/blob/master/nova/objects/instance_action.py#L39-L39 | |
| 14:10:28 | mriedem | hmm, i don't know if anything calls action_finish or finish, | |
| 14:10:29 | mriedem | looking | |
| 14:11:00 | mriedem | i know we don't expose finish_time in the api for the action https://developer.openstack.org/api-ref/compute/?expanded=list-actions-for-server-detail#servers-actions-servers-os-instance-actions | |
| 14:11:03 | mriedem | only the events | |
| 14:11:07 | mriedem | but that could easily be changed | |
| 14:11:09 | dansmith | heh | |
| 14:11:15 | sean-k-mooney | stephenfin: we basicaly need to create os_vif.objects.network.Network so that there would not be a circular dependency between os-vif and nova. | |
| 14:11:34 | stvnoyes1 | good morning mriedem: I updated the live migrate review, addressing your comments. Please take a look when you get a chance. Thanks. - https://review.openstack.org/#/c/463987/ | |
| 14:11:47 | dansmith | mriedem: I wonder why that is, but it seems like that'd be a thing you look for if you're using the action to identify the long-running thing | |
| 14:12:43 | mriedem | dansmith: yeah so nothing calls InstanceAction.action_finish / finish today | |
| 14:12:54 | mriedem | so we have the finish-time field in the data model, but nothing sets it | |
| 14:13:02 | mriedem | stvnoyes1: ok | |
| 14:13:04 | dansmith | hrm, that seems weird | |
| 14:13:14 | dansmith | and unfortunate | |
| 14:13:47 | mriedem | i think i asked alaski about this a long time ago, | |
| 14:13:52 | mriedem | and the tasks api came up | |