Hi Adrian,
Thanks for your comment. I do have consul server in my cf-release deployment.
Currently it’s database_z2/0 that is failing, however if I stop all running etcds on database_z1 and database_z2 and then start it first on database_z2, it works. On the other hand, after the etcd in database_z2 works, the etcd in database_z1 wouldn’t start, so it seems that only 1 etcd can be run.
+---------------------------------------------------------------------------+---------+-----+-----------+---------------+
| VM | State | AZ | VM Type | IPs |
+---------------------------------------------------------------------------+---------+-----+-----------+---------------+
| api_z1/0 (aef6e8d4-e088-420c-89f8-c74c4be0f3c6) | running | n/a | large_z1 | 192.168.1.6 |
| consul_z1/0 (8b1972db-1a24-414a-a40b-924f0d880fda) | running | n/a | small_z1 | 192.168.1.22 |
| doppler_z1/0 (1f044051-be96-4235-bd74-21093156136e) | running | n/a | medium_z1 | 192.168.1.31 |
| etcd_z1/0 (fde0895e-39dc-4826-8f29-be6ef5bb9ee5) | running | n/a | medium_z1 | 192.168.1.18 |
| ha_proxy_z1/0 (20d2a2b4-4c57-4fc4-8f99-0a365fbc8246) | running | n/a | router_z1 | 192.168.1.10 |
| | | | | 137.172.74.81 |
| hm9000_z1/0 (0f124588-7dd0-4351-b606-42630e8bc300) | running | n/a | medium_z1 | 192.168.1.7 |
| loggregator_trafficcontroller_z1/0 (e904e07f-2877-421d-8336-65f8422c4592) | running | n/a | small_z1 | 192.168.1.32 |
| loggregator_z1/0 (28a5d336-9f5f-45a8-b427-73be37a1f37d) | running | n/a | medium_z1 | 192.168.1.9 |
| nats_z1/0 (6a56ebca-a1bb-4192-beb7-86f4ac11b3ca) | running | n/a | medium_z1 | 192.168.1.12 |
| nfs_z1/0 (876a10c2-212e-49a5-913e-2fcce0c215a6) | running | n/a | medium_z1 | 192.168.1.13 |
| router_z1/0 (1fafd912-7357-4d12-8bbd-fedc10f47d40) | running | n/a | router_z1 | 192.168.1.15 |
| runner_z1/0 (d80862bb-f3b9-43da-ab55-fc0af3f5b569) | running | n/a | runner_z1 | 192.168.1.8 |
| stats_z1/0 (2ab128db-8efc-4c2b-98fb-673b0ebaaba4) | running | n/a | small_z1 | 192.168.1.4 |
| uaa_z1/0 (76800329-ad05-442a-a18d-79cb98abec27) | running | n/a | medium_z1 | 192.168.1.5 |
+---------------------------------------------------------------------------+---------+-----+-----------+---------------+
+-----------------------------------------------------------+---------+-----+------------------+--------------+
| VM | State | AZ | VM Type | IPs |
+-----------------------------------------------------------+---------+-----+------------------+--------------+
| access_z1/0 (598f16db-60c2-4c13-bcec-85ae2a38102d) | running | n/a | access_z1 | 192.168.3.44 |
| access_z2/0 (a83d049d-6c95-417e-84f4-9aced8a9136f) | running | n/a | access_z2 | 192.168.4.56 |
| brain_z1/0 (a95c56bb-a84d-41b4-91b1-ade57c773dbe) | running | n/a | brain_z1 | 192.168.3.40 |
| brain_z2/0 (eb386b16-c8e4-4c04-9582-20f4161f6e03) | running | n/a | brain_z2 | 192.168.4.52 |
| cc_bridge_z1/0 (b9870145-26d7-4e59-9358-97c43db6a110) | running | n/a | cc_bridge_z1 | 192.168.3.42 |
| cc_bridge_z2/0 (7477b06f-e501-4757-abda-8e29c7c15464) | running | n/a | cc_bridge_z2 | 192.168.4.54 |
| cell_z1/0 (a6ef0a8c-52c0-4bd2-abfb-2fcf0101dd24) | running | n/a | cell_z1 | 192.168.3.41 |
| cell_z2/0 (36f012e3-2013-44aa-9a92-18161d6854ad) | running | n/a | cell_z2 | 192.168.4.53 |
| database_z1/0 (5428cca8-9832-42f4-9b3a-a822eb6d7e96) | running | n/a | database_z1 | 192.168.3.39 |
| database_z2/0 (16c88d30-fe70-4d42-8307-34cc85521ca7) | failing | n/a | database_z2 | 192.168.4.51 |
| database_z3/0 (c802162f-0681-479e-bb9c-98dac7d78941) | running | n/a | database_z3 | 192.168.5.31 |
| route_emitter_z1/0 (f7f7a8f3-9784-4b99-b0a5-6efb4d193cf5) | running | n/a | route_emitter_z1 | 192.168.3.43 |
| route_emitter_z2/0 (7f4e7fb7-7986-432e-a2e3-b298d3070753) | running | n/a | route_emitter_z2 | 192.168.4.55 |
+-----------------------------------------------------------+---------+-----+------------------+--------------+
Regards,
Ricky
From: Amit Gupta [mailto:agupta(a)pivotal.io]
Sent: Tuesday, 29 March 2016 4:30 AM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Failed to deploy diego 0.1452.0 on openstack: database_z2/0 is not running after update
The consul server cluster will be part of the cf-release deployment. This Diego deployment will be talking to the consul server cluster in the cf-release deployment.
On Mon, Mar 28, 2016 at 10:20 AM, Adrian Zankich <azankich(a)pivotal.io<mailto:azankich(a)pivotal.io>> wrote:
Hello Ricky,
I see that you're trying to run etcd in SSL mode, but I do not see a consul server instance in your instance list. Are you deploying a consul server job?
- Adrian
Disclaimer
The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.
Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.
If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe(a)fast.au.fujitsu.com
