Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-15
15:15:20 stephenfin mriedem: Yes please. It's a huge series
15:15:37 stephenfin I've got one follow-up at the end already
15:15:55 sean-k-mooney mriedem: by the way similar to https://bugs.launchpad.net/nova/+bug/1790204 but on the nova side we cant support inplace resize for numa instances due to how the numa toplogy filter or more acurally the nova.virt.hardware module is implemented
15:15:57 openstack Launchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged]
15:16:17 mriedem stephenfin: ok there are probably enough in here to give it its own fup patch but i'll approve
15:16:32 sean-k-mooney mriedem: so even if ^ is fix for numa instance it can still failt if the host is full
15:16:44 openstackgerrit François Palin proposed openstack/nova master: Include all network devices in nova diagnostics https://review.openstack.org/648123
15:19:06 sean-k-mooney i had breifly disccused supporing inplacee resize for numa instance downstream as we had a customer request realted to it but wanted to wait until the ptg to see how things panned out
15:20:12 mriedem sean-k-mooney: ok i haven't put any thought into numa for that bug, just the simple resource class cases
15:20:41 sean-k-mooney well its an issue with the resouce track side not placement.
15:21:07 sean-k-mooney if we do "fix" it want i wanted to ask is shoudl i be a bug or a blueprint
15:21:21 sean-k-mooney e.g. is it feature or an oversitght/bug
15:23:43 sean-k-mooney in the context of fixing https://bugs.launchpad.net/nova/+bug/1790204 you can ignore numa. im just wonderinf what i should be filing for the numa same host resize/rebuild case bug/spec/blueprint
15:23:44 openstack Launchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged]
15:34:44 mriedem stephenfin: another reno fix needed for https://review.openstack.org/#/c/651294/ in a fup somewhere,
15:34:53 adrianc mriedem: Hi, was hoping to get your inputs on https://review.openstack.org/#/c/649345, it seems that _heal_instance_info_cache updates port binding:host_id to point to the compute host. while this is OK for most cases, its problematic for baremetal with Smart NIC https://storyboard.openstack.org/#!/story/2003346
15:34:55 stephenfin ack
15:34:56 mriedem and probably want melwitt to answer the question about what map_cell_and_hosts is used for
15:36:24 sean-k-mooney adrianc: that periodic task was not intended to run for ironic nodes. at least how its written it was apparently assuming it was running no a vm host
15:36:46 mriedem adrianc: that's a regression due to https://review.openstack.org/#/c/603844/ right?
15:36:56 mriedem before ^ that periodic wouldn't mess with port bindings
15:37:27 adrianc sean-k-mooney: yea i know, hence i think it should not run on BM :)
15:38:21 adrianc mriedem: yes that is correct
15:38:56 openstackgerrit Boxiang Zhu proposed openstack/nova-specs master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645458
15:39:06 sean-k-mooney well for ironic nodes it could update teh port binding for the ironic node instead of skiping but ya we didnt think about that usesece with the previous patch
15:40:38 adrianc is the BM use-case relevant for this type of healing ?
15:41:05 mriedem adrianc: comments inline
15:41:44 sean-k-mooney adrianc: im not sure
15:41:47 mriedem adrianc: before that change the periodic task was essentially read-only as far as the ports are concerned, nova would just refresh it's internal cache
15:41:48 adrianc thanks mriedem, appreciated
15:41:55 mriedem what you need to avoid in the BM case is the update to the port
15:41:56 sean-k-mooney i know we cna do boot form volume with ironic now
15:42:06 sean-k-mooney do we supprot resize/cold migrate
15:42:46 sean-k-mooney in principal if we did then yes we coudl have the same failure cases
15:43:36 mriedem no we don't
15:45:42 sean-k-mooney ok there is no reason that should not be supported for boot form volume ironic instance right?
15:46:09 sean-k-mooney i guess there is the quetion of ephemeral storage
15:46:36 mriedem there was a spec for supporting migration of ironic instances, you could read the details there
15:47:13 mriedem https://review.openstack.org/#/c/449155/
15:47:20 sean-k-mooney if it was a pure bfv ironic node with no local disk it should work. no im jsut trying to reson about if we would need to validate neutron port for ironic instance in the future
15:47:22 mriedem anyway, that doesn't really have anything to do with this change IMO
15:47:35 mriedem just avoid the port binding update if ironic to get back to the pre-regression behavior
15:47:57 sean-k-mooney ya i was leaving a comment to say somthign similar
15:48:15 sean-k-mooney just wondering if we will need to do something more involed in the future
15:48:40 sean-k-mooney but to fix the regress we jus tneed to not to the port binding update here https://review.openstack.org/#/c/649345/4/nova/compute/manager.py@73311
15:49:25 sean-k-mooney sorry here https://review.openstack.org/#/c/649345/4/nova/compute/manager.py@7311
15:49:31 sean-k-mooney extra 3
15:50:00 adrianc a noob's question here, but why would nova attempt to fix something that ironic did ? that is, ironic is the once who does the actual port binding today right ?
15:50:07 mriedem melwitt: you should review this part of the cells v2 removal series regarding console stuff https://review.openstack.org/#/c/651295/
15:50:30 mriedem adrianc: the regression was just an oversight
15:50:42 sean-k-mooney adrianc: it depends on the workflow. for spawn yes the virt dirver does the binding
15:51:00 sean-k-mooney adrianc: this was trying to fix move opertion for virt dirver that supprot them
15:51:30 sean-k-mooney for live migration the conductor does the binidng
15:52:11 adrianc understood, sean-k-mooeny, was just addressing what you said about, "just wondering if we will need to do something more involed in the future"
15:53:15 sean-k-mooney adrianc: ah well if we support move operation maybe we shoudl be honestly this is only here because we dont cleanup thing correctly on revert or failed migration in all cases
15:53:31 sean-k-mooney adrianc: if we did we would not need to heal the info cache
15:55:03 openstackgerrit Dan Smith proposed openstack/nova master: Add image type capability flags and trait conversions https://review.openstack.org/652710
15:55:46 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Server move operations with ports having resource request https://review.openstack.org/652608
16:07:27 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081
16:07:47 mriedem bauzas: could take a look at these backports? https://review.openstack.org/#/q/topic:bug/1821594+branch:stable/rocky
16:11:33 openstackgerrit Merged openstack/nova stable/ocata: Update port device_owner when unshelving https://review.openstack.org/626413
16:23:58 sean-k-mooney the periodic task is ment to heal all instance that need to be healed on each invocation right?
16:24:26 sean-k-mooney because if it is, that is not what it actully does
16:25:30 sean-k-mooney oh actully reading the doc string that was intentional?
16:31:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Enable test_volume_backed_live_migration in tempest https://review.openstack.org/528104
16:37:58 openstackgerrit Merged openstack/nova stable/queens: Ignore VolumeAttachmentNotFound exception in compute.manager https://review.openstack.org/637391
16:53:37 tssurya dansmith: about the power update event spec (https://review.openstack.org/#/c/636132/4/specs/train/approved/nova-support-instance-power-update.rst) whenever you have the time could you confirm the things discussed at L77 and L74 ? main concern being the notifications/action record requirement
16:53:43 tssurya thanks! :)
17:22:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove ComputeDriver.macs_for_instance method https://review.openstack.org/652737
17:30:27 pacharya a quick question, does creation of a batch instance delete API fall under https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-more-orchestration ?
17:31:45 _erlon_ Folks, Im trying to debug a failure on the instance creation on Nova, on a Pike release, but all I get is " Got no allocation candidates from the Placement API" and no explanation on what resource is lacking:
17:31:51 _erlon_ http://paste.openstack.org/show/749318/
17:32:02 _erlon_ look at the placement API logs also does not help
17:32:53 _erlon_ what is the procudure now?
17:32:53 _erlon_ I didn't had this problem before the placement API was introduced
18:07:24 mriedem there was debug logging added to the placement GET /allocation_candidates code but i'm not sure it made it back to pike
18:07:38 mriedem jaypipes: ^?
18:10:22 mriedem _erlon_: https://review.openstack.org/#/q/If9ddb8a6d2f03392f3cc11136c4a0b026212b95b
18:10:42 mriedem and https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:one-resource-per-query
18:10:48 mriedem that would take some work to get back to pike
18:11:12 mriedem _erlon_: how many computes do you have?
18:11:54 mriedem first thing to do would be to make sure there is a resource provider for each compute node
18:22:28 openstackgerrit Merged openstack/python-novaclient stable/rocky: Revert "Fix crashing console-log" https://review.openstack.org/650364
18:22:29 openstackgerrit Merged openstack/python-novaclient stable/rocky: Add test for console-log and docs for bug 1746534 https://review.openstack.org/652033
18:22:31 openstack bug 1746534 in python-novaclient "encoding error when doing console-log" [High,Fix released] https://launchpad.net/bugs/1746534 - Assigned to Thomas Goirand (thomas-goirand)
18:28:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove macs kwarg from allocate_for_instance https://review.openstack.org/652749
18:33:08 edleafe vim
18:33:12 edleafe doh!
18:34:26 sean-k-mooney edleafe: password:
18:34:38 sean-k-mooney :)
18:35:43 edleafe too many windows open - now *that* would make an easy-to-remember password
18:37:27 sean-k-mooney im kind of sad the cirros passward is nolonger "cubswin:)"
18:37:45 sean-k-mooney anyway time for dinner
18:37:47 sean-k-mooney o/
18:58:33 _erlon_ mriedem: only 1
18:58:40 _erlon_ its a devstack node
19:00:02 mriedem _erlon_: oh, well, make sure it's reporting into placement with the correct inventory
19:00:15 mriedem https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list
19:00:20 mriedem https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-inventory-list
19:00:34 _erlon_ mriedem: its a devstack node and should be working fine

Earlier   Later