| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-25 | |||
| 12:33:58 | bhagyashris | kashyap: I am not getting why the n-sch is not returning the allocation_candicates as my change is at nova compute side | |
| 12:34:29 | bhagyashris | kashyap: and on master evrthing is fine only on patch patches it's failing | |
| 12:35:08 | bhagyashris | kashyap: any idea/ | |
| 12:35:10 | bhagyashris | ? | |
| 12:35:58 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Escalate UUID validation warning to error in test https://review.openstack.org/540386 | |
| 12:35:59 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fix invalid UUIDs in test https://review.openstack.org/564190 | |
| 12:37:25 | kashyap | bhagyashris: Not without delving too deep. Please go through the traces systematically to find the root cause. I'm a bit buried with a couple of urgent things | |
| 12:37:54 | bhagyashris | kashyap: ok np thank you :) | |
| 12:38:34 | bhagyashris | jaypipes: Hi, | |
| 12:47:35 | openstackgerrit | Martin Midolesov proposed openstack/nova master: Validating video ram against the max video ram allowed https://review.openstack.org/564193 | |
| 13:14:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.openstack.org/512552 | |
| 13:14:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.openstack.org/512623 | |
| 13:14:28 | openstack | bug 1724172 in OpenStack Compute (nova) "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Undecided,In progress] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 13:14:28 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1724172 in the functional test env https://review.openstack.org/512553 | |
| 13:29:29 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: mdevs returning parent and vendor PCI info https://review.openstack.org/562304 | |
| 13:29:30 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: Configure multiple vGPU types https://review.openstack.org/564214 | |
| 13:29:31 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Get inventories per pGPU https://review.openstack.org/564215 | |
| 13:38:05 | mnaser | super unrelated but i feel like this might be something devs have had to deal with | |
| 13:38:21 | mnaser | is there some sort of 'tcpdump for rabbitmq' toolset available anywhere (or part of rabbitmq) | |
| 13:43:44 | stephenfin | bauzas: OK, looked at that and it does seem like it's targeted. See line 35 from the paste paste.openstack.org/show/719901/ | |
| 13:43:50 | stephenfin | and compare to https://github.com/stephenfin/nova/blob/bp/numa-aware-vswitches/nova/conductor/manager.py#L1172-L1175 | |
| 13:46:41 | stephenfin | But wait - the *cell1* table wasn't migrated. Well that's annoying. I would have expected 'nova-manage sync' to do all cell tables unless I explicitly said otherwise http://paste.openstack.org/show/719912/ | |
| 13:46:56 | openstackgerrit | Hamdy Khader proposed openstack/nova master: Adding NVMEoF for libvirt driver https://review.openstack.org/482640 | |
| 13:47:08 | stephenfin | dansmith: Any reason 'nova-manage db sync' doesn't sync all cell DBs at once? | |
| 13:47:35 | dansmith | stephenfin: yeah, because that would potentially lock down all of them at once (or nearly) and maybe you're upgrading one cell before another | |
| 13:48:12 | dansmith | db sync is/can be run at runtime before upgrading code and has a significant impact on the performance of the db while running | |
| 13:48:32 | dansmith | we have or had a --all-cells flag proposed for it | |
| 13:48:47 | stephenfin | Right, and the non upgraded cell would be using old code so you wouldn't see backtraces like I did above | |
| 13:49:14 | stephenfin | (my next question was going to be "wouldn't the older schema be invalid for newer code") | |
| 13:53:53 | mriedem | stephenfin: if you want to brush this off https://review.openstack.org/#/c/420973/ | |
| 13:55:07 | stephenfin | Um, so how do I upgrade the schema for the cell1 DB? It's an all-in-one deployment so cell0 and cell1 DB are on the same node | |
| 13:55:44 | stephenfin | The docs say " If --local_cell is specified, then only the main database in the current cell is upgraded." but my main database for an all in one is...both of them? | |
| 13:55:47 | stephenfin | mriedem: I can do that | |
| 13:55:54 | dansmith | use the config that the cell1 services use | |
| 13:58:09 | stephenfin | So change '[database] connection' in nova.conf to the cell1 DB? | |
| 13:58:10 | stephenfin | Wait | |
| 13:58:24 | stephenfin | There's a '--config-file'. That should show up when I do 'nova-manage db sync --help' | |
| 13:58:39 | stephenfin | #usability | |
| 13:59:27 | mriedem | stephenfin: is this devstack? | |
| 13:59:33 | stephenfin | mriedem: It is | |
| 13:59:35 | mriedem | if so, by default, even though it's single node, it's not all in one | |
| 13:59:41 | mriedem | see under /etc/nova | |
| 13:59:45 | mriedem | there should be multiple config files | |
| 13:59:58 | mriedem | nova_cell1.conf is the cell1 conf | |
| 14:00:00 | stephenfin | Sorry, I'm using the wrong terminology so. I meant everything is deployed onto one machine | |
| 14:00:02 | mriedem | nova-cpu.conf is for nova-compute | |
| 14:00:16 | mriedem | nova.conf is used for the controller services and n-super-cond | |
| 14:00:24 | stephenfin | Yup, just ran this and things are looking good -> $ nova-manage --config-file /etc/nova/nova_cell1.conf db sync | |
| 14:06:11 | bhagyashris | efried: Hi, I am trying to write the functional test for https://review.openstack.org/#/c/560444/ https://review.openstack.org/#/c/560459/ but have some question about that: As of on current master there no as such functional test that is creating the RP providers and used to boot the instance or to build the instance | |
| 14:06:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459 | |
| 14:10:31 | efried | bhagyashris: You may have to piece it together from other bits. | |
| 14:11:58 | efried | bhagyashris: Did you figure out the error from yesterday? | |
| 14:13:04 | bhagyashris | efried: or I can say there is no frame work in fictional test that creates the resource provider and that providers will be used to build the instances | |
| 14:14:45 | bhagyashris | efried: and one more doubt is how that created provider will be pick by sch at the time of build instance | |
| 14:15:44 | bhagyashris | efried: in current functional test cases the create server are created on the single host | |
| 14:17:09 | efried | bhagyashris: You're trying to make a functional test that does exactly what you did in your live environment. That is, you create the provider, mark it as a sharing provider, give it DISK_GB inventory, and associate it via aggregate with the compute node provider. Then the purpose of the patch we're testing is that we fixed it exactly so the scheduler knows to pick that sharing provider for the DISK_GB. | |
| 14:18:36 | fishbone__ | hello all; I am receiving a strange error when launching windows instances: ERROR cloudbaseinit.init pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 'Session', 'Access is denied. ', None, 0, -2147024891), None) | |
| 14:19:16 | fishbone__ | I believe this is causing an issue that disallows the key to regenerate the password appropriately when rebuilding instances | |
| 14:19:35 | fishbone__ | Is that simply an issue with the cloudbase-init; perhaps a reinstall would fix that? | |
| 14:20:40 | bhagyashris | efried: yeah. but through creating provider and inventory and then association of CN and share provider etc will need in functional test and then while creating the instance how come that request will know that the CN and shared resource provider should pick that providers | |
| 14:21:20 | bhagyashris | becuse as on functional test the only the single provider is used | |
| 14:22:26 | efried | bhagyashris: What do you mean? If the functional test setup is using the "live" placement fixture, it should be behaving just like a real placement database. So if you create new providers in there, they should stick, and they should get picked up by your deploy (in the test). | |
| 14:31:33 | bhagyashris | efried: which fixture are you talking there are two fixture one is nova/nova/tests/fixtures.PlacementFixture and other one is nova/tests/functional/api/openstack/placement/fixtures.SharedStorageFixture | |
| 14:32:52 | bhagyashris | efried: so it's little bit confusing. the second fixture is used in gabbit test | |
| 14:34:29 | kashyap | mriedem: When you can, mind having a gander at this, as you have prior context: https://review.openstack.org/#/c/563926/ (Lift the restriction of choices for `cpu_model_extra_flags`) | |
| 14:35:33 | lyarwood | bauzas: you were working on a hard reboot bug in master around _get_all_assigned_mediated_devices right? | |
| 14:36:35 | efried | bhagyashris: The SharedStorageFixture is a thing that's setting up macros (and maybe some providers) for use in the gabbits. I'm talking about the first one. Hold on, let me find an example of how it gets used... | |
| 14:37:05 | bhagyashris | ok | |
| 14:38:29 | efried | bhagyashris: nova/tests/functional/test_servers.py | |
| 14:39:20 | efried | bhagyashris: That's a good example, the PlacementFixture is instantiated and then saved off to an instance variable, and then it gets used to talk to the placement API in the test cases. | |
| 14:39:21 | bauzas | lyarwood: yup | |
| 14:39:47 | efried | Hey, anyone got their thumb on a nice reference doc for bfv? | |
| 14:41:37 | bauzas | efried: yup, master doc | |
| 14:41:51 | bauzas | efried: BDMs, you mean ? | |
| 14:42:19 | bauzas | efried: https://docs.openstack.org/nova/latest/user/block-device-mapping.html | |
| 14:43:02 | efried | bauzas: boot from volume specifically | |
| 14:44:06 | jaypipes | efried: the "live" PlacementFixture thing is broken by design, IMHO. Try removing @safe_connect and running a functional test case with the PlacementFixture and see what happens. It's basically hiding a bunch of brokenness with @safe_connect | |
| 14:45:19 | efried | jaypipes: But it ought to work to set up providers and stuff, won't it? | |
| 14:46:01 | jaypipes | efried: and by "brokenness with @safe_connect" I'm referring to any place that calls a method of the reportclient that returns something (because @safe_connect will mask over issues and return a None, meaning anything that calls or depends on the return value from a method in reportclient will be broken) | |
| 14:46:55 | efried | jaypipes: Ah, but only if you call a method that's decorated by @safe_connect. So doing primitive get/put/post/delete calls will be fine. | |
| 14:47:38 | jaypipes | efried: are you referring to the nova.tests.fixtures.PlacementFixture, or are you referring to this? https://github.com/openstack/nova/blob/master/nova/tests/functional/api/openstack/placement/fixtures.py#L34 | |
| 14:47:52 | efried | bhagyashris: So note the above, and do your calls in the same fashion that test_servers.py does them. See the helper methods around L1440-1474 | |
| 14:48:08 | efried | jaypipes: The former. | |
| 14:48:08 | jaypipes | efried: because the latter sets up the data fixtures with direct calls to the database, not by the placement API calls. | |
| 14:49:07 | jaypipes | efried: yeah. the former is what I consider to be broken. but whatevs. | |
| 14:51:14 | bhagyashris | efried: yeah checking the same... | |
| 14:58:00 | mriedem | kashyap: that would be my pleasure | |
| 14:58:12 | stephenfin | dansmith: Any hints about why this could be happening? http://paste.openstack.org/show/719928/ | |
| 14:58:22 | kashyap | s/snids/snide/ | |
| 14:58:35 | stephenfin | It seems to be caused by this line in o.vo https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L65-L66 | |
| 14:58:47 | dansmith | stephenfin: well, it means you don't have a context on that object | |
| 14:58:58 | dansmith | and you're trying to lazy-load .network_requests | |
| 14:59:15 | stephenfin | dansmith: But it doesn't happen for the numa_topology object which is defined the exact same way | |
| 14:59:55 | dansmith | stephenfin: I dunno what to say.. that ^ is the exact reason | |
| 15:00:15 | dansmith | either give it a context if it needs to be able to lazy-load, or make sure .network_requests is set to something | |
| 15:01:18 | stephenfin | Oh, that latter would do it. numa_topology is defined to something https://github.com/openstack/nova/blob/master/nova/tests/unit/compute/test_resource_tracker.py#L1853 | |
| 15:01:29 | openstackgerrit | Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371 | |
| 15:04:19 | stephenfin | dansmith: Yup, 'instance.network_requests = None' did the job. Thanks :) | |
| 15:04:26 | dansmith | stephenfin: cool | |
| 15:06:41 | kashyap | When someone gets a moment, is there a better / effficient way to test a config in Gate than this DevStack patch: http://paste.openstack.org/show/719929/ | |