| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-27 | |||
| 13:56:52 | dansmith | efried: if you hotplug some memory into your compute node, then nova-compute would automatically report that on the next periodic | |
| 13:57:19 | dansmith | efried: what you are talking about is updating the reserved value, which is static, operator-configured or operator-scripted | |
| 13:57:36 | mriedem | bauzas: provided your thoughts where? don't see anything in the bug or the linked pike change | |
| 13:57:39 | dansmith | efried: the HUP is so we notice the change to the config file.. certainly you don't want us to be live reloading the config file whenever we feel like it | |
| 13:57:54 | bauzas | mriedem: oh snap, duplicate bug | |
| 13:58:05 | bauzas | mriedem: https://bugs.launchpad.net/nova/+bug/1719859 | |
| 13:58:06 | openstack | Launchpad bug 1719859 in OpenStack Compute (nova) "Resize failure due to instance group being None in request spec" [Undecided,New] | |
| 13:58:30 | efried | dansmith Right, extending SAN was a bad example. | |
| 13:58:44 | bauzas | mriedem: mmm, nevermind, different issue, it seems | |
| 13:59:34 | efried | Not being super well-versed on how OVS comes into play for libvirt, can we apply the same principle to networking resources? | |
| 13:59:42 | mriedem | bauzas: ok, mel's is pretty straight forward | |
| 13:59:49 | mriedem | we used to set group_members in the filter_properties, | |
| 13:59:56 | mriedem | your change in pike stopped using filter_properties, | |
| 13:59:58 | efried | I.e. similar UX statement: "Do OVS thingy, edit conf file, HUP n-cpu" not as friendly as "Do OVS thingy" | |
| 14:00:02 | mriedem | but forgot to include the group_members stuff | |
| 14:00:12 | mriedem | she already said that the 1 line change fixes the issue | |
| 14:00:20 | mriedem | i just asked that a functional regression test get created | |
| 14:00:24 | bauzas | mriedem: okay, I'll wait for melwitt's patch | |
| 14:00:29 | dansmith | efried: no, nova-compute isn't reporting any network resources | |
| 14:00:53 | bauzas | mriedem: thanks for the catch | |
| 14:01:00 | mriedem | bauzas: which reminds me, did you cleanup that num_instances one? | |
| 14:01:06 | bauzas | mriedem: I got some late pings yesterday | |
| 14:01:08 | mriedem | melwitt found the problem, i just helped debug | |
| 14:01:22 | mriedem | https://review.openstack.org/#/c/506093/ | |
| 14:01:33 | dansmith | efried: I think the block you're stumbling over is that nova does not count things it does not count. Therefore, it does not dynamically update inventory for things it does not count. If you want to override the inventory for a thing it _does_ count to account for things it does not count, then you put that in config an HUP it to notice. | |
| 14:01:42 | bauzas | mriedem: yeah, just needs rebase | |
| 14:01:46 | mriedem | i need to start making an etherpad of bug fixes we need in pike... | |
| 14:02:07 | bauzas | mriedem: I also have a couple of bugfixes that are on hold in my queue | |
| 14:02:17 | bauzas | like the fact we don't destroy the Spec objects | |
| 14:02:42 | bauzas | mriedem: an etherpad seems a good idea to me | |
| 14:02:54 | bauzas | that would also help me focusing on rebasing such bugs | |
| 14:03:10 | mriedem | https://etherpad.openstack.org/p/nova-pike-bug-fix-backports | |
| 14:04:01 | bauzas | ack | |
| 14:04:25 | tssurya | dansmith, mriedem, sdague : so basically I have a simple set up using devstack with one cell, then I added a new 'cell2' that has some unmapped instances in its DB. However when I run the map_instances command specifying the cell uuid, it does not work since like sdague said earlier, the db url is being taken from nova.conf (which is that of cell0) while the db url for the new cell is inside the cell_mappings table of nova_api db. So I | |
| 14:05:06 | dansmith | tssurya: create a small config with just the db url you need | |
| 14:05:19 | efried | dansmith Thanks, that makes sense. | |
| 14:06:56 | tssurya | dansmith : okay! so that means the current working is as expected ? | |
| 14:07:31 | dansmith | tssurya: it's been a while since I looked at that command, but I would guess so | |
| 14:07:48 | mriedem | tssurya: nova.conf in default devstack points at cell0 on purpose | |
| 14:08:00 | mriedem | tssurya: nova-manage uses nova.conf if no other --config-file is specified | |
| 14:08:02 | mriedem | on the command line | |
| 14:08:31 | mriedem | so if you want to do things to cell1, you would do something like: nova-manage --config-file /etc/nova/nova_cell1.conf db archive_deleted_instances --verbose --until-complete | |
| 14:08:37 | mriedem | for archiving deleted instances in cell1 | |
| 14:08:52 | stephenfin | efried: You didn't start work converting this to a seqdiag, did you? https://photos.google.com/share/AF1QipNpWVQKU8GK4_9wxVbiRJUqJnMzqPcBh6DvjVyBPIjjmi6ZU8r9TleQNo6pV1t9SA?key=NUl3OUFGYkRFTE8tMHhSX0lfc0Y1eEdoeHo4SUhn | |
| 14:08:55 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP(5): PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 14:09:01 | stephenfin | I think mriedem asked for it? | |
| 14:09:04 | tssurya | mriedem, dansmith : okay thanks that makes sense | |
| 14:09:13 | dansmith | tssurya: yeah look at the docstring on that method, it says it assumes the config points at the right database | |
| 14:09:30 | mriedem | tssurya: related https://bugs.launchpad.net/nova/+bug/1719487 | |
| 14:09:32 | openstack | Launchpad bug 1719487 in OpenStack Compute (nova) "nova-manage db archive_deleted_rows is not multi-cell aware" [Wishlist,Triaged] - Assigned to Zhenyu Zheng (zhengzhenyu) | |
| 14:09:39 | dansmith | tssurya: you could make it smarter :) | |
| 14:09:40 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif stable/pike: Updated from global requirements https://review.openstack.org/493146 | |
| 14:09:43 | mriedem | stephenfin: that's already done | |
| 14:09:59 | mriedem | stephenfin: https://docs.openstack.org/nova/latest/reference/live-migration.html | |
| 14:10:01 | efried | stephenfin Yes, merged. | |
| 14:10:03 | mriedem | there is one thing missing | |
| 14:10:07 | mriedem | i noticed yesterday | |
| 14:10:31 | mriedem | on the failure path, it doesn't have a box saying that the source node is running the _rollback_live_migration method | |
| 14:10:42 | mriedem | which does some stuff on the source node, and calls the dest node to cleanup | |
| 14:10:49 | tssurya | dansmith , mriedem : ok, will have a look at it :) | |
| 14:11:17 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient stable/pike: Updated from global requirements https://review.openstack.org/493187 | |
| 14:11:26 | efried | mriedem That would be like a box to the left of that final 'call' arrow at the bottom? | |
| 14:11:54 | mriedem | efried: i think more like how the post_live_migration box is in the success path on the source node | |
| 14:14:40 | efried | sdague cdent Care to render an opinion/ruling on jichenjc's concerns here: https://review.openstack.org/#/c/488137/21/nova/conf/utils.py@85 ? | |
| 14:17:01 | cdent | efried: remind me when I’m back in about 20 mins | |
| 14:17:08 | efried | ack, thx | |
| 14:17:55 | openstackgerrit | Eric Fried proposed openstack/nova master: _rollback_live_migration in live-migration seqdiag https://review.openstack.org/507871 | |
| 14:18:23 | efried | mriedem ^ | |
| 14:19:26 | mriedem | thanks | |
| 14:19:56 | mriedem | claudiub|3: hyperv ci seems to have gone crazy | |
| 14:19:57 | mriedem | http://cloudbase-ci.com//nova/507871/1/console.log.gz | |
| 14:20:08 | mriedem | not sure if that's a zuulv3 side effect or what | |
| 14:22:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: xenapi: pass migrate_data to recover_method if live migrate fails https://review.openstack.org/507874 | |
| 14:23:20 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif stable/pike: Updated from global requirements https://review.openstack.org/493146 | |
| 14:24:54 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient stable/pike: Updated from global requirements https://review.openstack.org/493187 | |
| 14:27:50 | mriedem | gibi: appears that test_live_migrate_delete has introduced a race http://logs.openstack.org/87/507687/2/check/gate-nova-tox-functional-ubuntu-xenial/90cc144/testr_results.html.gz | |
| 14:28:13 | mriedem | i was noticing some stuff like this yesterday when writing another test, | |
| 14:28:27 | mriedem | i noticed that we set migration and instance state before we're actually done cleaning up live migration things, | |
| 14:28:34 | mriedem | so tests that rely on asserting the cleanups can get racy | |
| 14:30:59 | gibi | mriedem: I have to check if we can wait for notification or instance action to avoid the race | |
| 14:31:37 | gibi | but I guess we need a bug so I can go and file it if you haven't already filed it | |
| 14:32:36 | mriedem | gibi: https://bugs.launchpad.net/nova/+bug/1719915 | |
| 14:32:37 | openstack | Launchpad bug 1719915 in OpenStack Compute (nova) "test_live_migrate_delete race fail when checking allocations: MismatchError: 2 != 1" [Medium,Confirmed] | |
| 14:34:30 | gibi | mriedem: thanks, I go and dig for a solution | |
| 14:36:22 | gibi | mriedem: btw, I will be mostly unavailable tomorrow and on Friday. Could you do the reporting about the notification subteam meeting on the weekly nova meeting? | |
| 14:36:33 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif stable/pike: Updated from global requirements https://review.openstack.org/493146 | |
| 14:37:00 | mriedem | gibi: sure | |
| 14:37:03 | gibi | mriedem: thanks a lot | |
| 14:38:06 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient stable/pike: Updated from global requirements https://review.openstack.org/493187 | |
| 14:38:06 | johnthetubaguy | mriedem: I was looking at the requesting traits in flavors, did we ever talk about requesting the absence of a trait (like request no CPU_FLAG_X available) | |
| 14:39:11 | efried | johnthetubaguy That's a fun thought. Is there a real use case for it? | |
| 14:39:35 | johnthetubaguy | efried: disable the VT CPU flag? | |
| 14:39:54 | johnthetubaguy | or disable hyperthreading | |
| 14:39:56 | dansmith | johnthetubaguy: not that I'm aware of, just required and preferred | |
| 14:40:33 | efried | johnthetubaguy I have been chastised already to make the distinction between "Ask for a resource that *can* do this thing" and "Ask for a resource and then switch this thing on". | |
| 14:41:22 | johnthetubaguy | I am happy to ignore all that for now | |
| 14:41:29 | efried | johnthetubaguy (or off). The latter thing definitely needs to be supported - just not via the placement/traits paths, I am led to understand. | |
| 14:41:29 | johnthetubaguy | need the basic thing first | |
| 14:42:16 | efried | I can't remember whether it was a review or IRC where jaypipes and I had that talk. Looking... | |
| 14:43:09 | efried | johnthetubaguy Whee: https://review.openstack.org/#/c/497713/4/specs/queens/approved/add-trait-support-in-allocation-candidates.rst@72 | |