|
Re: Allow gorouter to log random headers.
Simon Johansson <simon@...>
WAKAWAKA is just an example
toggle quoted messageShow quoted text
But the difference is that WAKAWAKA is not platform specific whereas X-Cf-Requestid is. If we want to move our app to Heroku, or a VM, or whatewher we have platform specific implementation details in our app(namely we rely on a header that is not there anymore). But that is not the point of this thread. The point is, say we have an app that is fronted by a CDN, and the CDN sets the X-Im-a-shark header with some value that we are interested to see in our logs. The easiest way to achivie this without having to implement it into our own apps is just to tell the Gorouter that it should append the value of that header into the string that it logs so the event that flow via Doppler and ultimately into cf logs/ELK will contain that value. The reason why this would be such a valuable feature for us is that we dont have to do anything. CF already provide the out of the box facility to give us routing logs, so if we can piggy back on that for what we are interested in we dont have to add libraries to our apps to log interesting headers on the side.
On Wed, Jul 22, 2015 at 12:45 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
I don't see the difference between WAKAWAKA and X-Cf-Requestid. Gorouter
|
|
|
|
Assigning Role to Group
Zakharov Alexey <alexey.zakharov@...>
Hi guys!Have you looked at the `uaac` tool? I'm not quite sure I understand what you're trying to do, but you can map an LDAP group DN to a UAA group with `uaac`. Then if a user in that LDAP group logs in, they'll have that uaa group. Is that what you're looking to do? Ex: uaac group map --name cloud_controller.admin "GROUP-DISTINGUISHED-NAME" Or are you asking about mapping LDAP groups to CF org & space roles? i.e. user in ldap group X is automatically given the OrgManager role in org Y. Dan Hi Dan! Yes, as I’ve stated before, I’ve already managed to configure group mappings using ‘uaac group map’. And now I want to bind group members to Organizations and Spaces. Is it possible to do? --- Alexey Zakharov | CloudFoundry Team | Altoros Tel: (617) 841-2121 ext. 5704 | Toll free: 855-ALTOROS Fax: (866) 201-3646 | Skype: alexey.zakharov.a www.altoros.com<http://www.altoros.com> | blog.altoros.com<http://blog.altoros.com> | twitter.com/altoros<http://twitter.com/altoros>
|
|
|
|
Re: Did anybody deploy a wiki as app to CF?
Dieu Cao <dcao@...>
Very cool!
toggle quoted messageShow quoted text
On Tue, Jul 21, 2015 at 8:16 PM, Cornelia Davis <cdavis(a)pivotal.io> wrote:
What Josh said!! WOW!
|
|
|
|
Re: Did anybody deploy a wiki as app to CF?
Cornelia Davis <cdavis@...>
What Josh said!! WOW!
toggle quoted messageShow quoted text
On Tue, Jul 21, 2015 at 6:53 PM, Josh Long <starbuxman(a)gmail.com> wrote:
WOW!
|
|
|
|
Re: UAA integrate with ADFS
Gwenn Etourneau
I am guessing a problem in your yaml file and the spring profile shoud
toggle quoted messageShow quoted text
be 'saml,default,fileMetadata' for saml no ? But I am not sure about the exact format
On Wed, Jul 22, 2015 at 8:28 AM, Zhang, Yuan <Yuan.Zhang(a)emc.com> wrote:
Hi,
|
|
|
|
Re: Did anybody deploy a wiki as app to CF?
Josh Long <starbuxman@...>
WOW!
toggle quoted messageShow quoted text
-- Thanks, Josh Long the Spring Developer Advocate, Pivotal http://joshlong.com || http://twitter.com/starbuxman || http://spring.io/team/jlong
On July 21, 2015 at 5:44:50 PM, Noburou TANIGUCHI (dev(a)nota.m001.jp) wrote:
cloudfoundry.gr.jp, a Cloud Foundry user group in Japan, is currently running a project (or a campaign, more properly) called "Cloud Foundry 100-day challenge" ("Cloud Foundry 100-nichi Gyou" in Japanese. "gyou" originally means a kind of discipline or training in Buddhism). It is an activity to make 100 open source apps run on Cloud Foundry, one app per day. http://blog.cloudfoundry.gr.jp/search/label/%E7%99%BE%E6%97%A5%E8%A1%8C We have done 33 apps until now. We are sorry the all articles are presented only in Japanese. Do they help your project, James? -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Did-anybody-deploy-a-wiki-as-app-to-CF-tp643p808.html Sent from the CF Dev mailing list archive at Nabble.com. _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
|
Re: 3 etcd nodes don't work well in single zone
Amit Kumar Gupta
Hi Tony,
toggle quoted messageShow quoted text
The logs you've retrieved only go back to Jul 21, which I can't correlate with the "?/2" issues you were seeing. If you could possibly record again a bunch of occurrences of flapping between "2/2" and "?/2" for an app (along with datetime stamps), and then immediately get logs from *all* the HM and etcd nodes (`bosh logs` only gets logs from one node at a time), I can try to dig in more. It's important to get the logs from the HM and etcd VMs soon after recording the "?/2" events, otherwise BOSH may rotate/archive the logs and then make them harder to obtain. Best, Amit
On Tue, Jul 21, 2015 at 4:53 PM, Amit Gupta <agupta(a)pivotal.io> wrote:
You should definitely not run etcd with 2 instances. You can read more
|
|
|
|
Re: 3 etcd nodes don't work well in single zone
Amit Kumar Gupta
You should definitely not run etcd with 2 instances. You can read more about
recommended cluster sizes in the etcd docs: https://github.com/coreos/etcd/blob/740187f199a12652ca1b7bddb7b3489160103d84/Documentation/admin_guide.md#fault-tolerance-table I will look at the attached logs and get back to you, but wanted to make sure to advise you to run either 1 or 3 nodes. With 2, you can wedge the system, because it will need all nodes to be up to achieve quorum. If you roll one of the two nodes, it will not be able to rejoin the cluster, and the service will be stuck in an unavailable state. ----- Amit, CF OSS Release Integration PM Pivotal Software, Inc. -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p809.html Sent from the CF Dev mailing list archive at Nabble.com.
|
|
|
|
Re: Did anybody deploy a wiki as app to CF?
Noburou TANIGUCHI
cloudfoundry.gr.jp, a Cloud Foundry user group in Japan, is currently running
a project (or a campaign, more properly) called "Cloud Foundry 100-day challenge" ("Cloud Foundry 100-nichi Gyou" in Japanese. "gyou" originally means a kind of discipline or training in Buddhism). It is an activity to make 100 open source apps run on Cloud Foundry, one app per day. http://blog.cloudfoundry.gr.jp/search/label/%E7%99%BE%E6%97%A5%E8%A1%8C We have done 33 apps until now. We are sorry the all articles are presented only in Japanese. Do they help your project, James? -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Did-anybody-deploy-a-wiki-as-app-to-CF-tp643p808.html Sent from the CF Dev mailing list archive at Nabble.com.
|
|
|
|
Re: Introducing OSS Release Integration Team
Amit Kumar Gupta
No problem, more than happy to clarify!
toggle quoted messageShow quoted text
Amit
On Tue, Jul 21, 2015 at 4:03 PM, Noburou TANIGUCHI <dev(a)nota.m001.jp> wrote:
Thank you for the scrupulous answer, Amit.
|
|
|
|
UAA integrate with ADFS
Tina Zhang
Hi,
We have cloud foundry v197 env wants to integrate UAA server with existing ADFS. But uaa server not working properly when changing uaa.yml from spring_profiles: postgresql to spring_profiles: default. We want to know the steps to integrate UAA with MS ADFS. We have modified uaa server as following: 1. uaa.yml, change spring_profiles: postgresql to spring_profiles: default name: uaa database: url: jdbc:postgresql://10.8.52.65:5524/uaadb username: uaaadmin password: "c1oudc0w" spring_profiles: default #spring_profiles: postgresql logging: config: /var/vcap/jobs/uaa/config/log4j.properties ... 2. in login.yml, adding saml: entityID: https://XXXX/adfs/services/trust nameID: 'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified' assertionConsumerIndex: 0 signMetaData: true signRequest: true socket: connectionManagerTimeout: 10000 soTimeout: 10000 providers: openam-local: idpMetadata: https:// XXXX/FederationMetadata/2007 -06/FederationMetadata.xml nameID: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress assertionConsumerIndex: 0 signMetaData: false signRequest: false showSamlLoginLink: true Error from uaa.log as following, change spring_profiles: postgresql to default causes openid cannot be identified. [2015-07-21 22:42:46.001] uaa - 9927 [localhost-startStop-1] .... ERROR --- YamlConfigurationValidator: Failed to load YAML validation bean. Your YAML file may be invalid. Can't construct a java object for tag:yaml.org,2002:org.cloudfoundry.identity.uaa.UaaConfiguration; exception=Cannot create property=oauth for JavaBean=org.cloudfoundry.identity.uaa.UaaConfiguration(a)38ad5581; Cannot create property=openid for JavaBean=org.cloudfoundry.identity.uaa.UaaConfiguration$OAuth(a)40615f24; Unable to find property 'openid' on class: org.cloudfoundry.identity.uaa.UaaConfiguration$OAuth in 'string', line 1, column 1: oauth: ^ What are steps to integrate cloud foundry UAA server to MS ADFS? Thanks, Tina Zhang
|
|
|
|
Re: Introducing OSS Release Integration Team
Noburou TANIGUCHI
Thank you for the scrupulous answer, Amit.
(I apologize this late response) -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Introducing-OSS-Release-Integration-Team-tp757p805.html Sent from the CF Dev mailing list archive at Nabble.com.
|
|
|
|
Re: Allow gorouter to log random headers.
Shannon Coen
I don't see the difference between WAKAWAKA and X-Cf-Requestid. Gorouter
would have to add some header with a uuid for the request. Your apps have to have logic to pass this header on, so that a log search returns the original request as well as subsequent requests between apps. Could you please clarify? Thank you, Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Tue, Jul 21, 2015 at 11:09 AM, Simon Johansson <simon(a)simonjohansson.com> wrote: Sure that header can be used. But then we are adding CF specific stuff
|
|
|
|
Re: Allow gorouter to log random headers.
Simon Johansson <simon@...>
Sure that header can be used. But then we are adding CF specific stuff into
toggle quoted messageShow quoted text
the implementation of our services, which is something we want to avoid at all costs. Also Im not entirely sure if all the libraries we use for Zipkin supports using custom headers. All our public apps are fronted by different CDNs, which sets headers that we might want to store for debugging, so we still need a way to pass those trough into the log.
On Tuesday, 21 July 2015, Shannon Coen <scoen(a)pivotal.io> wrote:
Hello Simon,
|
|
|
|
Re: Allow gorouter to log random headers.
Shannon Coen
Hello Simon,
The X-Cf-Requestid header already provides a uuid. Couldn't app "a" add the value of X-Cf-Requestid to a header of your choosing? Call it WAKAWAKA or X-Random-Header, but it doesn't need to be a platform standard. Wouldn't a search for the value of X-Cf-Requestid then provide the desired results? Thank you, Shannon Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Tue, Jul 21, 2015 at 6:06 AM, Simon Johansson <simon(a)simonjohansson.com> wrote: Howdie!
|
|
|
|
Re: Diego log grouping
MJ
The CF messages ingest OK into Splunk; None of the Diego messages ingest, not even the first line of their payload.
The problematic deployment: · CF v212 · Stemcell 3012 (bosh-stemcell-3012-vsphere-esxi-ubuntu-trusty-go_agent.tgz) · Diego 1304 An single CF syslog message payload: 2015-07-21T00:26:51.619730+00:00 10.5.139.228 vcap.hm9000.listener [job=hm9000_z1 index=1] {"timestamp":1437438411.619571447,"process_id":9750,"source":"vcap.hm9000.listener","log_level":"info","message":"Saved Heartbeats - {\"Duration\":\"217.887334ms\",\"Heartbeats to Save\":\"3\"}","data":null} An single Diego syslog message payload: 2015-07-21T00:27:02.389177+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.389095783","source":"receptor","message":"receptor.task-handler.get-all.succeeded-fetching-tasks-from-store","log_level":1,"data":{"domain":"","session":"3.3949"}} <13>2015-07-21T00:27:02.389399+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.389337301","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/tasks","session":"20204"}} <13>2015-07-21T00:27:02.389982+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.389916658","source":"receptor","message":"receptor.request.serving","log_level":1,"data":{"method":"GET","request":"/v1/desired_lrps","session":"20205"}} <13>2015-07-21T00:27:02.620949+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.620829105","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/desired_lrps","session":"20205"}} <13>2015-07-21T00:27:02.621660+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438422.621593714","source":"receptor","message":"receptor.request.serving","log_level":1,"data":{"method":"GET","request":"/v1/actual_lrps","session":"20206"}} <13>2015-07-21T00:27:03.145810+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438423.145678282","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/actual_lrps","session":"20206"}} <13>2015-07-21T00:27:03.146939+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438423.146871328","source":"receptor","message":"receptor.request.serving","log_level":1,"data":{"method":"GET","request":"/v1/domains","session":"20207"}} <13>2015-07-21T00:27:03.192371+00:00 10.5.139.241 vcap.receptor [job=cell_z1 index=1] {"timestamp":"1437438423.192266226","source":"receptor","message":"receptor.request.done","log_level":1,"data":{"method":"GET","request":"/v1/domains","session":"20207"}} <12>2015-07-21T00:27:03.692338+00:00 10.5.139.241 vmsvc [job=cell_z1 index=1] [ warning] [guestinfo] Failed to get vmstats. <13>2015-07-21T00:27:03.936841+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.935924530","source":"rep","message":"rep.running-bulker.sync.starting","log_level":1,"data":{"session":"11.7938"}} <13>2015-07-21T00:27:03.937079+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.936018705","source":"rep","message":"rep.running-bulker.sync.batch-operations.started","log_level":1,"data":{"session":"11.7938.1"}} <13>2015-07-21T00:27:03.937110+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.936035156","source":"rep","message":"rep.running-bulker.sync.batch-operations.getting-containers-lrps-and-tasks","log_level":1,"data":{"session":"11.7938.1"}} <13>2015-07-21T00:27:03.937132+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.936167717","source":"rep","message":"rep.running-bulker.sync.batch-operations.fetching-tasks-from-store","log_level":1,"data":{"session":"11.7938.1"}} <13>2015-07-21T00:27:03.968190+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438423.968116999","source":"rep","message":"rep.running-bulker.sync.batch-operations.succeeded-fetching-tasks-from-store","log_level":1,"data":{"session":"11.7938.1"}} <13>2015-07-21T00:27:06.495263+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438426.495136499","source":"rep","message":"rep.running-bulker.sync.batch-operations.succeeded-getting-containers-lrps-and-tasks","log_level":1,"data":{"session":"11.7938.1"}} <13>2015-07-21T00:27:06.495341+00:00 10.5.139.241 vcap.rep [job=cell_z1 index=1] {"timestamp":"1437438426.495275497","source":"rep","message":"rep.running-bulker.sync.batch-operations.succeeded","log_level":1,"data":{"batch-size":0,"session":"11.7938.1"}} Another (single) Diego syslog message payload: 2015-07-21T00:27:10.310490+00:00 10.5.139.246 vcap.route-emitter [job=route_emitter_z1 index=0] {"timestamp":"1437438430.310252428","source":"route-emitter","message":"route-emitter.watcher.sync.emitting-messages","log_level":1,"data":{"messages":{"RegistrationMessages":null,"UnregistrationMessages":null},"session":"5.10080"}} <13>2015-07-21T00:27:10.312037+00:00 10.5.139.246 vcap.route-emitter [job=route_emitter_z1 index=0] {"timestamp":"1437438430.311890841","source":"route-emitter","message":"route-emitter.watcher.sync.complete","log_level":1,"data":{"session":"5.10080"}} <12>2015-07-21T00:27:11.049315+00:00 10.5.139.246 vmsvc [job=route_emitter_z1 index=0] [ warning] [guestinfo] Failed to get vmstats. -Mike From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Eric Malm Sent: Tuesday, July 21, 2015 12:01 AM To: Discussions about Cloud Foundry projects and the system overall. Subject: Re: [cf-dev] Diego log grouping Hi, Mike, Thanks for the report! From your packet captures or on-VM logs, do you have an example of the log line groups that Splunk is failing to ingest? Is it all the log lines, or just ones coming from particular Diego components? The github.com/tedsuo/ifrit<http://github.com/tedsuo/ifrit> dependency hasn't changed in diego-release between 1099 and 1304, but it's possible that our use of it in diego-release has. Likewise, the github.com/pivotal-golang/lager<http://github.com/pivotal-golang/lager> package that's emitting logs has changed in only trivial ways between those releases. We have upgraded the release to use Go 1.4.2 instead of 1.4, though. Also, what stemcell versions are you using in the deployments? I'm assuming that if CF is deployed alongside these Diego deployments, it's at the corresponding recommended final version (v207 and v212, respectively). If so, are there any problems with the syslog messages coming from those deployments? Thanks, Eric, CF Runtime Diego PM On Mon, Jul 20, 2015 at 6:51 PM, Mike Jacobi <jacobi(a)adobe.com<mailto:jacobi(a)adobe.com>> wrote: We have a Diego 1099 deployment and syslog_daemon_config configured. We see a 1:1 mapping for Diego platform messages to syslog messages. In other words, for each syslog message that hits the wire, there is one platform message as its payload. This works well with Splunk, which is ultimately where the messages end up. We have another deployment, but on Diego 1304, with its syslog_daemon_config identical to the other, but Splunk is *not* ingesting its logs. We ran a packet capture and discovered that this deployment is grouping its log messages in a 1:n manner: For each syslog message on the wire, we have multiple platform messages within, separated by newlines. I suspect this is the reason the logs aren’t being ingested. I took a quick glance at the code and it seems like this might be due to ifrit/grouper, but I can’t say for sure. Has anyone run into this issue? Thanks, Mike _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
|
Allow gorouter to log random headers.
Simon Johansson <simon@...>
Howdie!
We have some devs who want to be able to trace a request troughout their applications. user -> a -> b -> c | |-> d -> e When a user makes a request to "a" uuid is generated inside the app, and the request to "b" from "a" will set a header(call it WAKAWAKA to uuid), "b"'s call will passthrough WAKAWAKA to "c" and "d", "d" will passthrough WAKAWAKA to "e". Etc. We aggregate all RTR logs into ELK so it would be super helpful to them to be able to filter on WAKAWAKA and get all the access logs(and app logs aswell, they mostly use GELF so its easy for them to add whatewher field they want) from the services involved. I had a quick peek at the gorouter( https://github.com/cloudfoundry/gorouter/blob/76668f5818ea8c089ff52a14fcdfbf703c8e8767/access_log/access_log_record.go#L40) and it seems like this should be a simple PR. 1. To gorouter.yml add passthrough_headers: - WAKAWAKA - X-Random-Header 2. In makeRecord at the bottom add something like(in psuedo) data = {} for header in passthrough_headers: header_val = r.FormatRequestHeader("X-Forwarded-For") if header_val: passthrough_headers[header] = header_val if data: fmt.Fprintf(b, data.to_stringified_json()) That would yield a log line like blurgh.dev.cf.private.domain.com - [21/07/2015:10:17:05 +0000] "GET /statements?ascending=true&since=2015-06-30T14%3A10%3A03.078Z&skipStatementId=30a88204-0779-4385-9859-e4aabd30baf0 HTTP/1.1" 200 0 17 "-" "NING/1.0" 10.230.31.2:46204 x_forwarded_for:"-" vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08 {"WAKAWAKA": "Space is the place", "X-Random-Header": "Once upon a midnight dreary, while I pondered weak and weary"} The reason for a stringified JSON is to make it easy to parse with logstash or other loganalysis tools. Before I spend time implementing, is this something you would merge?
|
|
|
|
Re: revrse proxy in CF
Felix Friedrich
Thanks, it works now!
toggle quoted messageShow quoted text
Felix
On Tue, Jul 21, 2015, at 10:21 AM, Dieu Cao wrote:
That's odd. I've fixed the link so it should be readable/commentable
|
|
|
|
Re: revrse proxy in CF
Dieu Cao <dcao@...>
That's odd. I've fixed the link so it should be readable/commentable again.
toggle quoted messageShow quoted text
-Dieu CF CAPI PM
On Tue, Jul 21, 2015 at 12:59 AM, Felix Friedrich <felix(a)fri.edri.ch> wrote:
Hello,
|
|
|
|
Re: 3 etcd nodes don't work well in single zone
Tony
Hi Amit,
It’s me again. Could you please see log files in the attachment? We got these errors: Etcd: ./etcd/etcd.stderr.log: etcdhttp: unexpected error: etcdserver: request timed out (but it might be not a bug according to https://github.com/coreos/etcd/issues/3133) Hm9000 ./hm9000/hm9000_analyzer.log , hm9000_apiserver.log and hm9000_sender.log "error","message":"Store is not fresh - Error:Actual state is not fresh" Today we tried to run it with 2 etcd instances but not 3, to detect the problem more clearly. Also, we tried to change properties of etcd: properties: … etcd: election_timeout_in_milliseconds: 3000 (also tried 5000) heartbeat_interval_in_milliseconds: 50 (also tried 500, 1000) log_sync_timeout_in_seconds: 30 It seems that heartbeat_interval_in_milliseconds works (got ?/2 about 4 times as many as 2/2, when it is 50, and Got ?/2 about 1.7 times as many as 2/2, when it is 1000). We may try 2000 or 3000 tomorrow though we think it is too big compared with the default value 50. Do you have any idea about it? Thanks, Tony Li From: Tony [via CF Dev] [mailto:ml-node+s70369n788h4(a)n6.nabble.com] Sent: Tuesday, 21 July 2015 9:54 AM To: Li, Tony Subject: Re: [cf-dev] 3 etcd nodes don't work well in single zone Hi Amit, Thanks for your reply. Yes, we still get stuck here. And let's me introduce George who is checking this issue in detail. He will send log and report with more details to you soon. BTW, We know how to get logs from bosh vms. Thank you very much. Regards, Tony ________________________________ If you reply to this email, your message will be added to the discussion below: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p788.html To unsubscribe from [cf-dev] 3 etcd nodes don't work well in single zone, click here<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=746&code=VG9ueWxAZmFzdC5hdS5mdWppdHN1LmNvbXw3NDZ8LTQ5MjU5Njk1Nw==>. NAML<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 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 logs.zip (47K) <http://cf-dev.70369.x6.nabble.com/attachment/797/0/logs.zip> -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-3-etcd-nodes-don-t-work-well-in-single-zone-tp746p797.html Sent from the CF Dev mailing list archive at Nabble.com.
|
|
|