aws-sdk-ruby: ECS register_task_definition validation bug (log_driver)
Issue description
I’m taking an existing valid task definition in json format, converting it to the proper casing and then resubmitting via the SDK. Only 1 validation error on submission:
2017-12-29T15:34:58.285Z 79621 TID-oumh4as1o WARN: ArgumentError: missing required parameter params[:container_definitions][0]["log_configuration"][:log_driver]
I can hack around this by either doing task['container_definitions'].first['log_configuration'][:log_driver] = 'awslogs'
to explicitly set the log_driver to be a symbol or it also works if I disable validation entirely Aws::ECS::Client.new(region: 'us-east-1', validate_params: false)
Gem name (‘aws-sdk’, ‘aws-sdk-resources’ or service gems like ‘aws-sdk-s3’) and its version
aws-sdk (2.10.105)
aws-sdk-resources (= 2.10.105)
aws-sdk-core (2.10.105)
aws-sigv4 (~> 1.0)
jmespath (~> 1.0)
aws-sdk-resources (2.10.105)
aws-sdk-core (= 2.10.105)
aws-sigv4 (1.0.2)
Version of Ruby, OS environment
2.3.1 on OSX
Code snippets / steps to reproduce
- Logging definition in json
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "awslogs-some-service",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "some-service"
}
},
- Main code body
ecs = Aws::ECS::Client.new(region: 'us-east-1')
task = JSON.parse(File.read(task_file))
task['containerDefinitions'].first['image'] = publish_image
skip_transform = task['containerDefinitions'].first['logConfiguration'].delete('options')
task.deep_transform_keys!(&:underscore).with_indifferent_access
task['container_definitions'].first['log_configuration']['options'] = skip_transform
task_revision = ecs.register_task_definition(
{container_definitions: task['container_definitions'], family: task['family'], task_role_arn: task['task_role_arn']}
)['task_definition']['revision']
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 17 (10 by maintainers)
To give some background, we have a task to investigate a safe way to consistently handle both symbolized and non-symbolized keys in our backlog. Likely, this would involve validation exceptions if the same key is provided twice.
Yes, it should be.