DNS for SSH Proxy about cf-deployment HOT 17 CLOSED

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/138988189

The labels on this github issue will be updated when the story is started.

from cf-deployment.

cf-deployment made it a required input from the user

...or default to something meaningful. silver ideal is to only ask for system_domain (ideally not even that). if exposed properly people can always override it if it's necessary.

from cf-deployment.

I agree with @cppforlife, I'd still prefer to configure as little as possible as a user. This is assuming we do a better job of explaining the responsibility of DNS management to the user.

from cf-deployment.

👍 to that. Most (all?) of the *.sys domains are hard-coded. What's the customer value in letting it be configured?

from cf-deployment.

@cppforlife how would you imagine not asking for system domain?

@wendorf @drich10 I'm not a fan of magic, I'd much rather have an explicit dependency I can understand than magical wiring that I have to have tribal knowledge about.

The customer value in letting it be configured is that customers want to configure it. Pivotal Web Services manages the run.pivotal.io and cfapps.io domains differently. Customers also may wish to have multiple shared app domains.

Perhaps you're asking about the value in making users configure it, not about letting them configure it. Making them configure it makes the dependency clear and simple, less magical.

The issue actually conflates two things. There's less value in configuring the SSH domain, but it's also undocumented.

from cf-deployment.

Not to pile on, but I definitely don't want to add more required variables for basic OSS consumers of cf-deployment. That doesn't mean we can't make it easy(er) for other deployers/vendors out there in the world to extend cf-deployment to allow for more complex configuration.

With the way that CC "hard-codes" the ssh proxy location, it's impossible to even override this with an ops file. However, I was able to override the app_domains with a pretty simple ops file:

- type: replace
  path: /instance_groups/name=api/jobs/name=cloud_controller_ng/properties/app_domains
  value:
  - ((app_domain))
- type: replace
  path: /instance_groups/name=api/jobs/name=cloud_controller_worker/properties/app_domains
  value:
    - ((app_domain))
- type: replace
  path: /instance_groups/name=cc_clock/jobs/name=cloud_controller_clock/properties/app_domains
  value:
  - ((app_domain))

And manifest generation looked like this:

bosh int cf-deployment.yml \
  --var-errs \
  --vars-store ~/workspace/gcp-spike/deployment-vars.yml \
  -o ~/workspace/gcp-spike/override-apps-domain.yml \
  -v system_domain=cf-dsabeti.cf-app.com \
  -v app_domain=apps.cf-dsabeti.cf-app.com

which I think is sort of a nice UX -- you only get the new variable if you included the ops file.

If CAPI made the ssh proxy url configurable (but with the same default), vendors could similarly ship an ops file that requires a property called ((ssh_proxy_domain)) variable and override the default value.

EDIT [because Amit added a response while I was writing]:
@Amit-PivotalLabs, does adding these values to the specs, even with the same defaults, help with make this better documents / less magical?

from cf-deployment.

@dsabeti's snippets above are exactly what i was thinking. nice!

from cf-deployment.

Hey @Amit-PivotalLabs, there hasn't been much activity on this thread for a while, and I want to take action and the close this out.

It looks like capi-release still computes the ssh-proxy domain from the system domain. Do you want to submit a github issue for them to make the ssh-proxy domain configurable?

As for the "app domain," it's actually a slightly more complicated topic than we've implied here. There isn't really such a thing as the "app domain" -- the field simply seeds the SharedDomains table. If you change the value of app_domains after the first deploy, I'm not sure that anything gets updated in your Cloud Controller DB. It might make sense to support an ops file for configuring the app_domains on the initial deploy anyway, but we'd have to set expectations that the ops-file is only relevant for a bootstrap deploy.

cc @anEXPer

from cf-deployment.

from cf-deployment.

I suspect (but have not tested) that changing app_domains does affect the DB... but not how users might expect. I suspect it's additive only, which means if you have only one, and you change it, what you will actually get is a second shared domain. CC uses the first shared domain as a default, and the "changed" "app domain" won't be used.

The idea of an "app domain" configuration may have to go away. We'd be adding a concept in manifest tooling that doesn't actually exist in the spec.

from cf-deployment.

from cf-deployment.

Howdy folks. Reviving this thread again. I think we can address everything brought up here.

First of all, docs now include an explanation of DNS requirements for deployers: http://docs.cloudfoundry.org/deploying/common/dns_prereqs.html

As for seed value and app domains, we think that this story should prevent stale seed data from living on in deployment manifests, but still allows an out-of-the-box successful deploy:
https://www.pivotaltracker.com/story/show/149282005

How do these sound as solutions?

from cf-deployment.

It would be good if the docs pointed out exactly where an external LB should point SSH traffic to as well. A user moving to cf-deployment from an older setup might look for proxy_z1 & proxy_z2 and then have to consult the output of bosh instances --ps to find out that ssh_proxy is with diego-brain, for example.

from cf-deployment.

I think that's good advice, @jsievers. As I look through that doc, there are few other things that look cf-release-specific, so we should make sure they get updated once cf-deployment is GA.

from cf-deployment.

@dsabeti I guess you meant @jleavers :)

from cf-deployment.

Heh, it seems so. Sorry about that!

from cf-deployment.

Hi @jleavers, I made a PR (cloudfoundry/docs-deploying-cf#181) to the docs to describe where the ssh_proxy is located. I'll close the issue.

from cf-deployment.