| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-20 | |||
| 18:00:04 | dansmith | edleafe: around? | |
| 18:01:33 | melwitt | yeah. as usual, the beginning of the cycle people are reviewing specs more because as you said, have to approve things before we can focus on reviewing the implementations. I think people are already doing that. last cycle we had a 79% approved spec/bp completion percentage so I think this cycle we're probably going to approve fewer things to increase that percentage significantly | |
| 18:02:19 | melwitt | like last cycle, we'll have a dedicated spec review day to burn through a lot of them before spec freeze. that's what I'm going to send email about this week so we can pick a date that works for most | |
| 18:02:59 | edleafe | dansmith: yeah - somewhat distracted atm | |
| 18:03:41 | dansmith | edleafe: okay, I'm having trouble getting member_of to work and there's kindof a missing case in your tests, which I thought maybe was covering up a bug, but I tweaked it and it still passes, so .. I'm still digging | |
| 18:04:01 | dansmith | edleafe: but, I've associated a provider with an aggregate, but when I member_of it, I get back no candidates | |
| 18:04:36 | edleafe | dansmith: that's... odd | |
| 18:04:47 | edmondsw | melwitt just a little anxious not seeing reviews on the powervm spec. I'd have thought it was a fairly easy review. I believe the nova team is already committed to this effort and it's just a matter of how much or how little we bite off per release, not whether. I'd like to get the rocky content locked down. | |
| 18:05:08 | edleafe | dansmith: the gabbi tests show that exact case | |
| 18:05:31 | edmondsw | we've been putting up commits for review, but until the spec is approved hard to ask anyone to look at functional commits | |
| 18:05:33 | melwitt | edmondsw: has it been previously approved? I don't know the history about it | |
| 18:05:49 | edmondsw | melwitt yes, and the history is all in the spec at the end | |
| 18:05:55 | dansmith | edleafe: yeah, I know, that's why I'm trying to diff what I'm doing with those | |
| 18:06:02 | edmondsw | melwitt it's a multirelease effort | |
| 18:06:21 | edmondsw | melwitt since it was considered too much to bite off in one release from a reviewer bandwidth perspective | |
| 18:06:25 | dansmith | edleafe: you don't have a case where you only have one thing in member_of that actually returns results, but I shaved one down and it still seems to work (although it's hard to know if it's returning the thing we expect | |
| 18:06:48 | edmondsw | melwitt https://review.openstack.org/#/c/545111/ | |
| 18:08:08 | artom | So, do we handle *any* NUMA stuff during live migration? I know hugepages and CPU pinning aren't, but what about plain old NUMA topology? | |
| 18:09:03 | openstackgerrit | Merged openstack/nova master: Remove old flavor_access_get_by_flavor_id db api method https://review.openstack.org/539720 | |
| 18:09:04 | melwitt | edmondsw: okay, probably just needs some reminding then. looks like mriedem has reviewed it last month so maybe he can take another look at it soon | |
| 18:09:21 | edleafe | dansmith: you could inspect the returned a-c, but that's always too complicated to write in gabbi | |
| 18:09:46 | dansmith | edleafe: yeah, I'm doing that in my real test and getting back [], but I dunno how to do much with the gabbit | |
| 18:09:47 | cdent | edleafe: untrue, either make the test verbose: True or make it fail intentionally in the response_json_paths | |
| 18:09:54 | openstackgerrit | Merged openstack/nova master: Remove old flavor_destroy db api method https://review.openstack.org/539729 | |
| 18:10:00 | dansmith | but it's checking the length of allocation_requests | |
| 18:10:04 | cdent | and the error message will show the full response | |
| 18:10:23 | openstackgerrit | Merged openstack/nova master: Remove old flavor_get_by_flavor_id db api method https://review.openstack.org/539733 | |
| 18:10:35 | openstackgerrit | Merged openstack/nova master: Remove old flavor_get_by_name db api method https://review.openstack.org/544379 | |
| 18:10:36 | dansmith | cdent: ah, duh, trying | |
| 18:10:47 | openstackgerrit | Merged openstack/nova master: Remove old flavor_get db api method https://review.openstack.org/544621 | |
| 18:10:58 | openstackgerrit | Merged openstack/nova master: Remove old flavor_get_all db api method https://review.openstack.org/544688 | |
| 18:11:10 | openstackgerrit | Merged openstack/nova master: Remove old flavor_create db api method https://review.openstack.org/544703 | |
| 18:11:35 | openstackgerrit | Merged openstack/python-novaclient master: Fix local test fails with pypy https://review.openstack.org/553426 | |
| 18:11:45 | dansmith | cdent: I tried just setting the asserted length to something wrong, but it doesn't show me anything else other than 17 != 1 | |
| 18:12:03 | cdent | dansmith: yeah, I meant something more breaking that that: | |
| 18:12:19 | cdent | response_json_paths:\n $: foo | |
| 18:12:39 | cdent | will try to compre the whole json object to foo | |
| 18:14:11 | vivsoni__ | In case of 'nova create' - NO cinder API is called | |
| 18:14:18 | vivsoni__ | In case of 'nova delete' - NO cinder API is called | |
| 18:15:10 | vivsoni__ | Hi Team, please correct if my understanding is wrong | |
| 18:15:25 | mriedem | if you're booting from volume then of course cinder is called | |
| 18:15:44 | mriedem | if you've attached volumes before you delete the instance, of course cinder is called | |
| 18:15:46 | vivsoni__ | mriedem: ok | |
| 18:16:36 | edleafe | cdent: /me learns new gabbi trick | |
| 18:16:51 | dansmith | cdent: edleafe: yeah, well, that clearly shows it's working as expected | |
| 18:16:56 | dansmith | so I be stumped | |
| 18:17:04 | dansmith | if I don't pass member_of, I get back the things I expect | |
| 18:17:42 | vivsoni__ | mriedem: so if my instance is attached to volume, then if i shutoff the nova instance and restart the instance... then cinder api of detach and attach is called is it ? | |
| 18:17:53 | dansmith | interestingly, the request logging from placement is urlencoded from inside my functional test, but not when the gabbit runs | |
| 18:18:10 | dansmith | so I wonder if it's getting more than the uuid | |
| 18:18:12 | mriedem | vivsoni__: no, if you're just stopping and starting the instance, nova doesn't detach the volume | |
| 18:19:00 | edleafe | dansmith: are you sending a single uuid string, or a 1-element list? | |
| 18:19:30 | dansmith | edleafe: I've tried both, initially just one, then tried in:$uuid | |
| 18:20:11 | vivsoni__ | mriedem: ok... i wanted to understand more on 'nova create/delete/live-migration' w.r.t cinder api call.. do you have some reference link, if yes, please share | |
| 18:21:27 | mriedem | vivsoni__: not really | |
| 18:21:44 | mriedem | vivsoni__: hemna has some diagrams of those flows though i think | |
| 18:21:52 | mriedem | not sure if they are published | |
| 18:22:26 | vivsoni__ | ok | |
| 18:22:34 | dansmith | edleafe: yeah I know | |
| 18:22:54 | dansmith | edleafe: I printed member_of from inside the normalize function and it is properly [$uuid] | |
| 18:23:19 | cdent | dansmith, edleafe: any chance that this is the result of some base database condition that is different between the dan tests and the ed tests? | |
| 18:23:31 | dansmith | cdent: such as what? | |
| 18:24:09 | dansmith | cdent: I can get /resource_providers/$rp/aggregates and I get back $uuid | |
| 18:24:23 | dansmith | so I feel like placement is working and storing the association I made | |
| 18:25:07 | dansmith | ohhhhhhh | |
| 18:25:22 | dansmith | I may be completely stupid | |
| 18:25:23 | dansmith | maybe | |
| 18:27:34 | dansmith | edleafe: I deserve whatever was coming before you bit your tongue for this one | |
| 18:29:14 | dansmith | good news, member_of seems to work.. EOM | |
| 18:29:24 | efried | Well now you gotta tell us what you were doing wrong. | |
| 18:29:31 | efried | Not just so we can make fun of you - although that too. | |
| 18:29:40 | efried | But mainly so we can avoid similar pratfalls ourselves. | |
| 18:29:53 | efried | And therefore avoid being made fun of in turn. | |
| 18:30:18 | edleafe | uh, yeah - for *education* | |
| 18:31:00 | dansmith | I had a method that would create and add hosts to aggregates, both in nova and placement | |
| 18:31:11 | dansmith | and the nova call I was making is additive, where the placement one is declarative | |
| 18:31:38 | dansmith | so I was putting multiple hosts in the nova aggregates, but only in the latest placement one | |
| 18:31:45 | dansmith | and the last placement one I created was "no-hosts" | |
| 18:31:48 | dansmith | so, you know.. | |
| 18:32:09 | dansmith | and the order in which I was printing debug stuff was consistent, but.. not the full story | |
| 18:33:54 | edleafe | wish I could say I | |
| 18:34:02 | mriedem | https://www.youtube.com/watch?v=AMQ8E3mTgY0 | |
| 18:34:03 | edleafe | I've never done something similar | |
| 18:34:18 | dansmith | mriedem: yeah I know, but thanks for putting into visual form | |
| 18:34:29 | mriedem | ha | |
| 18:35:17 | mriedem | ask smcginnis or jungleboyj, i was bashing my head for about 2 hours one morning over a unit test i was writing and couldn't figure out why it didn't work | |
| 18:35:33 | mriedem | can't remember what it was, but it was really dumb | |
| 18:36:17 | edleafe | cdent: ok, given the output using your trick: http://paste.openstack.org/show/706443/, how would I reference the resource provider uuid within the response_json_paths in order to compare it to the cn1uuid? | |
| 18:38:25 | cdent | edleafe: reading | |
| 18:38:29 | smcginnis | mriedem: What what? | |
| 18:40:32 | mriedem | smcginnis: last time i was at claddagh and we were upstairs, i was trying to get a gd unit test working most of the morning | |
| 18:40:41 | mriedem | maybe i was the only one that heard my swearing | |
| 18:41:08 | cdent | edleafe: you can to check that the cn1uuid is in there, which in there? | |
| 18:41:13 | smcginnis | Oh yeah, I remember now. :) | |
| 18:41:14 | cdent | s/can/want/? | |
| 18:42:33 | edleafe | cdent: dunno, just thought that checking that it's in there wasn't definitive enough. Getting allocation_requests[0].keys()[0] or something like that | |
| 18:42:35 | melwitt | I'm able to repro the EndpointNotFound problem in an old devstack I have, and what I get from ksa_adapter.get_endpoint() in both the non-list and interface list cases is: "*** EmptyCatalog: The service catalog is empty." | |
| 18:43:08 | melwitt | even though I have glance in 'openstack endpoint list' | |
| 18:44:30 | cdent | edleafe: if you know the uuid in advance, it's generally easier to check for some key down its path. you can do environ and response expansions within the left hand side of a json path thing | |
| 18:45:04 | efried | melwitt: Can you show me your openstack endpoint list for glance? | |