Since it appears the approach is to keep blocking this feature request until it goes away, I'm again asking for the ability to enable/disable containers in a docker-compose.yaml file temporarily, with an
enable:true or --disable
kind of mechanism.
I get that the developers don't want to do this, and have suggested that we use multiple docker-compose.yaml files, but:
-
Valid uses cases have been presented over and over (since 2015 at least) on why this is a good feature, but I have one too... I have a stack entirely used for local development purposes when we don't have AWS access. If I intend to debug only one of my applications in the stack, I don't need to bring up the other 12 applications that are also in my stack, or incur the cost of them starting up just to get my one app up. I also don't want to remove the apps from the stack, because tomorrow, I might need them. I haven't heard a good reason why this use case isn't valid.
-
Using multiple docker-compose.yaml files generates warnings that we also then have to quiet because the containers in the other files are now considered "orphans" (which is STOOPID - I only have one stack!). So, I had to turn off the warning about orphans, had to change my shutdown to force orphans to be removed, and then add code everywhere to run docker-compose multiple times based on flags I added in a startup script (which I wouldn't need if docker-compose supported this).
-
docker-compose ps, logs, etc also don't show all stacks, so you have to also pass in the -f docker-file.yaml arg as well to all of those commands as well. Now, so I don't spend all day typing, I have to have scripts to run what should be simple docker-compose commands. This also means I have to run a whole bunch of docker-compose ps commands just to view the real status of my stack rather than a single command.
I get that this wasn't in the original design, but the developers simply putting their foot down on this and refusing to address it, even when presented with a fix, and blocking comments from users, just makes everyone else have to work harder to achieve the same goals, and puts a bad taste in your users mouth's.
I really hope someone new can take a fresh look into this.
Since it appears the approach is to keep blocking this feature request until it goes away, I'm again asking for the ability to enable/disable containers in a docker-compose.yaml file temporarily, with an
enable:true or --disable
kind of mechanism.
I get that the developers don't want to do this, and have suggested that we use multiple docker-compose.yaml files, but:
Valid uses cases have been presented over and over (since 2015 at least) on why this is a good feature, but I have one too... I have a stack entirely used for local development purposes when we don't have AWS access. If I intend to debug only one of my applications in the stack, I don't need to bring up the other 12 applications that are also in my stack, or incur the cost of them starting up just to get my one app up. I also don't want to remove the apps from the stack, because tomorrow, I might need them. I haven't heard a good reason why this use case isn't valid.
Using multiple docker-compose.yaml files generates warnings that we also then have to quiet because the containers in the other files are now considered "orphans" (which is STOOPID - I only have one stack!). So, I had to turn off the warning about orphans, had to change my shutdown to force orphans to be removed, and then add code everywhere to run docker-compose multiple times based on flags I added in a startup script (which I wouldn't need if docker-compose supported this).
docker-compose ps, logs, etc also don't show all stacks, so you have to also pass in the -f docker-file.yaml arg as well to all of those commands as well. Now, so I don't spend all day typing, I have to have scripts to run what should be simple docker-compose commands. This also means I have to run a whole bunch of docker-compose ps commands just to view the real status of my stack rather than a single command.
I get that this wasn't in the original design, but the developers simply putting their foot down on this and refusing to address it, even when presented with a fix, and blocking comments from users, just makes everyone else have to work harder to achieve the same goals, and puts a bad taste in your users mouth's.
I really hope someone new can take a fresh look into this.