Earlier  
Posted Nick Remark
#openstack-nova - 2017-12-13
17:12:39 melwitt it's just that the current topology is console proxies at the top. my series will make it so console proxies need to be per cell
17:12:41 melwitt yeah
17:12:43 mriedem the per-cell nova patch can't work if devstack is using global
17:12:57 mriedem so what happens if you changed devstack today to run consoleproxy per cell
17:13:00 mriedem w/o a depends-on
17:13:05 mriedem how does it blow up
17:13:12 melwitt right. the current console stuff *might* probably work if deployed per cell because the storage is global
17:13:19 melwitt well, I'm not sure actually
17:13:25 mriedem so you probably need a 2-step dance
17:13:44 melwitt yeah, let me try that without a depends-on and see what happens
17:14:12 mriedem if it's like one test in tempest that fails, we could maybe disable the test in tempest via config in devstack until we have the thing that makes it all work with the nova patch
17:14:34 melwitt I see. yeah, it is one test, the novnc test
17:15:00 stephenfin cfriesen__: This look like something you'd be interested in reviewing? https://review.openstack.org/#/c/527472/
17:15:32 melwitt mriedem: okay, let me try a run without depends-on in the devstack patch and see what blows up. thanks for the ideas
17:16:23 cfriesen__ stephenfin: yep, will take a look
17:20:04 mriedem melwitt: ok then you could disable that in devstack/lib/tempest using CONF.compute_feature_enabled.vnc_console=False in tempest.conf
17:20:28 mriedem melwitt: so maybe disable that with a TODO saying if you're running per-cell console proxy, it won't work until the nova patch which a later devstack patch depends on and removes that tempest conf
17:20:39 melwitt aha, cool
17:20:45 mriedem so devstack1->nova->devstack2
17:20:48 mriedem is the dep order i think
17:21:00 mriedem if that works, you owe me a cream sodda
17:21:01 mriedem *soda
17:21:17 melwitt heh, can do
17:48:22 openstackgerrit Stephen Finucane proposed openstack/nova master: Traits ops on ProviderTree https://review.openstack.org/521605
17:48:22 openstackgerrit Stephen Finucane proposed openstack/nova master: SchedulerReportClient._get_providers_in_aggregates https://review.openstack.org/521097
17:48:23 openstackgerrit Stephen Finucane proposed openstack/nova master: Track provider traits in report client https://review.openstack.org/521686
17:48:23 openstackgerrit Stephen Finucane proposed openstack/nova master: Move aggregates from report client to ProviderTree https://review.openstack.org/521685
17:48:24 openstackgerrit Stephen Finucane proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
17:48:24 openstackgerrit Stephen Finucane proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
17:48:25 openstackgerrit Stephen Finucane proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
17:48:25 openstackgerrit Stephen Finucane proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
17:48:26 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
17:48:26 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098
17:48:27 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
17:48:46 cfriesen__ stephenfin: the added comments are helpful
17:49:36 stephenfin cfriesen__: Good to hear. I got pretty bogged down in it myself yesterday and decided to add what I learned
17:51:21 stephenfin I also noticed a fair chunk of duplication and the likes going on, e.g. https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L148-L155 vs https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L242-L248
17:51:35 stephenfin Gonna tackle that once this in in, hopefully
17:53:54 yumapath hi all, am trying to launch a instance on devstack (queen's) and am getting the following error
17:54:04 yumapath Error: Failed to perform requested operation on instance "vm2", the instance has an error status: Please try again later [Error: No sql_connection parameter is established].
17:54:11 yumapath what could be the possible reason
17:54:25 yumapath googling did not yeild any useful results
17:54:34 yumapath can someone help
17:55:28 stephenfin yumapath: Looks like an oslo.db issue. You'd be better off asking about it on #openstack http://codesearch.openstack.org/?q=No%20sql_connection%20parameter%20is%20established&i=nope&files=&repos=
17:56:10 yumapath ok
17:56:14 yumapath thanks
18:03:04 mriedem actually that's probably a superconductor issue
18:03:06 stephenfin melwitt: This is odd. What's going on here? https://review.openstack.org/#/c/325381/16/nova/tests/unit/compute/test_compute_mgr.py@279
18:04:52 mriedem stephenfin: i sent yumapath here https://github.com/openstack-dev/devstack/blob/master/stackrc#L80
18:04:56 mriedem and here https://docs.openstack.org/nova/latest/user/cellsv2-layout.html
18:05:01 mriedem they are likely failing on a reschedule
18:06:08 stephenfin I just realized I'm not actually on that channel
18:06:28 mriedem i'm not either usually
18:06:42 mriedem unless someone comes here with a problem and we shoo them off and i think i have an answer
18:07:14 stephenfin Heh, fair. I figured it was a lack of a configuration option that oslo.db cared about
18:07:24 mriedem with devstack that's pretty hard to screw up
18:07:28 mriedem unless you messed with stuff
18:11:57 frickler mriedem: stephenfin: https://bugs.launchpad.net/nova/+bug/1733933
18:11:58 openstack Launchpad bug 1733933 in OpenStack Compute (nova) "nova-conductor is masking error when rescheduling" [Undecided,Confirmed]
18:12:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Add nova-status check for ironic flavor migration https://review.openstack.org/527541
18:12:19 mriedem dtantsur|afk: dansmith: edleafe: ^ now with tests and docsy things
18:14:19 mriedem frickler: replied in the bug
18:14:30 mriedem frickler: if you rely on reschedules, you need to modify devstack
18:17:14 frickler mriedem: I think that answers it only partially. even if the reschedule doesn't work, I want to see the error from n-cpu on the instance and not have it replaced by "No sql_connection parameter is established"
18:18:45 mriedem frickler: ok fair enough, i re-opened it
18:19:08 mriedem but now i'm off for my pre-holidays haircutting
18:58:50 openstackgerrit Ildiko Vancsa proposed openstack/nova master: WIP: libvirt: Allow multiple volume attachments https://review.openstack.org/267587
18:58:51 openstackgerrit Ildiko Vancsa proposed openstack/nova master: WIP: Allow multi-attach in compute api https://review.openstack.org/271047
19:11:40 openstackgerrit Ildiko Vancsa proposed openstack/nova master: WIP: libvirt: Allow multiple volume attachments https://review.openstack.org/267587
19:11:41 openstackgerrit Ildiko Vancsa proposed openstack/nova master: WIP: Allow multi-attach in compute api https://review.openstack.org/271047
19:27:39 openstackgerrit Merged openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/516707
19:27:46 openstackgerrit Merged openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
19:27:52 openstackgerrit Merged openstack/nova stable/ocata: fix nova accepting invalid availability zone name with ':' https://review.openstack.org/509659
19:41:16 mriedem TheJulia: would you happen to know if there is an ironic grenade job that runs with resource classes?
19:41:29 mriedem i'd like to run that against https://review.openstack.org/#/c/527541/
19:42:08 TheJulia I don't believe so... checking
19:43:07 mriedem hmm, doesn't look like the ironic grenade job runs the nova-status command anyway
19:43:14 mriedem compare http://logs.openstack.org/41/527541/1/check/legacy-grenade-dsvm-neutron-multinode/51ed76a/logs/grenade.sh.txt.gz#_2017-12-13_04_12_18_910
19:43:18 mriedem to http://logs.openstack.org/75/527075/1/check/ironic-grenade-dsvm-multinode-multitenant/2db59eb/logs/grenade.sh.txt.gz
19:43:36 mriedem i'll push an ironic patch to test things out
19:46:35 TheJulia mriedem: looks like we do set/use the resource class
19:46:58 TheJulia but we also set the mem/cpu/etc with a value of 0 for the flavor
19:47:43 mriedem yeah that's fine
19:47:56 mriedem this check would only fail if the node.resource_class isn't set i think
19:48:08 mriedem otherwise we'll migrate that node.resource_class into the instance.flavor.extra_specs
19:49:04 TheJulia we will likely want to publish a release note on ironic to stress that it MUST be set then
19:49:20 TheJulia Well, we've done that before, but now we really really mean it
19:49:51 mriedem you don't have to do that until nova drops the migration code
19:50:05 mriedem and we can't do that until we have at least this nova-status check to tell people if they are done with the migration
19:50:13 mriedem but yeah this is to try and get the ball rolling
19:51:12 mriedem hmm
19:51:20 mriedem why doesn't this ironic multinode grenade job upgrade nova?
19:51:21 mriedem http://logs.openstack.org/75/527075/1/check/ironic-grenade-dsvm-multinode-multitenant/2db59eb/logs/grenade.sh.summary.txt.gz
19:51:44 mriedem this other one does http://logs.openstack.org/75/527075/1/check/ironic-grenade-dsvm/41ce7b3/logs/grenade.sh.summary.txt.gz so i guess that's the one i care about
19:52:03 mriedem ok here we go http://logs.openstack.org/75/527075/1/check/ironic-grenade-dsvm/41ce7b3/logs/grenade.sh.txt.gz#_2017-12-11_22_49_15_166
19:52:05 mriedem cool
19:52:29 ildikov mriedem: hi
19:52:30 TheJulia oh, holdover from the old multinode scenario
19:52:47 ildikov mriedem: just wanted to give a heads up that I did some fix up on the libvirt patch for multi-attach
19:52:49 TheJulia one node should be getting upgraded if I remember correctly

Earlier   Later