[
https://issues.apache.org/jira/browse/KUDU-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823441#comment-17823441
]
Maxwell Guo commented on KUDU-3529:
-----------------------------------
any update ?
> Multiple HTTP 200 response when determining cloud instance types could crash
> Kudu
> ---------------------------------------------------------------------------------
>
> Key: KUDU-3529
> URL: https://issues.apache.org/jira/browse/KUDU-3529
> Project: Kudu
> Issue Type: Improvement
> Reporter: Abhishek Chennaka
> Priority: Major
>
> During server startup to determine the cloud instance type, we query the
> link-local address 169.254.169.254. By default the flag values are as below:
> cloud_aws_instance_id_url http://169.254.169.254/latest/meta-data/instance-id
> cloud_azure_instance_id_url
> http://169.254.169.254/metadata/instance/compute/vmId?api-version=2018-10-01&format=text
> cloud_gce_instance_id_url -vs
> http://metadata.google.internal/computeMetadata/v1/instance/id
> cloud_openstack_instance_id_url
> http://169.254.169.254/openstack/latest/meta_data.json
> We rely on a HTTP 200 OK response from these URL to determine the instance
> type. I came across a situation where the call to this URL (except
> metadata.google.internal) was intercepted by a Firewall and resulted in a 200
> response for three of the URLs causing the servers to fail to start with the
> below response:
> {code:java}
> F20231121 11:48:39.135685 2094206 instance_detector.cc:109] Check failed:
> kNoIdx == result_detector_idx_ (18446744073709551615 vs. 1) conflicting cloud
> instance types
> {code}
> In order to avoid running into this issue we could parse the URL for the
> contents instead of relying on just the 200 response.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
