Date
1 - 13 of 13
Reg the minimal-openstack yml files
|
Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
Hi
We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar one available for openstack environment, with which we can deploy the basic cloud foundry and do our custom changes on top of it Parallely we are updating our stub to match the template yml files guided by the errors given by the generate_deployment_manifest script. Kindly let us know if this is the correct way to generate the manifest. Regards Nithiyasri |
|
|
|
Amit Kumar Gupta
We're not likely to be able to create and maintain a new minimal manifest
any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of the latest release: http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html Combining this with updating your current template guided by the errors is a good way to generate the manifest. This is not guaranteed to work for 100% of use cases, e.g. if you want to use all floating IPs instead of static IPs. But it is a good starting point. Cheers, Amit On Mon, Mar 7, 2016 at 4:09 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote: Hi |
|
|
|
Jayarajan Ramapurath Kozhummal (jayark) <jayark@...>
Thanks Amit!
toggle quoted message
Show quoted text
A minor correction in our case. We are not using static IP. We are only using dynamic IP. None of the Cloud Foundry components are using Floating IP. What is Pivotal recommendation for the networking? Is it static or dynamic? Given that we are using dynamic IPs, do you foresee any issues with our current approach to generate the manifest for CF-229? Regards Jayaraj From: Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> Date: Monday, March 7, 2016 at 12:24 PM To: "Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)" <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> Cc: Rohit Kumar <rokumar(a)pivotal.io<mailto:rokumar(a)pivotal.io>>, Jayarajan Ramapurath Kozhummal <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Subject: Re: Reg the minimal-openstack yml files We're not likely to be able to create and maintain a new minimal manifest any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of the latest release: http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html Combining this with updating your current template guided by the errors is a good way to generate the manifest. This is not guaranteed to work for 100% of use cases, e.g. if you want to use all floating IPs instead of static IPs. But it is a good starting point. Cheers, Amit
On Mon, Mar 7, 2016 at 4:09 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar one available for openstack environment, with which we can deploy the basic cloud foundry and do our custom changes on top of it Parallely we are updating our stub to match the template yml files guided by the errors given by the generate_deployment_manifest script. Kindly let us know if this is the correct way to generate the manifest. Regards Nithiyasri |
|
|
|
Amit Kumar Gupta
You need some static IPs, because some components don't use service
discovery, so clients need to be configured up front to know those components' IPs. For example, the route-registrar jobs talk to the NATS cluster to register routes for CC, HM9k, UAA, and Doppler. NATS servers must be assigned static IPs in the manifest and components like route-registrar that talk to NATS need to have those IPs provided in their config in the manifest. This current requirement on static IPs exists for some other components as well. Some other components however would be fine with dynamic networking. A private vendor may be able to work with you to manage a Cloud Foundry installation that suits your networking requirements, but said guidance is beyond the scope of this mailing list. The deployments that the Foundation tests continuously use static IPs for simplicity. Cheers, Amit On Monday, March 7, 2016, Jayarajan Ramapurath Kozhummal (jayark) < jayark(a)cisco.com> wrote: Thanks Amit! |
|
|
|
Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
Hi Amit
Thanks your reply We understood the must of static IP of routers in uaa jobs. Kindly let me know if we can give the DNS entry name (hostname) of the router in the uaa job - 0.router-z1.ccc-bosh-net.<%= $deployment_name %>.microbosh We are also parallel trying to get the help of a private vendor to help us on the installation, as told by you Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io] Sent: Tuesday, March 08, 2016 3:43 AM To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org> Cc: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com> Subject: Re: Reg the minimal-openstack yml files You need some static IPs, because some components don't use service discovery, so clients need to be configured up front to know those components' IPs. For example, the route-registrar jobs talk to the NATS cluster to register routes for CC, HM9k, UAA, and Doppler. NATS servers must be assigned static IPs in the manifest and components like route-registrar that talk to NATS need to have those IPs provided in their config in the manifest. This current requirement on static IPs exists for some other components as well. Some other components however would be fine with dynamic networking. A private vendor may be able to work with you to manage a Cloud Foundry installation that suits your networking requirements, but said guidance is beyond the scope of this mailing list. The deployments that the Foundation tests continuously use static IPs for simplicity. Cheers, Amit On Monday, March 7, 2016, Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> wrote: Thanks Amit! A minor correction in our case. We are not using static IP. We are only using dynamic IP. None of the Cloud Foundry components are using Floating IP. What is Pivotal recommendation for the networking? Is it static or dynamic? Given that we are using dynamic IPs, do you foresee any issues with our current approach to generate the manifest for CF-229? Regards Jayaraj From: Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> Date: Monday, March 7, 2016 at 12:24 PM To: "Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)" <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> Cc: Rohit Kumar <rokumar(a)pivotal.io<mailto:rokumar(a)pivotal.io>>, Jayarajan Ramapurath Kozhummal <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Subject: Re: Reg the minimal-openstack yml files We're not likely to be able to create and maintain a new minimal manifest any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of the latest release: http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html Combining this with updating your current template guided by the errors is a good way to generate the manifest. This is not guaranteed to work for 100% of use cases, e.g. if you want to use all floating IPs instead of static IPs. But it is a good starting point. Cheers, Amit On Mon, Mar 7, 2016 at 4:09 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar one available for openstack environment, with which we can deploy the basic cloud foundry and do our custom changes on top of it Parallely we are updating our stub to match the template yml files guided by the errors given by the generate_deployment_manifest script. Kindly let us know if this is the correct way to generate the manifest. Regards Nithiyasri |
|
|
|
Yitao Jiang
Of course yes, assuming you have add the director as the dns resolver in
UAA job. On Wed, Mar 9, 2016 at 4:38 PM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote: Hi Amit -- Regards, Yitao |
|
|
|
Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
Hi Amit
We are trying to upgrade cf-205 to cf-230. So I have checked out with the commit id of cf-230.yml and I could generate the manifest using the generate_deployment_manifest script for our stub. While deploying , consul_z1 job was not started, though all the other jobs are running. Consul Logs below :: consul_agent.stdout.log:: {"timestamp":"1457972549.805328369","source":"confab","message":"confab.agent-client.verify-joined.members.not-joined","log_level":2,"data":{"error":"no expected members","members":["10.20.0.116"],"wan":false}} consul_agent.stderr.log:: ++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log error booting consul agent: timeout exceeded Properties in yml: consul: agent: log_level: INFO servers: lan: - 0.consul-z1.ccc-bosh-net.<%= $deployment_name %>.microbosh require_ssl: false Please note that 10.20.0.116 will resolve to lan member dns name. As we don’t use static ip, we have given the dns hostname of the consul and the corresponding ip is picked by the consul job too.. I also have included the consul_agent template in haproxy job as stated by you in the below mail threadhttps://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/FCWBMKVOZSI4D6RBTOHL3JL42JN2LCRS/#4OW3HWF55O7TQRRM4UEQFHT4OPCNV7NB I have another question: Pls let me know is it possible to upgrade a deployment of cf-205 to cf-230, with the updated yml file. With cf-230 release, new jobs like api_z1,uaa, hm9000, clock_global, etc have been added and cloud_controller, dea, etc have been removed.. Will the upgrade, remove the unwanted jobs and create new jobs ? or a fresh deployment of cf-230 is only possible? We do cf push few apps into dea vms in our existing deployment. With the new cf-230, will metron agent accept cf push of apps? Thank you very much for your support. Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io] Sent: Tuesday, March 08, 2016 3:43 AM To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org> Cc: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com> Subject: Re: Reg the minimal-openstack yml files You need some static IPs, because some components don't use service discovery, so clients need to be configured up front to know those components' IPs. For example, the route-registrar jobs talk to the NATS cluster to register routes for CC, HM9k, UAA, and Doppler. NATS servers must be assigned static IPs in the manifest and components like route-registrar that talk to NATS need to have those IPs provided in their config in the manifest. This current requirement on static IPs exists for some other components as well. Some other components however would be fine with dynamic networking. A private vendor may be able to work with you to manage a Cloud Foundry installation that suits your networking requirements, but said guidance is beyond the scope of this mailing list. The deployments that the Foundation tests continuously use static IPs for simplicity. Cheers, Amit On Monday, March 7, 2016, Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> wrote: Thanks Amit! A minor correction in our case. We are not using static IP. We are only using dynamic IP. None of the Cloud Foundry components are using Floating IP. What is Pivotal recommendation for the networking? Is it static or dynamic? Given that we are using dynamic IPs, do you foresee any issues with our current approach to generate the manifest for CF-229? Regards Jayaraj From: Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> Date: Monday, March 7, 2016 at 12:24 PM To: "Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)" <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> Cc: Rohit Kumar <rokumar(a)pivotal.io<mailto:rokumar(a)pivotal.io>>, Jayarajan Ramapurath Kozhummal <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Subject: Re: Reg the minimal-openstack yml files We're not likely to be able to create and maintain a new minimal manifest any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of the latest release: http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html Combining this with updating your current template guided by the errors is a good way to generate the manifest. This is not guaranteed to work for 100% of use cases, e.g. if you want to use all floating IPs instead of static IPs. But it is a good starting point. Cheers, Amit On Mon, Mar 7, 2016 at 4:09 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar one available for openstack environment, with which we can deploy the basic cloud foundry and do our custom changes on top of it Parallely we are updating our stub to match the template yml files guided by the errors given by the generate_deployment_manifest script. Kindly let us know if this is the correct way to generate the manifest. Regards Nithiyasri |
|
|
|
Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
+Added some more details below
From: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) Sent: Monday, March 14, 2016 10:02 PM To: 'Amit Gupta' <agupta(a)pivotal.io>; Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org> Cc: Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com> Subject: RE: Reg the minimal-openstack yml files Hi Amit We are trying to upgrade cf-205 to cf-230. So I have checked out with the commit id of cf-230.yml and I could generate the manifest using the generate_deployment_manifest script for our stub. While deploying , consul_z1 job was not started, though all the other jobs are running. Consul Logs below :: consul_agent.stdout.log:: {"timestamp":"1457972549.805328369","source":"confab","message":"confab.agent-client.verify-joined.members.not-joined","log_level":2,"data":{"error":"no expected members","members":["10.20.0.116"],"wan":false}} consul_agent.stderr.log:: ++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log error booting consul agent: timeout exceeded Properties in yml: consul: agent: log_level: INFO servers: lan: - 0.consul-z1.ccc-bosh-net.<%= $deployment_name %>.microbosh require_ssl: false Please note that 10.20.0.116 will resolve to lan member dns name. As we don’t use static ip, we have given the dns hostname of the consul and the corresponding ip is picked by the consul job too.. I tried giving the static ip in consul.agent.servers.lan:10.20.0.116. But I get following error: ==> Error starting agent: Failed to start Consul server: Failed to start RPC layer: listen tcp 10.20.0.116:8300: bind: address already in use I also have included the consul_agent template in haproxy job as stated by you in the below mail threadhttps://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/FCWBMKVOZSI4D6RBTOHL3JL42JN2LCRS/#4OW3HWF55O7TQRRM4UEQFHT4OPCNV7NB I have another question: Pls let me know is it possible to upgrade a deployment of cf-205 to cf-230, with the updated yml file. With cf-230 release, new jobs like api_z1,uaa, hm9000, clock_global, etc have been added and cloud_controller, dea, etc have been removed.. Will the upgrade, remove the unwanted jobs and create new jobs ? or a fresh deployment of cf-230 is only possible? We do cf push few apps into dea vms in our existing deployment. With the new cf-230, will metron agent accept cf push of apps? Thank you very much for your support. Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io] Sent: Tuesday, March 08, 2016 3:43 AM To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Cc: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> Subject: Re: Reg the minimal-openstack yml files You need some static IPs, because some components don't use service discovery, so clients need to be configured up front to know those components' IPs. For example, the route-registrar jobs talk to the NATS cluster to register routes for CC, HM9k, UAA, and Doppler. NATS servers must be assigned static IPs in the manifest and components like route-registrar that talk to NATS need to have those IPs provided in their config in the manifest. This current requirement on static IPs exists for some other components as well. Some other components however would be fine with dynamic networking. A private vendor may be able to work with you to manage a Cloud Foundry installation that suits your networking requirements, but said guidance is beyond the scope of this mailing list. The deployments that the Foundation tests continuously use static IPs for simplicity. Cheers, Amit On Monday, March 7, 2016, Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> wrote: Thanks Amit! A minor correction in our case. We are not using static IP. We are only using dynamic IP. None of the Cloud Foundry components are using Floating IP. What is Pivotal recommendation for the networking? Is it static or dynamic? Given that we are using dynamic IPs, do you foresee any issues with our current approach to generate the manifest for CF-229? Regards Jayaraj From: Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> Date: Monday, March 7, 2016 at 12:24 PM To: "Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)" <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> Cc: Rohit Kumar <rokumar(a)pivotal.io<mailto:rokumar(a)pivotal.io>>, Jayarajan Ramapurath Kozhummal <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Subject: Re: Reg the minimal-openstack yml files We're not likely to be able to create and maintain a new minimal manifest any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of the latest release: http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html Combining this with updating your current template guided by the errors is a good way to generate the manifest. This is not guaranteed to work for 100% of use cases, e.g. if you want to use all floating IPs instead of static IPs. But it is a good starting point. Cheers, Amit On Mon, Mar 7, 2016 at 4:09 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar one available for openstack environment, with which we can deploy the basic cloud foundry and do our custom changes on top of it Parallely we are updating our stub to match the template yml files guided by the errors given by the generate_deployment_manifest script. Kindly let us know if this is the correct way to generate the manifest. Regards Nithiyasri |
|
|
|
Amit Kumar Gupta
Using the DNS hostname of consul instead of the IP will not work in CF
v230. It should work in v231. Open source Cloud Foundry does not guarantee direct upgrades between non-consecutive versions. I have no way to tell you if 205 to 230 will work. Some proprietary distributions of CF from certified vendors do support slower upgrade cadences. I'm sorry, but it looks as though you're asking 5 or 6 different questions, and with the change in color, boldness, underline, etc. I find it very difficult to follow. Best, Amit On Mon, Mar 14, 2016 at 9:32 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote: Hi Amit |
|
|
|
Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
Hi Amit
Sorry if the colors, and bolding disturbs you .. Will refrain from using that. I tried giving the static ip in consul.agent.servers.lan:10.20.0.116. But I get following error in cf-230 ==> Error starting agent: Failed to start Consul server: Failed to start RPC layer: listen tcp 10.20.0.116:8300: bind: address already in use Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io] Sent: Monday, March 14, 2016 11:10 PM To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com> Subject: Re: Reg the minimal-openstack yml files Using the DNS hostname of consul instead of the IP will not work in CF v230. It should work in v231. Open source Cloud Foundry does not guarantee direct upgrades between non-consecutive versions. I have no way to tell you if 205 to 230 will work. Some proprietary distributions of CF from certified vendors do support slower upgrade cadences. I'm sorry, but it looks as though you're asking 5 or 6 different questions, and with the change in color, boldness, underline, etc. I find it very difficult to follow. Best, Amit On Mon, Mar 14, 2016 at 9:32 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi Amit We are trying to upgrade cf-205 to cf-230. So I have checked out with the commit id of cf-230.yml and I could generate the manifest using the generate_deployment_manifest script for our stub. While deploying , consul_z1 job was not started, though all the other jobs are running. Consul Logs below :: consul_agent.stdout.log:: {"timestamp":"1457972549.805328369","source":"confab","message":"confab.agent-client.verify-joined.members.not-joined","log_level":2,"data":{"error":"no expected members","members":["10.20.0.116"],"wan":false}} consul_agent.stderr.log:: ++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log error booting consul agent: timeout exceeded Properties in yml: consul: agent: log_level: INFO servers: lan: - 0.consul-z1.ccc-bosh-net.<%= $deployment_name %>.microbosh require_ssl: false Please note that 10.20.0.116 will resolve to lan member dns name. As we don’t use static ip, we have given the dns hostname of the consul and the corresponding ip is picked by the consul job too.. I also have included the consul_agent template in haproxy job as stated by you in the below mail threadhttps://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/FCWBMKVOZSI4D6RBTOHL3JL42JN2LCRS/#4OW3HWF55O7TQRRM4UEQFHT4OPCNV7NB I have another question: Pls let me know is it possible to upgrade a deployment of cf-205 to cf-230, with the updated yml file. With cf-230 release, new jobs like api_z1,uaa, hm9000, clock_global, etc have been added and cloud_controller, dea, etc have been removed.. Will the upgrade, remove the unwanted jobs and create new jobs ? or a fresh deployment of cf-230 is only possible? We do cf push few apps into dea vms in our existing deployment. With the new cf-230, will metron agent accept cf push of apps? Thank you very much for your support. Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>] Sent: Tuesday, March 08, 2016 3:43 AM To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Cc: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> Subject: Re: Reg the minimal-openstack yml files You need some static IPs, because some components don't use service discovery, so clients need to be configured up front to know those components' IPs. For example, the route-registrar jobs talk to the NATS cluster to register routes for CC, HM9k, UAA, and Doppler. NATS servers must be assigned static IPs in the manifest and components like route-registrar that talk to NATS need to have those IPs provided in their config in the manifest. This current requirement on static IPs exists for some other components as well. Some other components however would be fine with dynamic networking. A private vendor may be able to work with you to manage a Cloud Foundry installation that suits your networking requirements, but said guidance is beyond the scope of this mailing list. The deployments that the Foundation tests continuously use static IPs for simplicity. Cheers, Amit On Monday, March 7, 2016, Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> wrote: Thanks Amit! A minor correction in our case. We are not using static IP. We are only using dynamic IP. None of the Cloud Foundry components are using Floating IP. What is Pivotal recommendation for the networking? Is it static or dynamic? Given that we are using dynamic IPs, do you foresee any issues with our current approach to generate the manifest for CF-229? Regards Jayaraj From: Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> Date: Monday, March 7, 2016 at 12:24 PM To: "Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)" <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> Cc: Rohit Kumar <rokumar(a)pivotal.io<mailto:rokumar(a)pivotal.io>>, Jayarajan Ramapurath Kozhummal <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Subject: Re: Reg the minimal-openstack yml files We're not likely to be able to create and maintain a new minimal manifest any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of the latest release: http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html Combining this with updating your current template guided by the errors is a good way to generate the manifest. This is not guaranteed to work for 100% of use cases, e.g. if you want to use all floating IPs instead of static IPs. But it is a good starting point. Cheers, Amit On Mon, Mar 7, 2016 at 4:09 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar one available for openstack environment, with which we can deploy the basic cloud foundry and do our custom changes on top of it Parallely we are updating our stub to match the template yml files guided by the errors given by the generate_deployment_manifest script. Kindly let us know if this is the correct way to generate the manifest. Regards Nithiyasri |
|
|
|
Amit Kumar Gupta
Try the following:
ssh onto the consul VM run "sudo su -" to switch to root run "monit stop consul_agent" run "ps uwax | grep consul" to see if there are any errant consul-related processes, and kill them run "rm -rf /var/vcap/store/consul_agent" run "monit start consul_agent" This will blow away all the consul data, which is okay because it's all ephemeral data that is continuously repopulated. In your case, the "rm -rf" step may not be strictly necessary, but this "hard reset" strategy tends to be the cleanest and avoids unforeseen edge cases. This is all assuming you only have one instance of the consul server. Best, Amit On Mon, Mar 14, 2016 at 7:22 PM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:
|
|
|
|
Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
Hi Amit
Thank you very much for your support, as I am able to successfully deploy with cf-231. We use DNS hostname for all the jobs, with dynamic IP networks. So I used cf-231 release today.. All the jobs are up and running.. Thanks for the pointers you have given.. Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io] Sent: Tuesday, March 15, 2016 8:00 AM To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com> Subject: Re: Reg the minimal-openstack yml files Try the following: ssh onto the consul VM run "sudo su -" to switch to root run "monit stop consul_agent" run "ps uwax | grep consul" to see if there are any errant consul-related processes, and kill them run "rm -rf /var/vcap/store/consul_agent" run "monit start consul_agent" This will blow away all the consul data, which is okay because it's all ephemeral data that is continuously repopulated. In your case, the "rm -rf" step may not be strictly necessary, but this "hard reset" strategy tends to be the cleanest and avoids unforeseen edge cases. This is all assuming you only have one instance of the consul server. Best, Amit On Mon, Mar 14, 2016 at 7:22 PM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi Amit Sorry if the colors, and bolding disturbs you .. Will refrain from using that. I tried giving the static ip in consul.agent.servers.lan:10.20.0.116. But I get following error in cf-230 ==> Error starting agent: Failed to start Consul server: Failed to start RPC layer: listen tcp 10.20.0.116:8300<http://10.20.0.116:8300>: bind: address already in use Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>] Sent: Monday, March 14, 2016 11:10 PM To: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> Cc: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> Subject: Re: Reg the minimal-openstack yml files Using the DNS hostname of consul instead of the IP will not work in CF v230. It should work in v231. Open source Cloud Foundry does not guarantee direct upgrades between non-consecutive versions. I have no way to tell you if 205 to 230 will work. Some proprietary distributions of CF from certified vendors do support slower upgrade cadences. I'm sorry, but it looks as though you're asking 5 or 6 different questions, and with the change in color, boldness, underline, etc. I find it very difficult to follow. Best, Amit On Mon, Mar 14, 2016 at 9:32 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi Amit We are trying to upgrade cf-205 to cf-230. So I have checked out with the commit id of cf-230.yml and I could generate the manifest using the generate_deployment_manifest script for our stub. While deploying , consul_z1 job was not started, though all the other jobs are running. Consul Logs below :: consul_agent.stdout.log:: {"timestamp":"1457972549.805328369","source":"confab","message":"confab.agent-client.verify-joined.members.not-joined","log_level":2,"data":{"error":"no expected members","members":["10.20.0.116"],"wan":false}} consul_agent.stderr.log:: ++ tee -a /var/vcap/sys/log/consul_agent/consul_agent.stdout.log error booting consul agent: timeout exceeded Properties in yml: consul: agent: log_level: INFO servers: lan: - 0.consul-z1.ccc-bosh-net.<%= $deployment_name %>.microbosh require_ssl: false Please note that 10.20.0.116 will resolve to lan member dns name. As we don’t use static ip, we have given the dns hostname of the consul and the corresponding ip is picked by the consul job too.. I also have included the consul_agent template in haproxy job as stated by you in the below mail threadhttps://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/FCWBMKVOZSI4D6RBTOHL3JL42JN2LCRS/#4OW3HWF55O7TQRRM4UEQFHT4OPCNV7NB I have another question: Pls let me know is it possible to upgrade a deployment of cf-205 to cf-230, with the updated yml file. With cf-230 release, new jobs like api_z1,uaa, hm9000, clock_global, etc have been added and cloud_controller, dea, etc have been removed.. Will the upgrade, remove the unwanted jobs and create new jobs ? or a fresh deployment of cf-230 is only possible? We do cf push few apps into dea vms in our existing deployment. With the new cf-230, will metron agent accept cf push of apps? Thank you very much for your support. Regards Nithiyasri From: Amit Gupta [mailto:agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>] Sent: Tuesday, March 08, 2016 3:43 AM To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Cc: Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>>; Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> Subject: Re: Reg the minimal-openstack yml files You need some static IPs, because some components don't use service discovery, so clients need to be configured up front to know those components' IPs. For example, the route-registrar jobs talk to the NATS cluster to register routes for CC, HM9k, UAA, and Doppler. NATS servers must be assigned static IPs in the manifest and components like route-registrar that talk to NATS need to have those IPs provided in their config in the manifest. This current requirement on static IPs exists for some other components as well. Some other components however would be fine with dynamic networking. A private vendor may be able to work with you to manage a Cloud Foundry installation that suits your networking requirements, but said guidance is beyond the scope of this mailing list. The deployments that the Foundation tests continuously use static IPs for simplicity. Cheers, Amit On Monday, March 7, 2016, Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com<mailto:jayark(a)cisco.com>> wrote: Thanks Amit! A minor correction in our case. We are not using static IP. We are only using dynamic IP. None of the Cloud Foundry components are using Floating IP. What is Pivotal recommendation for the networking? Is it static or dynamic? Given that we are using dynamic IPs, do you foresee any issues with our current approach to generate the manifest for CF-229? Regards Jayaraj From: Amit Gupta <agupta(a)pivotal.io<mailto:agupta(a)pivotal.io>> Date: Monday, March 7, 2016 at 12:24 PM To: "Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)" <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> Cc: Rohit Kumar <rokumar(a)pivotal.io<mailto:rokumar(a)pivotal.io>>, Jayarajan Ramapurath Kozhummal <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>> Subject: Re: Reg the minimal-openstack yml files We're not likely to be able to create and maintain a new minimal manifest any time soon. As for generating the manifest, you can look at these docs for what needs to go into the OpenStack stub as of the latest release: http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html Combining this with updating your current template guided by the errors is a good way to generate the manifest. This is not guaranteed to work for 100% of use cases, e.g. if you want to use all floating IPs instead of static IPs. But it is a good starting point. Cheers, Amit On Mon, Mar 7, 2016 at 4:09 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote: Hi We are trying to upgrade our deployment with the latest cloud-foundry, from 205 to 230 release, as per your advice. We could see minimal-aws.yml available in the GIT repo. Can we have a similar one available for openstack environment, with which we can deploy the basic cloud foundry and do our custom changes on top of it Parallely we are updating our stub to match the template yml files guided by the errors given by the generate_deployment_manifest script. Kindly let us know if this is the correct way to generate the manifest. Regards Nithiyasri |
|
|
|
Amit Kumar Gupta
That's fantastic! Great to hear DNS hostname worked well for you, as
supporting it is a new feature in consul-release, so it's good to hear it's working "in the wild". Best, Amit On Tue, Mar 15, 2016 at 8:15 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote: Hi Amit |
|
|