Date
1 - 5 of 5
Hard-coded domain name in diego etcd job
MaggieMeng
Hi,
I am trying to deploy diego 0.1402.0 into vShpere server to work with CF 210. However the deployment failed when creating job 'etcd' with following error.
Error: cannot sync with the cluster using endpoints https://database-z1-0.etcd.service.cf.internal:4001
I tried to change the domain name to my own domain name in diego yml file. But it didn't work. I found the domain name was hard-coded in etcd_bosh_utils.sh.
https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/etcd/templates/etcd_bosh_utils.sh.erb
Could anyone tell me how to work around it?
Thanks,
Maggie
I am trying to deploy diego 0.1402.0 into vShpere server to work with CF 210. However the deployment failed when creating job 'etcd' with following error.
Error: cannot sync with the cluster using endpoints https://database-z1-0.etcd.service.cf.internal:4001
I tried to change the domain name to my own domain name in diego yml file. But it didn't work. I found the domain name was hard-coded in etcd_bosh_utils.sh.
https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/etcd/templates/etcd_bosh_utils.sh.erb
Could anyone tell me how to work around it?
Thanks,
Maggie
Gwenn Etourneau
You not should change it, this domain is use only with consul as DNS.
Many component rely on it, uaa and so on.
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/jobs/consul_agent/templates/config.json.erb
Do you have some logs ?
toggle quoted message
Show quoted text
Many component rely on it, uaa and so on.
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/jobs/consul_agent/templates/config.json.erb
Do you have some logs ?
On Mon, Aug 17, 2015 at 7:41 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:
Hi,
I am trying to deploy diego 0.1402.0 into vShpere server to work with CF
210. However the deployment failed when creating job ‘etcd’ with following
error.
*Error: cannot sync with the cluster using endpoints
https://database-z1-0.etcd.service.cf.internal:4001
<https://database-z1-0.etcd.service.cf.internal:4001>*
I tried to change the domain name to my own domain name in diego yml file.
But it didn’t work. I found the domain name was hard-coded in
etcd_bosh_utils.sh.
https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/etcd/templates/etcd_bosh_utils.sh.erb
Could anyone tell me how to work around it?
Thanks,
Maggie
MaggieMeng
Then how should I config my DNS server? Which host/job’s IP should be mapped to domain “service.cf.internal”?
I also attached the etcd job log. Would you please help to take a look?
Thanks,
Maggie
From: Gwenn Etourneau [mailto:getourneau(a)pivotal.io]
Sent: 2015年8月17日 18:51
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Hard-coded domain name in diego etcd job
You not should change it, this domain is use only with consul as DNS.
Many component rely on it, uaa and so on.
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/jobs/consul_agent/templates/config.json.erb
Do you have some logs ?
On Mon, Aug 17, 2015 at 7:41 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi,
I am trying to deploy diego 0.1402.0 into vShpere server to work with CF 210. However the deployment failed when creating job ‘etcd’ with following error.
Error: cannot sync with the cluster using endpoints https://database-z1-0.etcd.service.cf.internal:4001
I tried to change the domain name to my own domain name in diego yml file. But it didn’t work. I found the domain name was hard-coded in etcd_bosh_utils.sh.
https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/etcd/templates/etcd_bosh_utils.sh.erb
Could anyone tell me how to work around it?
Thanks,
Maggie
I also attached the etcd job log. Would you please help to take a look?
Thanks,
Maggie
From: Gwenn Etourneau [mailto:getourneau(a)pivotal.io]
Sent: 2015年8月17日 18:51
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Hard-coded domain name in diego etcd job
You not should change it, this domain is use only with consul as DNS.
Many component rely on it, uaa and so on.
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/jobs/consul_agent/templates/config.json.erb
Do you have some logs ?
On Mon, Aug 17, 2015 at 7:41 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
Hi,
I am trying to deploy diego 0.1402.0 into vShpere server to work with CF 210. However the deployment failed when creating job ‘etcd’ with following error.
Error: cannot sync with the cluster using endpoints https://database-z1-0.etcd.service.cf.internal:4001
I tried to change the domain name to my own domain name in diego yml file. But it didn’t work. I found the domain name was hard-coded in etcd_bosh_utils.sh.
https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/etcd/templates/etcd_bosh_utils.sh.erb
Could anyone tell me how to work around it?
Thanks,
Maggie
Amit Kumar Gupta
You should not change anything in your DNS servers. It is purely internal;
jobs that need to reach other services over the internal domain should be
colocated with consul_agents which will serve those DNS requests. It's all
self-contained.
toggle quoted message
Show quoted text
jobs that need to reach other services over the internal domain should be
colocated with consul_agents which will serve those DNS requests. It's all
self-contained.
On Mon, Aug 17, 2015 at 7:47 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:
Then how should I config my DNS server? Which host/job’s IP should be
mapped to domain “service.cf.internal”?
I also attached the etcd job log. Would you please help to take a look?
Thanks,
Maggie
*From:* Gwenn Etourneau [mailto:getourneau(a)pivotal.io]
*Sent:* 2015年8月17日 18:51
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] Re: Hard-coded domain name in diego etcd job
You not should change it, this domain is use only with consul as DNS.
Many component rely on it, uaa and so on.
https://github.com/cloudfoundry/cf-release/blob/90d730a2d13d9e065a7f348e7fd31a1522074d02/jobs/consul_agent/templates/config.json.erb
Do you have some logs ?
On Mon, Aug 17, 2015 at 7:41 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:
Hi,
I am trying to deploy diego 0.1402.0 into vShpere server to work with CF
210. However the deployment failed when creating job ‘etcd’ with following
error.
*Error: cannot sync with the cluster using endpoints
https://database-z1-0.etcd.service.cf.internal:4001
<https://database-z1-0.etcd.service.cf.internal:4001>*
I tried to change the domain name to my own domain name in diego yml file.
But it didn’t work. I found the domain name was hard-coded in
etcd_bosh_utils.sh.
https://github.com/cloudfoundry-incubator/diego-release/blob/develop/jobs/etcd/templates/etcd_bosh_utils.sh.erb
Could anyone tell me how to work around it?
Thanks,
Maggie
Eric Malm <emalm@...>
Hi, Maggie,
Apologies, I sent this reply to cf-dev earlier, but it seems not to have gone through. Anyway, the 'cf.internal' domain is used internally by CF and Diego components to do service discovery via consul DNS. You shouldn't need to change it, but for Diego to operate correctly you do need to have a consul cluster present in your CF deployment.
Also, I see you're attempting to deploy Diego 0.1402.0 against CF v210, but those versions are not interoperable. As mentioned in the CF release notes[1], we recommend you deploy Diego version 0.1247.0 against CF v210, or that you upgrade to CF v214 and deploy the recommended Diego version 0.1398.0 alongside it. In particular, that internal domain changed from 'consul' to 'cf.internal' after CF v213/Diego v0.1353.0, so there's no way Diego 0.1402.0 will work with CF v210.
Thanks,
Eric, CF Runtime Diego PM
[1]: https://github.com/cloudfoundry/cf-release/releases
Apologies, I sent this reply to cf-dev earlier, but it seems not to have gone through. Anyway, the 'cf.internal' domain is used internally by CF and Diego components to do service discovery via consul DNS. You shouldn't need to change it, but for Diego to operate correctly you do need to have a consul cluster present in your CF deployment.
Also, I see you're attempting to deploy Diego 0.1402.0 against CF v210, but those versions are not interoperable. As mentioned in the CF release notes[1], we recommend you deploy Diego version 0.1247.0 against CF v210, or that you upgrade to CF v214 and deploy the recommended Diego version 0.1398.0 alongside it. In particular, that internal domain changed from 'consul' to 'cf.internal' after CF v213/Diego v0.1353.0, so there's no way Diego 0.1402.0 will work with CF v210.
Thanks,
Eric, CF Runtime Diego PM
[1]: https://github.com/cloudfoundry/cf-release/releases