Earlier  
Posted Nick Remark
#openstack-nova - 2018-05-08
19:13:42 tssurya jaypipes: :P
19:13:51 jaypipes tssurya: :)
19:15:36 mriedem fortunately we already have a project_id index in the instance_mappings table
19:17:04 mriedem this unblocks osc-placement if someone wants to give the +W https://review.openstack.org/#/c/565694/
19:19:02 jaypipes mriedem: done
19:19:10 mriedem thanks
19:30:02 arvindn05 mriedem: quick question on your comment for https://review.openstack.org/#/c/560596 - update scheduler to use image-traits
19:30:59 arvindn05 for volume backed instance, there is no image right? so where do the image traits come in?
19:30:59 arvindn05 >>have a functional test for a volume-backed instance to show that we don't consider the required image traits
19:31:34 arvindn05 tests for launching volume backed instance should already capture this case correct?
19:33:47 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
19:33:48 openstackgerrit Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435
19:33:49 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857
19:34:20 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Add PLACEMENT_DB_ENABLED=True to the nova-next job https://review.openstack.org/564067
19:35:20 mriedem arvindn05: the root volume has an image in it
19:35:24 mriedem which could have required traits,
19:35:43 mriedem but yes that doesn't get put into the request spec so we don't filter on the image traits for volume-backed instances
19:36:18 arvindn05 mriedem: ahh..ok..dont know a lot about volume backed instances
19:36:37 mriedem arvindn05: a test could be that i have a single compute and an image with a required trait CUSTOM_FOO, and the compute doesn't have that trait. trying to create a server with just the image fails with novalidhost, but trying to create a volume-backed instance using that image passes because we don't filter on the image required traits in that case
19:38:47 arvindn05 i am guessing this should be in a single method? because the first part of the test is already part of the current functional test, but we will need to duplicate so we dont get intermittent success/failures?
19:40:51 arvindn05 or i can just create a test for volume backed instance case and use an image with trait and prove that it does not throw novalidhost
19:41:18 mriedem test_image_traits_based_scheduling_no_valid_host already tests the first thing i said, right
19:41:42 arvindn05 mriedem: is this a good example of how i can create a volume backed instance https://github.com/openstack/nova/blob/master/nova/tests/functional/test_servers.py#L1330
19:41:54 mriedem so you'd basically copy test_image_traits_based_scheduling_no_valid_host but _create_server_with_traits would include block_device_mapping_v2
19:42:41 mriedem yes and no,
19:42:59 mriedem that relies on https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L1323 to boot from an existing bootable volume in the fixture
19:43:29 mriedem so for your test, the image 155d900f-4e14-4e4c-a73d-069cbf4541e6 would need to have the required trait on it
19:43:34 mriedem see https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L1409
19:44:40 mriedem i think you get the idea though
19:44:51 mriedem and it's something that will need to be in whatever image property documentation exists for required traits
19:45:31 arvindn05 yup...we have a patch for all the documentation...will handle it as part of that
19:49:38 openstackgerrit Merged openstack/osc-placement master: Fix error message in test assert https://review.openstack.org/565694
19:51:44 efried melwitt: Is there a bug for the intermittent nova-next failure?
19:52:41 openstack Launchpad bug 1769286 in devstack "NoVNCConsoleTestJSON.test_novnc intermittently fails with: SecurityProxyNegotiationFailed: Failed to negotiate security type with server: No compute auth available: No matching auth scheme: allowed types: 'AuthType.NONE', desired types: '19'" [High,Fix released] - Assigned to melanie witt (melwitt)
19:52:41 melwitt efried: there was this one from yesterday https://launchpad.net/bugs/1769286
19:53:06 efried melwitt: Hum, okay, so this is not the same one: http://logs.openstack.org/57/517757/38/check/nova-next/4d5fdba/job-output.txt.gz#_2018-05-08_18_40_52_205203
19:53:06 melwitt efried: are you seeing new failures?
19:53:19 mriedem that's not vnc
19:53:32 mriedem and is a known latent bug
19:53:40 mriedem http://status.openstack.org/elastic-recheck/#1732199
19:54:06 efried mriedem: Thanks. I knew there's no way it could have anything to do with my 1.3KLOC patch.
19:54:15 melwitt :)
19:54:43 melwitt is e-r working these days? I feel like it's been at least a year since I saw it comment on any review
19:54:48 efried I thought once something was registered with elastic-recheck it posted comments to the gerrit review...
19:54:51 efried yeah, what melwitt said.
19:55:43 arvindn05 mriedem: Can i add a IMAGE_WITH_TRAITS_BACKED_VOL to CinderFixture for adding the unit test? or is there a different approach i should take...
19:57:07 arvindn05 *CinderFixtureNewAttachFlow
19:59:49 melwitt I remember asking about this VolumePathsNotFound during extend_volume http://logs.openstack.org/57/517757/38/check/nova-next/4d5fdba/logs/screen-n-cpu.txt.gz?level=TRACE#_May_08_18_35_13_576026 in the cinder channel awhile back, but no one had any ideas. it looks like something to do with iscsiadm not able to find or read the session
20:00:52 melwitt and I had no idea what that means or what could cause it
20:05:20 mriedem elastic-recheck used to not comment on changes because we'd hit a 15 minute timeout to process logs
20:05:39 melwitt I've asked in -infra
20:05:57 melwitt looks like anytime indexing is behind, it won't comment as it won't want to post stale info http://status.openstack.org/elastic-recheck/
20:06:02 melwitt maybe it's perpetually behind
20:06:36 mriedem arvindn05: the fixture is using a "real" image in the fake image service registry, so you could just update that image with required traits https://github.com/openstack/nova/blob/master/nova/tests/unit/image/fake.py#L44
20:07:05 mriedem in your test, like you're doing in setUp for the other image
20:11:02 arvindn05 cool...one other question though i am looking at https://developer.openstack.org/api-ref/block-storage/v3/#list-accessible-volumes-with-details
20:12:00 arvindn05 },
20:12:00 arvindn05 ....
20:12:00 arvindn05 "image_id": "b48c53e1-9a96-4a5a-a630-2e74ec54ddcc",
20:12:00 arvindn05 "kernel_id": "8a55f5f1-78f7-4477-8168-977d8519342c",
20:12:00 arvindn05 "volume_image_metadata": {
20:12:57 arvindn05 does volume image metadata ever even contain the image meta props like hw_architecture etc?
20:13:50 arvindn05 if the image meta data for a volume is just the image attributes rather than any of the standard fields of ImageMetaProps then again the test may not make sense
20:15:41 mriedem the volume's volume_image_metadata is a copy of the image metadata from the image or snapshot used to create the volume
20:16:15 mriedem so if we ever wanted/needed to actually filter volume-backed instances based on image metadata, we can totally do that by getting the image meta via the volume_image_metadata, we just don't do that today
20:17:13 mriedem http://git.openstack.org/cgit/openstack/cinder/tree/cinder/volume/flows/manager/create_volume.py#n559
20:19:06 arvindn05 },
20:19:06 arvindn05 ....
20:19:06 arvindn05 "trait:foo" "required"
20:19:06 arvindn05 "image_id": "b48c53e1-9a96-4a5a-a630-2e74ec54ddcc",
20:19:06 arvindn05 "volume_image_metadata": {
20:19:06 arvindn05 so if i have an image with trait:foo, then for a volume based on that image the meta data would look like below
20:19:29 arvindn05 or would the trait:foo field be missing and looked up when the image is loaded with the ID
20:19:58 mriedem arvindn05: maybe you should fire up a devstack and test this out for yourself
20:20:45 arvindn05 if its the above with trait:foo being part of volume_image_metadata then i would need to add to CinderFixtureNewAttachFlow else i can do your suggestion of updating the image directly
20:21:36 mriedem https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L1409 is not attempting to be an exhaustive list of what goes into volume_image_metadata for the cinder fixture
20:21:47 arvindn05 mriedem: havent worked with cinder before...so trying to cover the bases...will update my devstack to have cinder and try out as well
20:23:42 arvindn05 yea...if you knew off the top of the head if volume_image_metadata enumerates all ImageMetaProps(if defined on the image) that would help me get a headstart with the test
20:37:29 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Fix the policy argument in server-group-create https://review.openstack.org/564699
20:55:13 openstackgerrit karim proposed openstack/nova master: Pushing image traits to ironic node https://review.openstack.org/565620
20:58:38 openstackgerrit Eric Fried proposed openstack/nova master: Use .. deprecated:: theme for deprecations https://review.openstack.org/565822
21:05:54 mriedem melwitt: i don't know if this is a bug fix or a feature or what https://review.openstack.org/#/c/564193/
21:06:34 openstackgerrit Merged openstack/nova master: Bump pypowervm minimum to 1.1.15 https://review.openstack.org/564276
21:08:18 openstackgerrit Artom Lifshitz proposed openstack/nova master: Service version check for NUMA live migration https://review.openstack.org/566723
21:08:48 melwitt mriedem: yeah, looks like a driver parity thing. not sure if it's a feature either, not an expert on what image meta props really are
21:10:55 mriedem yeah it's adding support for hw_video_ram to the vmware driver
21:11:00 mriedem so not a bug
21:11:23 mriedem the commit message totally makes it sound like it's fixing something, but it's not
21:11:31 mriedem "fix this new thing that i'm adding"
21:12:01 melwitt yeah, agreed. good doc finds in your comment
21:13:41 melwitt we usually do blueprints for driver parity things but this is indeed a lot smaller than most of the parity things we usually see. kind of more along the lines of adding the aarch64 support stuff maybe?
21:16:06 melwitt so maybe don't need a blueprint but do need release note and doc update at a minimum
21:17:08 mriedem yeah i don't think we need a blueprint either
21:17:10 mriedem just reno and doc updates
21:17:56 melwitt ++
21:18:38 melwitt looks like the doc update would be in glance though
21:18:51 mriedem for the image properties one yeah,
21:18:58 mriedem but we should also document the flavor extra spec in our docs
21:19:23 melwitt yeah -- just not sure it has to fall on their change though, since it's currently undocumented even for the libvirt driver
21:20:03 mriedem melwitt: ok, i'll do them a solid and push a patch below theirs that adds the flavor extra spec doc, and they can then update it

Earlier   Later