Re: Reg the minimal-openstack yml files


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:



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> 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 thread
https://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> 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>
*Date: *Monday, March 7, 2016 at 12:24 PM
*To: *"Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at
Cisco)" <ngnanase(a)cisco.com>
*Cc: *Rohit Kumar <rokumar(a)pivotal.io>, Jayarajan Ramapurath Kozhummal <
jayark(a)cisco.com>, "Discussions about Cloud Foundry projects and the
system overall." <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> 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




Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.