Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DescribeInstanceTypes does not return VCpuInfo #910

Closed
3 tasks done
r0kas opened this issue Nov 18, 2020 · 2 comments · Fixed by #992
Closed
3 tasks done

DescribeInstanceTypes does not return VCpuInfo #910

r0kas opened this issue Nov 18, 2020 · 2 comments · Fixed by #992
Assignees
Labels
bug This issue is a bug.

Comments

@r0kas
Copy link

r0kas commented Nov 18, 2020

Confirm by changing [ ] to [x] below to ensure that it's a bug:

Describe the bug
When describing an InstanceType like "t3a.large" or "t3a.xlarge" in returned 'InstanceTypeInfo' information about vCPUs is empty - VCpuInfo is nil.

In comparison MemoryInfo is fine and has all the details.

aws-sdk-go v1 does not have this issue and works as expected.

Version of AWS SDK for Go?
v0.29.0

Version of Go (go version)?
v1.15.2

To Reproduce (observed behavior)

reqInput := &ec2.DescribeInstanceTypesInput{
	InstanceTypes: []types.InstanceType{types.InstanceType("t3a.large")},
}

info, err := p.ec2.DescribeInstanceTypes(ctx, reqInput)
if err != nil {
	return nil, fmt.Errorf("describing instance type %q: %v", instanceType, err)
}

fmt.Println(info.InstanceTypes[0].VCpuInfo)

Output: nil

Expected behavior
Expected output:
{
DefaultCores: 1,
DefaultThreadsPerCore: 2,
DefaultVCpus: 2,
ValidCores: [1],
ValidThreadsPerCore: [1,2]
}

Additional context
Tried this out on "t3a.large" and "t3a.xlarge" instance types. Same behavior on both.
aws-sdk-go v1 works as expected.

@r0kas r0kas added the bug This issue is a bug. label Nov 18, 2020
@jasdel jasdel modified the milestone: v1.0 Release Candidate Dec 17, 2020
@skmcgrail skmcgrail self-assigned this Dec 18, 2020
@skmcgrail
Copy link
Member

Thanks for reporting this issue @r0kas, I can confirm this behavior and have narrowed it down to a deserialization bug. We will have this fixed in our next release.

@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

ungureanuvladvictor added a commit to cilium/cilium that referenced this issue Dec 24, 2020
Fixes b4b2263. The sdk had a bug where
it was not deserializing responses correctly
(aws/aws-sdk-go-v2#910).

Other changes are:
- `LoadDefaultConfig` accepts now a context object
- `github.com/aws/aws-sdk-go-v2/ec2imds` moved to
`github.com/aws/aws-sdk-go-v2/feature/ec2/imds`
- `github.com/awslabs/smithy-go` moved to `github.com/aws/smithy-go`

Signed-off-by: Vlad Ungureanu <vladu@palantir.com>
aanm pushed a commit to cilium/cilium that referenced this issue Dec 28, 2020
Fixes b4b2263. The sdk had a bug where
it was not deserializing responses correctly
(aws/aws-sdk-go-v2#910).

Other changes are:
- `LoadDefaultConfig` accepts now a context object
- `github.com/aws/aws-sdk-go-v2/ec2imds` moved to
`github.com/aws/aws-sdk-go-v2/feature/ec2/imds`
- `github.com/awslabs/smithy-go` moved to `github.com/aws/smithy-go`

Signed-off-by: Vlad Ungureanu <vladu@palantir.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants