deis open opens http://<app name>.localhost in browser about controller HOT 18 CLOSED

Is this code still using the /deis/platform/domain key? That defaults to localhost. If so, we need either to update that mechanism not to use etcd, or document how to set that key correctly.

from controller.

Huh, I was under the assumption that it'd use the base domain that you used when you initially ran deis login. Good catch!

from controller.

Confirmed: if you etcdct set /deis/platform/domain 10.245.1.3.xip.io (or the appropriate IP), then deis open works correctly again, so the workflow controller is using the etcd key for this purpose.

from controller.

So... my $0.02... you have to tell the router the platform domain and the router doesn't use etcd at all... so making people set an etcd key is a DRY exception we'd be forcing on our users. I like the idea of the CLI deriving the platform domain automatically by scraping the deis. off the front of the controller's base URL and using what's left.

from controller.

Looked at this a little bit, problem is that we use ALLOWED_HOST = * in Django so using get_host or similar mechanisms are spoofable, depends if we care about that. That'd be determine if we do any sort of scraping or not

For now I'm going to make it so you can set a DEIS_CONTROLLER_DOMAIN and DEIS_CONTROLLER_SUBDOMAIN env var as a stop gap measure until we decide if we want people to add the platform domain on BOTH router and workflow

from controller.

I really think there's no need for that. Workflow does not need to know the platform domain. Only the router and the client do. The router knows the platform domain already (maybe; @bacobgobbler made it optional recently) but workflow and builder shouldn't need to know it...

git push can end with directions to use deis open. The deis CLI can infer the platform domain from the URL of the controller it is logged into.

from controller.

https://github.com/deis/workflow/search?utf8=%E2%9C%93&q=DEIS_DOMAIN is where the platform domain is "used".

The models.py usage of it seems to be not used but the BuildHook one appears to be in some sort of use, at least there are tests for it. I'd have to look deeper to confirm that. To be honest I'm all for reducing the need for workflow to know anything like this

from controller.

Is someone able to verify that deis open behaves more like advertised using a newer binary?

from controller.

Yes. It works as expected.

from controller.

I'm reopening. This was working for me for much of the day. Now, it's not.

What I'm experiencing is that with my client logged into http://deis.micro-kube.io and testing with an application named cheery-yardbird, deis open is directing my browser to http://cheery-yardbird.deis.micro-kube.com

The "deis" doesn't belong in that URL.

If think the reason this worked for me for most of the day is because I was not specifying a platform domain for most of the day. Without a platform domain specified, the router would have created a vhost that matches the pattern ~^cheery-yardbird\.(?<domain>.+)$-- and that happens to handle the incorrect URL just fine.

Now that I've specified a platform domain, vhosts are a little more specific-- like cheery-yardbird.micro-kube.io.

I'll try to track down the error in the client code.

from controller.

Ah, I was trying to strip out the subdomain initially but it is not super straightforward when you are dealing with scenarios that do not include a subdomain like the tests and especially when you are dealing with xip.io or straight up IPs. That really only happens when you are not going via the router.

I had a brainfart and decided we didn't need to strip but obviously that doesn't pan out all that great.

from controller.

Isn't the subdomain of the controller always deis? I think something like this works:

const workflowURLPrefix = "deis."
...
app.URL = fmt.Sprintf("%s.%s", app.ID, strings.TrimPrefix(c.ControllerURL.Host, workflowURLPrefix))

Stay tuned for PR.

from controller.

Ah... now that I think about it, the subdomain of the controller doesn't have to be deis. In v1.x that would have been true, but in v2, the controller is "just another app" from the router's perspective. The controller could have any address.

from controller.

But the code I posted will safely strip deis. from the beginning of the controller URL if it's there. So it at least improves the situation for the average case.

from controller.

It's configurable in django right now (https://github.com/deis/workflow/blob/master/rootfs/templates/confd_settings.py#L17 - defaults to deis). We could hardcode it... or not... I just don't want to try to reintroduce passing back URL information

from controller.

@helgi but the controller URL can literally be anything now. It can be my-awesome-controller.my-deis.com as long as you've annotated the service to make that one of the domains.

It's virtually impossible to accurately infer the app URL from a controller URL that could look like anything.

from controller.

So we settle for this heuristic?

from controller.

Yeah - I commented in the PR on what the potential solution could be if we wanted to tackle that. tl;dr put onus on end user

from controller.