| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-19 | |||
| 19:28:17 | lucidguy | I believe this bug applies to me, unfortunately I don't know how to resolve, assistance? https://bugs.launchpad.net/tripleo/+bug/1785568 | |
| 19:29:19 | mriedem | cfriesen: so if you have a minute, could you just update the note at the top of https://docs.openstack.org/nova/latest/admin/pci-passthrough.html about sriov to also mention that cold migration of servers with sriov ports attached didn't work until newton and reference that bug? | |
| 19:42:52 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | |
| 19:46:23 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | |
| 20:12:14 | openstackgerrit | Merged openstack/nova-specs master: fix spelling mistake https://review.openstack.org/573479 | |
| 20:32:25 | cfriesen | anyone know anything about "bad magic number in nova.conf.crypto" when trying to build nova docs? | |
| 20:33:34 | cfriesen | http://paste.openstack.org/show/730383/ | |
| 20:35:25 | mriedem | i've seen that i think... | |
| 20:37:02 | mriedem | py34 isn't supported... | |
| 20:37:06 | mriedem | not sure if that would be related | |
| 20:37:53 | mriedem | also, | |
| 20:37:57 | mriedem | nova.conf.crypto isn't in master | |
| 20:38:05 | mriedem | is that a starlingx special? | |
| 20:38:29 | mriedem | https://github.com/openstack/nova/blob/stable/pike/nova/conf/crypto.py | |
| 20:38:29 | mriedem | oh pike | |
| 20:39:07 | cfriesen | my regular "python" is 2.7.5. not sure why tox would use 3.4 unless it's searching for whether it's present. I'm on the master branch of upstream nova, though I have checked out pike in this repo. | |
| 20:51:14 | cfriesen | found a nova/conf/crypto.pyc file left over from a previous branch. deleted and retrying | |
| 20:54:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Mention SR-IOV cold migration limitation in admin docs https://review.openstack.org/603909 | |
| 20:55:05 | mriedem | cfriesen: huh, i thought we used to have a thing in all tox runs that would clean out pycs | |
| 20:55:13 | mriedem | but i also seem to remember someone removing that years ago | |
| 20:55:28 | mriedem | oh right it's in the base testenv, | |
| 20:55:41 | mriedem | but commands is overridden in the actual testenv:docs run | |
| 20:56:29 | mriedem | cfriesen: oh were you building those docs ^ | |
| 20:56:35 | mriedem | for the thing i just pushed? | |
| 20:58:04 | cfriesen | heh...yep | |
| 20:58:20 | mriedem | sorry, you didn't say anything so i assumed you were busy with something else | |
| 20:58:34 | cfriesen | no worries. | |
| 20:59:51 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Default zero disk flavor to RULE_ADMIN_API in Stein https://review.openstack.org/603910 | |
| 21:00:53 | cfriesen | mriedem: I almost feel like we should use PCI in there instead of SR-IOV, since it's the more generic form. Not all PCI passthrough is SR-IOV, but all SR-IOV is a form of PCI passthrough. | |
| 21:02:24 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Drop migration pre-check error for file_backed_memory https://review.openstack.org/603911 | |
| 21:02:40 | mnaser | mriedem: ^ i thought we were in openstack-nova oops | |
| 21:02:57 | cfriesen | mnaser: you are. :) | |
| 21:03:05 | mnaser | oh no i was talking in #o-operators | |
| 21:03:15 | mnaser | pushing stuffa nd wondering why the hell the bot wasn't notifying | |
| 21:03:38 | cfriesen | that'll do it | |
| 21:04:42 | mriedem | cfriesen: feel free to -1 my change and break my heart | |
| 21:05:12 | mnaser | thats my nova commit for the cycle | |
| 21:05:13 | mriedem | mnaser: i'm guessing you didn't run this through tests yet right? | |
| 21:05:17 | cfriesen | mriedem: I commented on it | |
| 21:05:22 | mnaser | mriedem: nope | |
| 21:05:24 | mnaser | i probably should | |
| 21:07:03 | mnaser | well it looks like tests should pass because the tests use a fixture of using RULE_ADMIN_API and making sure it fails | |
| 21:07:12 | mnaser | so it was testing the then-future case | |
| 21:07:40 | mriedem | mnaser: at least EnforceVolumeBackedForZeroDiskFlavorTestCase in tox -e functional | |
| 21:08:57 | mnaser | mriedem: running | |
| 21:09:05 | mriedem | comments inline | |
| 21:09:58 | mnaser | lemme address after seeing if test breaks | |
| 21:15:57 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Default zero disk flavor to RULE_ADMIN_API in Stein https://review.openstack.org/603910 | |
| 21:19:25 | mriedem | lbragstad: are dashes in policy rule names frowned upon? | |
| 21:19:37 | mriedem | e.g. os_compute_api:servers:cross-cell-resize? | |
| 21:19:42 | mriedem | should be os_compute_api:servers:cross_cell_resize? | |
| 21:19:58 | lbragstad | i don't think so | |
| 21:20:11 | lbragstad | but when i went through a bunch of the projects last week there isn't really a standard | |
| 21:20:20 | mriedem | shocking | |
| 21:20:26 | lbragstad | inoright? | |
| 21:20:46 | lbragstad | so - i guess if we're going to try and do this, i'd like to whack all the moles at once... | |
| 21:20:51 | mriedem | since the prefix is os_compute_api i assume suffix should also be underscores | |
| 21:21:11 | mriedem | oh and we have things like network:attach_external_network and create:zero_disk_flavor so nvm | |
| 21:21:14 | mriedem | answered my own question | |
| 21:21:16 | lbragstad | did you see my note about using the service name? | |
| 21:21:27 | mriedem | no, where? | |
| 21:21:46 | mriedem | i have'nt read the ML thread | |
| 21:22:08 | lbragstad | http://lists.openstack.org/pipermail/openstack-dev/2018-September/134597.html | |
| 21:22:12 | lbragstad | it starts there... | |
| 21:22:24 | lbragstad | sorry if you we waiting to parse the lists later :) | |
| 21:22:35 | mriedem | :( | |
| 21:22:54 | lbragstad | but i'm trying to update that with all context of what i've found across projects (since operators are on that note, too) | |
| 21:24:44 | mriedem | so you'd like to see compute:server:cross_cell_resize | |
| 21:24:56 | mriedem | note this is an action, | |
| 21:25:01 | mriedem | so it won't cleanly map to a method | |
| 21:25:15 | lbragstad | right | |
| 21:25:29 | lbragstad | which i guess is another reason to not put http methods in policy names? | |
| 21:25:32 | mriedem | i mean, we could do compute:servers:resize:cross_cell | |
| 21:26:29 | lbragstad | yeah - i don't think nova would be super special in that case... there are other projects have more than just <service>:<resource>:<action> | |
| 21:26:54 | lbragstad | ironic and heat for example | |
| 21:27:09 | mriedem | alright, this is months/releases away from landing so i'll just do that and move on | |
| 21:27:20 | mriedem | this is the amount of progress i've made on this since last week | |
| 21:27:47 | lbragstad | what's months away from landing? | |
| 21:27:57 | mriedem | cross-cell resize | |
| 21:28:01 | lbragstad | oh - sure | |
| 21:28:04 | mriedem | not your thing | |
| 21:28:26 | mriedem | being cross project, your thing is *years* away from landing :) | |
| 21:28:28 | lbragstad | i'd like to get the convention "established" as soon as possible, because I think it's going to affect gmann's work too | |
| 21:28:35 | lbragstad | right - let's be real here | |
| 21:41:03 | mnaser | is there a documented process for when you end up with: "Instance 13a09ff5-7124-4b3c-8229-a8691a2f43b4 has allocations against this compute host but is not found in the database." | |
| 21:41:35 | mnaser | context: dns was borked on a compute, live migration would complete, but the placement migration allocation thing fails because compute cant talk to placement | |
| 21:43:34 | mriedem | that doesn't sound like a scenario in which you'd see that message | |
| 21:44:01 | mnaser | well, it happened after fixing dns | |
| 21:44:16 | mnaser | the compute node finally started talking to placement properly and now complains forever | |
| 21:44:30 | mriedem | is that instance in the db? | |
| 21:44:52 | mnaser | hmm | |
| 21:45:02 | mriedem | the code calls out 2 cases that could happen: | |
| 21:45:03 | mnaser | no, i think the exception i was seeing was unrelated | |
| 21:45:08 | mnaser | i think it was no placement + vm deleted | |
| 21:45:23 | mnaser | i think i jumped to a conclusion there | |
| 21:45:25 | mriedem | 1. compute RT is racing with the scheduler where the scheduler created allocations in placement but didn't yet create the instance in the cell db, | |
| 21:45:45 | mriedem | 2. the instance was deleted and archived/purged from the db, but the alloctions are still in placement for that node | |
| 21:45:52 | mriedem | yeah, | |
| 21:46:03 | mriedem | so if the compute couldn't talk to placement when the vm was deleted, we'd fail to cleanup the allocations | |
| 21:46:32 | mriedem | https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-allocation-delete | |