Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-19
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
21:46:44 mnaser thanks for making life easy and writing those clie stuf
21:46:46 mriedem openstack resource provider allocation delete 13a09ff5-7124-4b3c-8229-a8691a2f43b4
21:46:57 mriedem if the instance is truly deleted
21:47:13 mriedem if it were moved and allocations were just messed up, doing ^ would be bad
21:47:42 mnaser ill double check they're all deleted
21:47:45 mriedem might be good to update that log message with the same info
21:47:55 mnaser tail -1000 /var/log/nova/nova-compute.log | grep 'has allocations against this compute host but is not found in the database.' | cut -d' ' -f13 | sort | uniq | xargs -n1 echo nova show
21:47:56 mnaser magic
21:48:30 mriedem "If you continue to see this message and have confirmed the instance is truly gone from the database, you can run 'openstack resource provider allocation delete <uuid>' to remove the allocation from the placement service."

Earlier   Later