| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-20 | |||
| 20:56:14 | mriedem | so yeah, the osc --block-device param is definitely less robust than the nova boot one | |
| 20:56:19 | melwitt | yeah, maybe. I was trying to do from image | |
| 20:56:25 | mriedem | but to be fair, | |
| 20:56:32 | mriedem | every time i need to use nova boot --block-device, | |
| 20:56:35 | mriedem | i have to parse the help first | |
| 20:58:27 | melwitt | yeah. we'd just have to turn our attention to making sure commands like those can be one step and keep them working | |
| 20:59:03 | melwitt | long ago I wondered if we could make the novaclient stuff be an osc plugin, that way we can take care of the test coverage/regression coverage for our commands | |
| 21:00:08 | melwitt | in our tree | |
| 21:00:41 | mriedem | there are a lot of easy low hanging CLIs we could deprecate though b/c they have coverage in osc, | |
| 21:00:48 | mriedem | like create snapshot image, add/remove volume/interface, etc | |
| 21:00:57 | mriedem | the more exotic server create stuff would yeah be a wip | |
| 21:01:26 | mriedem | i was also watching an older k8s talk where everything was a single command line and realized they kind of figured that out from the beginning, | |
| 21:01:42 | mriedem | so people new to k8s don't have to figure out you need 6 different client libs installed to do something | |
| 21:04:18 | mnaser | mriedem: the bug that keeps on giving. when changing to the old fixture, https://github.com/openstack/nova/blob/stable/pike/nova/compute/api.py#L2008 checks for an attachment_id, but it doesn't have one from the fixtures.. sooo "Ignoring volume cleanup failure due to Object action obj_load_attr failed because: attribute attachment_id not lazy-loadable" | |
| 21:05:09 | mnaser | (therefore the functional test fails and the volume is still 'reserved' because it doesn't go into the 'else' codepath and detach) | |
| 21:06:13 | mriedem | mnaser: hmm, it wouldn't come from the fixture, | |
| 21:06:17 | mriedem | it should just be default to None in the DB | |
| 21:06:37 | mriedem | i mean, we create the bdm in cell0 | |
| 21:06:51 | mriedem | so when it's read back out, that should be null | |
| 21:07:00 | mnaser | maybe not in this case | |
| 21:07:07 | mnaser | because you pass it the bdms not from db | |
| 21:07:47 | mriedem | oh i know what it is, | |
| 21:07:52 | mriedem | the bdms in the build request | |
| 21:08:04 | mriedem | those don't have the attachment_id | |
| 21:08:11 | mnaser | yeah | |
| 21:08:21 | mnaser | `build_req.block_device_mappings` is whats passed | |
| 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 | zigo | https://bugs.launchpad.net/nova/+bug/1750672 | |
| 21:42:37 | openstack | Launchpad bug 1750672 in OpenStack Compute (nova) "failure to generate Nova's doc in Python 3.6" [Undecided,New] | |
| 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 | |