[API] external_links are ignored when creating a stack (environment) using the API


My assumption is that when passing a docker-compose.yml to the API when creating a stack it should behave just like it would had I used rancher-compose. It seems not to be the case for external links - they are ignored.

My simple (and not very constructive, I know, I’m playing with different features) docker-compose:

restart: "no"
- "Default/artifacts-external:artifacts-external"
image: nginx
command: sleep 30
io.rancher.container.start_once: true

and an even simpler rancher-compose.yml:

scale: ‘1’

So are my assumptions incorrect, or is this a bug?

There shouldn’t be any bug, but you might be hitting this issue where if you have multiple environments the links (including external ones) to not show up.

I’m assuming that you have the yaml file correctly white spaced as it’s not correctly whitespaced in what you provided.


I do have several environments, and I often see exactly that issue. But I don’t think that’s what’s going on here.
When I look at the service config the links aren’t there either, which I assume they would have to be should a refresh improve the situation. And a refresh has no effect.
And yes, the indentation is correct in the file but got crippled when pasting it to the chat.

What version of Rancher and rancher-compose are you using?

How did you check that external_links are not working? Also, is the artifacts-external service active? If there are no containers in the service that are running, there is nothing to return.

@denise I tried with version 0.46 and 0.47.
The “test” was simply looking at the resulting yaml configs in the UI. No external links showed up on any of the versions and refreshing the UI had no effect. And yes, the artifacts-external service was active.
The container was running for 30 seconds, then stopped. That was plenty for me to check the configs, and even do a refresh. Would Rancher need more time than that?

Do you know why the container stopped? Honestly, I don’t know if it would be enough time to check the config.

@denise, yes it stops because it only runs a sleep for 30 seconds (as evident from the yml file). It does not restart due to the run_once label. All of that works fine.
I’ve resorted to the docker API for our current batch processing needs, so I haven’t given this a try with the latest (0.50 and 0.50.1) versions.

I do see that issue #1389 is still present in the latest versions though.