-
Notifications
You must be signed in to change notification settings - Fork 303
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
Comments
This is because libcompose added a default network config. |
So does ecs support the |
Also reported in #345. |
Is there a workaround? |
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
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
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
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
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:
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".
|
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
ecs-cli
warns me that it's skipping an unsupported YAML option (name=networks
), but the stringnetworks
does not appear in mydocker-compose.yml
:You can see the same warning pasted over and over into various issues.
The text was updated successfully, but these errors were encountered: