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

Spurious "unsupported YAML option" for not-present keys #237

Closed
garthk opened this issue Apr 26, 2017 · 6 comments
Closed

Spurious "unsupported YAML option" for not-present keys #237

garthk opened this issue Apr 26, 2017 · 6 comments
Assignees
Labels

Comments

@garthk
Copy link

garthk commented Apr 26, 2017

ecs-cli warns me that it's skipping an unsupported YAML option (name=networks), but the string networks does not appear in my docker-compose.yml:

$ ecs-cli compose service up
WARN[0000] Skipping unsupported YAML option...           option name=networks
WARN[0000] Skipping unsupported YAML option for service...  option name=networks service name=loader
$ grep networks docker-compose.yml  | wc -l
       0

You can see the same warning pasted over and over into various issues.

@yinshiua
Copy link
Contributor

This is because libcompose added a default network config.
https://github.com/docker/libcompose/blob/master/project/project.go#L286

@hustshawn
Copy link

So does ecs support the networks / expose option now?

@SoManyHs
Copy link
Contributor

Support for network_mode is being actively developed.

Related to #267 and #153.

We can also look into suppressing the warning to avoid confusion about how the network field is being treated.

@SoManyHs
Copy link
Contributor

Also reported in #345.

@trahloff
Copy link

trahloff commented Jan 9, 2018

Is there a workaround?

SoManyHs added a commit to SoManyHs/amazon-ecs-cli that referenced this issue Jan 12, 2018
Previously, the check for the "networks" field was based on the
NetworkConfigs attribute on the project to be empty. Libcompose changed
the behavior of the Parse method to always create a "default" network
config (See: docker/libcompose@18dad7cb).

This caused a lot of spurious warnings for customers when they would try
to run a task even if the networks field was not specified in their
docker-compose files.

Fixes aws#406 and closes aws#237
SoManyHs added a commit to SoManyHs/amazon-ecs-cli that referenced this issue Jan 13, 2018
Previously, the check for the "networks" field was based on the
NetworkConfigs attribute on the project to be empty. Libcompose changed
the behavior of the Parse method to always create a "default" network
config (See: docker/libcompose@18dad7cb).

This caused a lot of spurious warnings for customers when they would try
to run a task even if the networks field was not specified in their
docker-compose files.

Fixes aws#406 and closes aws#237
SoManyHs added a commit to SoManyHs/amazon-ecs-cli that referenced this issue Jan 23, 2018
Previously, the check for the "networks" field was based on the
NetworkConfigs attribute on the project to be empty. Libcompose changed
the behavior of the Parse method to always create a "default" network
config (See: docker/libcompose@18dad7cb).

This caused a lot of spurious warnings for customers when they would try
to run a task even if the networks field was not specified in their
docker-compose files.

Fixes aws#406 and closes aws#237
SoManyHs added a commit to SoManyHs/amazon-ecs-cli that referenced this issue Jan 24, 2018
Previously, the check for the "networks" field was based on the
NetworkConfigs attribute on the project to be empty. Libcompose changed
the behavior of the Parse method to always create a "default" network
config (See: docker/libcompose@18dad7cb).

This caused a lot of spurious warnings for customers when they would try
to run a task even if the networks field was not specified in their
docker-compose files.

Fixes aws#406 and closes aws#237
@timwah
Copy link

timwah commented Jan 24, 2018

For what it's worth, I also see this for the "volumes" directive at the root level of a docker-compose file.

A simple docker-compose file with this format:

version: '2'
services:
    service1:
        image: XXX
        volumes:
            - test_volume:/opt/source/source_files
    service2:
        image: YYY
        volumes: 
            - test_volume:/source_files
volumes:
    test_volume:

This yields the following warning, even though when I look at the resulting task definition JSON, it looks like it successfully created the named volume "test_volume".

time="2018-01-24T22:14:11Z" level=warning msg="Skipping unsupported YAML option..." option name=volumes

SoManyHs added a commit to SoManyHs/amazon-ecs-cli that referenced this issue Jan 25, 2018
Previously, the check for the "networks" field was based on the
NetworkConfigs attribute on the project to be empty. Libcompose changed
the behavior of the Parse method to always create a "default" network
config (See: docker/libcompose@18dad7cb).

This caused a lot of spurious warnings for customers when they would try
to run a task even if the networks field was not specified in their
docker-compose files.

Fixes aws#406 and closes aws#237
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants