| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-20 | |||
| 21:08:25 | mriedem | yeah, crap | |
| 21:08:33 | mnaser | that change hasnt merged yet | |
| 21:08:37 | mnaser | if you want to abandon and restore | |
| 21:08:47 | mnaser | https://review.openstack.org/#/c/545132/ | |
| 21:09:05 | mriedem | well, it's not a problem in master or queens... | |
| 21:09:37 | mnaser | what's happening differently here if you dont mind me asking? | |
| 21:11:17 | mriedem | mnaser: we don't have https://github.com/openstack/nova/blob/stable/queens/nova/compute/api.py#L3765 in pike | |
| 21:11:30 | mnaser | ahhh i see | |
| 21:11:35 | mnaser | the attachments are created in db there | |
| 21:11:45 | mriedem | well, they bdm.attachment_id field is set | |
| 21:11:55 | mnaser | because the bdm is saved into db, i see | |
| 21:11:57 | mriedem | and the bdm is then later stored in the build request | |
| 21:12:09 | mriedem | so this is also a problem in queens if you have pike computes | |
| 21:12:12 | mriedem | it's really a different bug | |
| 21:12:33 | mriedem | so in the delete code, we need logic like, "if 'attachment_id' in bdm and bdm.attachment_id:" | |
| 21:12:39 | mriedem | mnaser: feel like opening a new bug? | |
| 21:13:39 | mnaser | mriedem: sure, ill do that | |
| 21:14:11 | mnaser | i'll reorder the backports so that fix comes right before the one that enables the functional test once it goes in master so it can pass | |
| 21:14:47 | mriedem | yeah i should have also added the recreate for the older cinder fixture as well, but was lazy | |
| 21:14:57 | mriedem | i guess can do that as part of the new bug fix | |
| 21:15:15 | mnaser | i already have it so ill reuse it | |
| 21:15:21 | mriedem | cool | |
| 21:20:05 | mnaser | https://bugs.launchpad.net/nova/+bug/1750666 probably not the best description but feel free to edit it, ill push up something | |
| 21:20:06 | openstack | Launchpad bug 1750666 in OpenStack Compute (nova) "Deleting an instance before scheduling with BFV fails to detach volume" [Undecided,New] | |
| 21:20:44 | openstackgerrit | Mohammed Naser proposed openstack/nova stable/pike: Add functional recreate test of deleting a BFV server pre-scheduling https://review.openstack.org/546222 | |
| 21:21:12 | mnaser | gah | |
| 21:26:07 | openstackgerrit | Mohammed Naser proposed openstack/nova stable/pike: Add functional recreate test of deleting a BFV server pre-scheduling https://review.openstack.org/546222 | |
| 21:27:08 | cfriesen | mriedem: does osc support automatic block live migration yet? last I checked you had to manually specify block migration | |
| 21:29:38 | mnaser | if i do git-review -d <change>, commit on top and git review .. will that prevent messing up the stack (or should i use -R ?) | |
| 21:30:19 | mnaser | the commit IDs match so i think i should be ok? | |
| 21:30:45 | dansmith | mnaser: depends | |
| 21:30:49 | dansmith | mnaser: you mean commit --amend? | |
| 21:30:54 | mnaser | nope, a seperate commit on top | |
| 21:31:10 | dansmith | that will create a new change, on top of the one you downloaded | |
| 21:31:15 | dansmith | if that's what you want then that's fine | |
| 21:31:18 | zigo | I got a weirdo Python 3 issue when generating Nova sphinx doc, can someone have a look? I tried to fix it for a long time and didn't succeed: http://paste.openstack.org/show/679271/ | |
| 21:31:27 | dansmith | but without -R it will/may rebase both when it submits | |
| 21:31:28 | mnaser | dansmith: yes, dont want to touch the changes below, but want to build on top of them | |
| 21:31:42 | dansmith | then yes, but I would use -R if you really want to avoid disturbing the one below | |
| 21:31:45 | zigo | The same passes in Py 2.7. | |
| 21:31:48 | mnaser | ok i'll do that, thank you dansmith | |
| 21:32:15 | dansmith | np | |
| 21:32:33 | zigo | It probably is an issue in blockdiag itself though... | |
| 21:34:45 | zigo | Everything else (ie: all Nova unit tests) pass in Py 3.6. | |
| 21:35:00 | zigo | Should I file a bug? | |
| 21:36:48 | melwitt | zigo: yeah, filing a bug would help. are you trying to run the tox 'docs' target or? | |
| 21:37:15 | zigo | melwitt: No, I'm building the Nova Debian package for Queens. | |
| 21:37:33 | zigo | No tox when doing packaging. | |
| 21:37:42 | melwitt | actually I see the 'docs' target is pinned to python 2.7, probably because of the bug you're hitting | |
| 21:37:55 | zigo | melwitt: PYTHONPATH=. python3 -m sphinx -b html doc/source $(CURDIR)/debian/nova-doc/usr/share/doc/nova-doc/html | |
| 21:37:58 | zigo | That's what I run. | |
| 21:38:22 | zigo | melwitt: Well, I do need the docs to also pass in Py3, since I'll be removing all traces of Py 2.7 in the Debian packages. | |
| 21:39:12 | zigo | Worst case, I'll remove the block dragram from the doc that is crashing sphinx. | |
| 21:39:33 | zigo | I'd of course prefer not to do that. | |
| 21:39:36 | melwitt | yeah ... based on the "basepython = python2.7" for docs in tox.ini, it's known not to build under py3 but I don't know why. I'd want to get stephenfin to look at it but he's out on PTO this week | |
| 21:42:00 | zigo | melwitt: No worries! :) | |
| 21:42:37 | openstack | Launchpad bug 1750672 in OpenStack Compute (nova) "failure to generate Nova's doc in Python 3.6" [Undecided,New] | |
| 21:42:37 | zigo | https://bugs.launchpad.net/nova/+bug/1750672 | |
| 21:47:28 | melwitt | thanks | |
| 21:51:27 | mriedem | cfriesen: don't know, it might assume you have to specify that, but you could open a bug and say if microversion >= x, don't require some option | |
| 21:51:49 | mriedem | cfriesen: melwitt: so there will definitely need to be some currency stuff like that in osc, like this https://review.openstack.org/#/c/546176/ | |
| 21:51:53 | mriedem | but it's pretty simple for most of it | |
| 21:52:04 | mriedem | oops wrong patch | |
| 21:52:15 | mriedem | https://review.openstack.org/#/c/545946/ | |
| 21:52:21 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Add functional test for deleting BFV server with old attach flow https://review.openstack.org/546315 | |
| 21:54:02 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Add functional test for deleting BFV server with old attach flow https://review.openstack.org/546315 | |
| 21:54:14 | mnaser | aaand thats a step 1 | |
| 21:54:26 | melwitt | mriedem: okay, that's cool. what about the auto-discover-latest behavior of the CLI? from what I understand, that's not something they wanted to allow in osc | |
| 21:56:40 | mriedem | melwitt: that doesn't exist in osc | |
| 21:56:44 | mriedem | or most CLIs besides nova's | |
| 21:56:48 | mriedem | i.e. cinder CLI doesn't do that either | |
| 21:57:27 | melwitt | I know | |
| 21:57:55 | melwitt | but I thought we would want to keep that, I've never understood how it's useful for a CLI to default to the lowest microversion | |
| 21:59:16 | melwitt | and I thought we discussed it in a forum session about osc last time, but I don't remember if we got any consensus or next steps about it | |
| 21:59:29 | zigo | melwitt: Here's the line that crashes everything: https://salsa.debian.org/openstack-team/services/nova/blob/debian/queens/debian/patches/remove-crashing-blockdiag-doc-line.patch | |
| 22:00:39 | melwitt | zigo: huh. interesting | |
| 22:00:51 | cfriesen | melwitt: yeah, I remember some discussion too. I pinged the OSC folks about microversion stuff but they basically said they had a plan and didn't seem to want any help with it. | |
| 22:01:20 | mriedem | melwitt: it was discussed in the user session in boston | |
| 22:01:35 | mriedem | and i think the consensus was "we should be consistent" but no decisive answer on which consistency is best | |
| 22:03:03 | mriedem | i can't remember which specific session now https://wiki.openstack.org/wiki/Forum/Boston2017 | |
| 22:03:06 | melwitt | okay. agreed on consistency. we'll need to re-sync with the osc team on that if we're going to get serious about deprecating the nova CLI | |
| 22:03:43 | jroll | melwitt: fwiw, the only explanation for defaulting CLIs to the lowest microversion that I've heard is so that new versions don't break bash scripts | |
| 22:03:50 | jroll | as if it's a bash sdk >.> | |
| 22:03:58 | mriedem | and we've asserted the CLI isn't an SDK | |
| 22:04:08 | mriedem | but the python API binding code is, so that's why that's opt-in | |
| 22:04:15 | melwitt | right | |
| 22:04:23 | jroll | for some definition of "we" :) | |
| 22:04:32 | mriedem | we == nova in this case | |
| 22:04:33 | mriedem | for our CLI | |
| 22:04:33 | melwitt | I don't think a bash sdk is a good idea for anyone | |
| 22:04:38 | jroll | right | |
| 22:04:46 | cfriesen | jroll: if you want that you can explicitly specify the API version in your bash script | |
| 22:05:08 | jroll | cfriesen: no I don't want that at all, just providing the anecdata that I have :)( | |
| 22:05:19 | cfriesen | "you" generally, not specifically | |
| 22:05:22 | jroll | right | |
| 22:05:22 | cfriesen | :) | |
| 22:06:15 | mriedem | well i can't find the etherpad, but i remember the discussion | |
| 22:06:20 | mriedem | i'm pretty sure it was boston | |
| 22:06:25 | mriedem | clarkb or mordred might remember | |
| 22:08:28 | melwitt | I had thought it got talked about more recently too, but maybe I'm thinking of boston and not realizing it | |