| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-08 | |||
| 17:57:02 | mriedem | efried: https://bugs.launchpad.net/nova/+bug/1469179 ? | |
| 17:57:02 | openstack | Launchpad bug 1469179 in OpenStack Compute (nova) "instance.root_gb should be 0 for volume-backed instances" [Medium,In progress] - Assigned to Dan Smith (danms) | |
| 18:23:50 | efried | Thanks mriedem | |
| 18:44:11 | dansmith | tssurya: have you looked over this yet? https://review.openstack.org/#/c/509003/ | |
| 18:44:39 | dansmith | mriedem: melwitt: do you both agree that having a config flag for gating that ^ vs. just hitting all cells is a good idea? | |
| 18:44:42 | tssurya | dansmith: oops, not yet, will review now | |
| 18:44:53 | dansmith | tssurya: okay I want to make sure it will work for you | |
| 18:47:27 | mriedem | umm, | |
| 18:47:48 | mriedem | since most people aren't >1 cell yet, that adds an extra db hit to every GET /servers operation right? | |
| 18:50:50 | dansmith | yeah, which is why I think it probably needs a config knob | |
| 18:51:01 | dansmith | it should be a huge benefit to cern, but not most people | |
| 18:51:31 | tssurya | dansmith: this works for us since we have a lot of cells, but I think from a developer perspective we wouldn't want to retrieve the mappings every time , so I vote for a config option -> same logic in us doing refresh handler for disable cells to maintain the cache. | |
| 18:52:37 | dansmith | aye | |
| 19:00:02 | jaypipes | dansmith: my thought was that such an option could easily be added if it becomes an issue later. | |
| 19:01:59 | mriedem | dansmith: well, you could create 1000 fake instances and compare the average time to list them either way and see if the extra join is a noticeable impact | |
| 19:02:17 | dansmith | mriedem: extra join? | |
| 19:02:26 | mriedem | instance mappings -> cell mappings | |
| 19:02:34 | jaypipes | mriedem: it's not a join. just an extra query against instance_mappings IIRC | |
| 19:02:35 | mriedem | the upfront extra join to filter cell mappings based on project_id | |
| 19:02:38 | dansmith | it's a whole extra hit, not just a join | |
| 19:02:57 | mriedem | the "new extra db kerfuffle" | |
| 19:03:57 | dansmith | I prefer to just make it default to continue using the cache, and let people like cern opt into this behavior | |
| 19:09:00 | melwitt | mriedem: sweet, thanks for closing out the bp | |
| 19:10:29 | jaypipes | stephenfin: still around? | |
| 19:11:52 | jaypipes | stephenfin: what precisely do you mean by "mechanisms" in "Like provider networks, tenant networks can use one of five mechanisms: *flat*, *VLAN*, *local*, *VXLAN*, or *GRE*."? In particular, what is "local mechanism"? | |
| 19:12:55 | melwitt | dansmith: config option sounds okay ... the only bad side is, yet-another-config-option. and I'm thinking how can we group cells-related options, CONF.cells is already taken by cells v1 | |
| 19:13:23 | jaypipes | melwitt: CONF.cern? ;) | |
| 19:13:25 | mriedem | CONF.api.something | |
| 19:13:35 | melwitt | heh | |
| 19:13:38 | mriedem | CONF.api.multicell_project_per_cell | |
| 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 | >>have a functional test for a volume-backed instance to show that we don't consider the required image traits | |
| 19:30:59 | arvindn05 | for volume backed instance, there is no image right? so where do the image traits come in? | |
| 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 | melwitt | efried: there was this one from yesterday https://launchpad.net/bugs/1769286 | |
| 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:53:06 | melwitt | efried: are you seeing new failures? | |
| 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: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 | "volume_image_metadata": { | |
| 20:12:00 | arvindn05 | "kernel_id": "8a55f5f1-78f7-4477-8168-977d8519342c", | |
| 20:12:00 | arvindn05 | "image_id": "b48c53e1-9a96-4a5a-a630-2e74ec54ddcc", | |
| 20:12:00 | arvindn05 | .... | |
| 20:12:00 | arvindn05 | }, | |
| 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 | 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:06 | arvindn05 | "volume_image_metadata": { | |
| 20:19:06 | arvindn05 | "image_id": "b48c53e1-9a96-4a5a-a630-2e74ec54ddcc", | |
| 20:19:06 | arvindn05 | "trait:foo" "required" | |