Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-25
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/
15:13:57 kashyap So the above should work; the fine folks on #openstack-qa confirmed
15:14:44 openstackgerrit sahid proposed openstack/nova-specs master: fix blueprint related to the spec overhead-pin-set https://review.openstack.org/561916
15:15:23 openstackgerrit Simon Dodsley proposed openstack/nova master: Add enhanced KVM storage QoS quotas https://review.openstack.org/558530
15:24:02 dansmith tssurya: mriedem melwitt: do we need a cells meeting today?
15:25:59 mriedem i don't
15:26:07 melwitt I don't have anything for today
15:26:12 tssurya belmoreira : ^
15:27:13 belmoreira we are upgrading to cellsV2 today... tomorrow I will have some info about it
15:27:22 tssurya dansmith: yea its okay to skip today then
15:27:42 dansmith wow, that's .. quite a statement :)
15:35:25 openstackgerrit Chris Dent proposed openstack/nova master: Make accept-language tests work with webob 1.8.x https://review.openstack.org/564255
15:37:04 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: fix hard reboot issue with mdevs https://review.openstack.org/564257
15:40:23 cdent melwitt: ^^ is the short term fix to the webob issues. should keep us for a while, but I've noted in the commit and on the bug that there's a long term need too
15:41:40 melwitt cdent: okay, thanks
15:43:57 melwitt reminder for the cells subteam, review would be appreciated on this fix for anti/affinity with multiple cells https://review.openstack.org/540258
15:45:12 melwitt cdent: curiosity question, why does q=1.1 not work if q=0.5 works? https://review.openstack.org/#/c/564255/1/nova/tests/unit/api/openstack/test_wsgi.py@102
15:45:45 cdent melwitt: oh sorry, the change of 1.1 to 1 was not supposed to be committed
15:45:46 cdent will tidy that
15:46:00 melwitt ah k
15:46:09 cdent that was part of several different loops around the problem
15:46:26 cdent the fact that the new invalid header class exists now really makes stuff a lot harder to debug :(
15:47:18 melwitt oh, I see. so it makes everything do an AttributeError instead of complaining about the invalid things
15:47:32 bauzas dansmith: mriedem: stephenfin: others: because of me, hard reboot no longer accepts to recreate a libvirt guest, but I fixed that by https://review.openstack.org/564257
15:47:37 melwitt (in the test situation)
15:47:50 bauzas throw me tomatoes if you wish
15:48:06 cdent melwitt: the tests all end up getting None instead of the desire result
15:48:07 bauzas dansmith: mriedem: stephenfin: others: it'll also be a backport for Queens
15:48:27 cdent an invalid header operates as basically a header with no values
15:48:44 melwitt okay. I thought the lack of 'best_match' might have been because an invalid header was created. ignore me
15:48:58 cdent melwitt: ah, also: 1.1 is invalid too
15:49:10 cdent the valid range is 0 to 1
15:49:17 melwitt oh, I had no idea
15:49:31 cdent I can update the commit message to make that more clear?
15:49:51 melwitt meh it's fine. I was just curious when I saw it
15:49:58 cdent ✔
16:06:46 jaypipes mriedem, cdent: for the api-ref, what's the process for changing the documentation for a particular qstring parameter when that parameter was added in a prior microversion?
16:07:32 jaypipes mriedem, cdent: ref this patch: https://review.openstack.org/#/c/561315/
16:08:11 efried jaypipes: In this case, I would add to the existing parameter entry. Let me find an example...
16:08:37 jaypipes mriedem, cdent: I see existing things in the api-ref like resource_provider_generation_1_19, etc. but is there a magic incantation to show a different description for a parameter once a specific microversion is reached?
16:08:55 cdent min_version
16:08:56 efried jaypipes: What do you mean "reached"?
16:09:23 jaypipes efried: sorry, I'm having trouble explaining this..
16:09:24 efried jaypipes: But you're talking about member_of behaving differently at version Y than version X
16:09:29 cdent but what efried is saying is generally true for cases where the parameter is already around: add to the description "in microversion x you can do y"
16:09:33 efried https://developer.openstack.org/api-ref/placement/#list-allocation-candidates - see the `required` option.
16:09:37 jaypipes efried, cdent: yeah, what you just said eric :)
16:10:14 efried jaypipes: `required` uses both min_version (1.17) and an inline note about the additional functionality in 1.22.
16:10:39 efried jaypipes: So member_of will be similar. min_version 1.3, then new functionality in 1.2x
16:10:56 jaypipes efried: gotcha. inline note in the description field, then?
16:11:07 efried jaypipes: Yup
16:12:07 jaypipes efried: ok, thank you.
16:12:45 mriedem i've seen it both ways,
16:13:10 mriedem but yeah usually if the type doesn't change, we'd just add something to the parameter description saying, "starting with x, you can do foobars"

Earlier   Later