Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-27
16:42:16 jaypipes mriedem: top patch (the claims one) has no failures.
16:42:42 mriedem yeah i've seen that weird rpc timeout one
16:49:00 openstackgerrit Matt Riedemann proposed openstack/nova master: doc: add FAQ entry for cells v1 config options https://review.openstack.org/487938
16:49:10 mriedem s-dean: ^
16:50:29 dansmith mriedem: I was thinking of expanding the warning on my new cells doc to explain not only it not applying to cellsv1, but also that anything about the nova-cells service, the [cells] section of the config, etc
16:50:45 dansmith since "cellsv1" is not a neat box everyone understands
16:52:06 mriedem yeah there is a warning here https://docs.openstack.org/ocata/config-reference/compute/cells.html
16:52:13 mriedem but doesn't mention the config options,
16:52:18 mriedem or nova-cells servie
16:52:21 mriedem which are part of the confusion
16:53:08 dansmith aye
16:53:46 sdague vdrok: ok https://review.openstack.org/#/c/487809/ is +A
16:54:27 sdague the ironic patch is looking pretty good
16:54:40 vdrok sdague: thanks!
16:54:43 sdague vdrok: you should start lining up +2s on that one
16:55:06 vdrok will do as soon as I have a pass :)
16:58:34 cfriesen_ mriedem: thanks for fixing those nits on the unshelve. I'm a couple hours behind you. :)
16:59:18 mriedem np, thanks for fixing
17:02:19 openstackgerrit Merged openstack/nova master: Add 'updated_at' field to InstancePayload in notifications https://review.openstack.org/475276
17:03:31 mriedem this fixes another one of our random functional test failures https://review.openstack.org/#/c/487772/
17:07:14 sdague mriedem nice
17:11:22 openstackgerrit Merged openstack/python-novaclient master: Add 'Forced down' column in serivce-list https://review.openstack.org/487263
17:17:28 openstackgerrit Merged openstack/python-novaclient master: Be clear about hypevisors.search used in a few CLIs https://review.openstack.org/487513
17:19:27 openstackgerrit Ed Leafe proposed openstack/nova master: Handle hash ring rebalancing in ironic flavor migration https://review.openstack.org/487954
17:19:33 openstackgerrit Doug Hellmann proposed openstack/nova master: WIP: add a redirect for the old cells landing page https://review.openstack.org/487932
17:19:34 openstackgerrit Matt Riedemann proposed openstack/nova master: hardware offload support for openvswitch https://review.openstack.org/398265
17:19:55 openstackgerrit Ed Leafe proposed openstack/nova master: Handle ironicclient failures in Ironic driver https://review.openstack.org/487925
17:20:33 mriedem jaypipes: +2 on moshe's hw offload thingamajig https://review.openstack.org/#/c/398265/
17:33:05 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test resize with placement api https://review.openstack.org/487958
17:33:28 gibi mriedem: here is my first stab at the resize tests with placement api ^^
17:34:10 gibi mriedem: it is pretty unstable at the current form and ther are some asserts commented out that are failing right now
17:34:20 mriedem gibi: cool, thanks
17:34:30 openstackgerrit Ed Leafe proposed openstack/nova master: Handle hash ring rebalancing in ironic flavor migration https://review.openstack.org/487954
17:34:44 gibi mriedem: can be a real bug or can be some race in the test
17:34:52 edleafe dansmith: ^^ updated to address your comments
17:34:58 gibi mriedem: I have to leave for today but check back tomorrow morning
17:35:34 dansmith edleafe: cool, lets get ironic eyes on it and then I think we're good
17:35:46 openstackgerrit Sean Dague proposed openstack/nova master: always show urls in list_cells https://review.openstack.org/487860
17:35:55 cdent gibi++
17:36:17 openstackgerrit Merged openstack/python-novaclient master: Help text for "--matching" is not clear. https://review.openstack.org/487708
17:36:55 sdague gibi: thanks for solving that test race
17:37:40 sdague mriedem: the sqla_url functions don't really provide the same reassembly that you get from urlparse
17:37:47 sdague which is why it was not used in https://review.openstack.org/#/c/487860/
17:49:10 mriedem "Alex Xu 2:33 AM oh..damn it."
17:49:18 mriedem someone is going to have to have a talk with alex_xu
17:52:07 mriedem bauzas: so your -1 on this is just stale at this point https://review.openstack.org/#/c/483566/
17:52:38 mriedem bauzas: can you remove the -1 and re-review? if you're ok, but don't want to +W until i go through it too that's fine
17:53:22 jaypipes mriedem: yeah, I'm on it.
17:53:57 mriedem you know, this low sodium vegetarian lentil soup that laura buys could really use some pork
17:54:11 jaypipes omg lmao
17:54:58 openstackgerrit Doug Hellmann proposed openstack/nova master: WIP: add a redirect for the old cells landing page https://review.openstack.org/487932
17:55:30 bauzas mriedem: sure , just at dinner atm so will do in the next hour
17:58:00 smcginnis mriedem: Some of the vegetarian pork like they tried to give dims?
17:58:17 dims LOL
17:58:36 dansmith just don't give him quinoa whatever you do
17:58:42 dims amen!
17:58:48 dansmith pork = funny joke
17:58:53 dansmith quinoa = unfunny disaster
17:58:57 sdague right, all the quinoa goes to dansmith
17:59:09 mriedem like a gremlin eating after midnight
17:59:13 dansmith sdague: joke's on you homeboy, I like quinoa
18:00:52 sdague I am confused by dansmith liking something that's not a hamburger
18:01:19 dansmith http://www.bonappetit.com/recipe/stellar-quinoa-burger
18:02:14 sdague dansmith: that looks pretty good, will need to add that to my recipe stash
18:02:54 dansmith first hit on google.. looks gross though because it has sweet potato in it
18:03:01 sdague heh
18:03:09 sdague oh, so you don't actually eat that :)
18:03:27 dansmith sweet potato is gross
18:03:41 dansmith regular potato == perfect
18:05:54 vdrok thanks for the help with multicell, all jobs green :)
18:08:15 dansmith woot
18:09:01 mriedem final novaclient release is up https://review.openstack.org/487966
18:10:59 mriedem onto the claims in the scheduler patch,
18:11:08 mriedem http://logs.openstack.org/66/483566/20/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial-nv/374e3c3/logs/screen-n-sch.txt.gz#_Jul_27_14_36_56_138843
18:11:08 mriedem i see the move accounting happening on that change in the multinode patch
18:11:22 mriedem New allocation request containing both source and destination hosts in move operation: {'allocations': [{'resource_provider': {'uuid': u'209a32d3-f240-4bcc-9d9d-8ae371b97d42'}, 'resources': {u'VCPU': 1, u'MEMORY_MB': 64}}, {u'resource_provider': {u'uuid': u'fdba3ea4-883a-4dc4-a2d6-49d723f9559e'}, u'resources': {u'VCPU': 1, u'MEMORY_MB': 64}}]}
18:11:56 mriedem this one is a resize New allocation request containing both source and destination hosts in move operation: {'allocations': [{'resource_provider': {'uuid': u'209a32d3-f240-4bcc-9d9d-8ae371b97d42'}, 'resources': {u'VCPU': 1, u'MEMORY_MB': 64}}, {u'resource_provider': {u'uuid': u'fdba3ea4-883a-4dc4-a2d6-49d723f9559e'}, u'resources': {u'VCPU': 1, u'MEMORY_MB': 64}}]}
18:11:58 mriedem oops
18:12:02 mriedem http://logs.openstack.org/66/483566/20/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial-nv/374e3c3/logs/screen-n-sch.txt.gz#_Jul_27_14_48_57_853377
18:12:10 mriedem New allocation request containing both source and destination hosts in move operation: {'allocations': [{'resource_provider': {'uuid': u'fdba3ea4-883a-4dc4-a2d6-49d723f9559e'}, 'resources': {u'VCPU': 1, u'MEMORY_MB': 64}}, {u'resource_provider': {u'uuid': u'209a32d3-f240-4bcc-9d9d-8ae371b97d42'}, u'resources': {u'VCPU': 1, u'MEMORY_MB': 128}}]}
18:12:16 mriedem memory bumps up
18:12:23 mriedem so that all seems cool
18:13:11 mriedem i don't expect anything to be busted with soft delete, since with soft delete we do'nt delete the instance until it's reclaimed
18:13:17 mriedem so the allocations shouldn't change until that happens
18:13:19 cdent gibi’s test suggeests that cleanups are not happening
18:13:35 cdent i’m experimenting with them now to see if I can see anything wrong/weird
18:15:20 mriedem http://logs.openstack.org/66/483566/20/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial-nv/374e3c3/logs/screen-n-cpu.txt.gz#_Jul_27_14_35_26_077233
18:15:20 mriedem i do see the source node cleaning up allocations during live migration
18:15:49 mriedem jaypipes: dansmith: do we need to worry about this? https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1068
18:16:03 mriedem wiping out all of the allocations for an instance because it's no longer on the source node
18:16:33 dansmith hmm, I thought not because of the claim at the end on the destination, but let me look
18:17:16 dansmith mriedem: yeah, we should check the allocations before we delete to see if we own any of them I think, or delete the ones that pertain to us
18:17:19 dansmith instead of just nuking them all
18:17:23 dansmith good call
18:20:16 mriedem it also seems that https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1068 could simply updated to be:
18:20:25 mriedem if not instance.host or instance.host != CONF.host:
18:20:28 mriedem continue
18:21:24 jaypipes err, not sure about that...
18:21:39 mriedem otherwise yeah, pass the cn uuid to https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L999 and we could make sure to only remove allocations for the source node + instance
18:22:07 mriedem note that if we have to change anything here in the compute, it wouldn't be there for ocata computes

Earlier   Later