Vault write is successful, but unable to find data when queried for the same.

890 views
Skip to first unread message

Bharath B

unread,
May 17, 2018, 6:44:14 AM5/17/18
to Vault
Hello Team,

        We have deployed vault + consul, with 2 vault instances and 3 consul instances. When we do vault write using equivalent GO API, it's successful, but when we query for the same using vault list, unable to find the data written.

       Deployed environment details:
               - OS : Red Hat Enterprise Linux Server release 7.4 (Maipo)
               - Vault : Vault v0.9.3 ('5c86ddcbb7854365f62ce1231846c1c24fb8675a+CHANGES')
               - Consul : Consul v1.0.6

       Below steps were performed before mentioned issue was observed:
               - Start all 3 consul instances
               - Check is consul leader is chosen
               - Start 2 vault instances
               - Init and unseal from vault instance 1
               - Unseal vault instance 2
               - Check vault leader is chosen
               - Write data to vault
               - List data in vault

        consul instance 1 logs:

        consul instance 2 logs:

        consul instance 3 logs:

        vault instance 1 logs:
2018/05/15 16:13:39.493898 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:39.520097 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:39.821918 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:39.883150 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.047783 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.058892 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.204434 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.224893 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.395825 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.421182 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.550948 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.562523 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.781571 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.820538 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.908266 [DEBUG] forwarding: error sending echo request to active node: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:41.138147 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:41.165794 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:41.509211 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:41.525078 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
        vault instance 2 logs:

Message has been deleted

Bharath B

unread,
May 17, 2018, 10:16:02 AM5/17/18
to Vault
Hello Team,

       We have deployed vault + consul, with 2 vault instances and 3 consul instances. When we do vault write using equivalent GO API, it's successful, but when we query for the same using vault list, unable to find the data written.

       Deployed environment details:
               - OS : Red Hat Enterprise Linux Server release 7.4 (Maipo)
               - Vault : Vault v0.9.3 ('5c86ddcbb7854365f62ce1231846c1c24fb8675a+CHANGES')
               - Consul : Consul v1.0.6

       Below steps were performed before mentioned issue was observed:
               - Start all 3 consul instances
               - Check is consul leader is chosen
               - Start 2 vault instances
               - Init and unseal from vault instance 1
               - Unseal vault instance 2
               - Check vault leader is chosen
               - Write data to vault
               - List data in vault

        consul instance 1 logs(x.x.x.x):
        May 15 16:13:10 repo1 consul[20266]: 2018/05/15 16:13:10 [WARN] memberlist: Was able to connect to repo2 but other probes failed, network may be misconfigured
May 15 16:13:11 repo1 consul[20266]: 2018/05/15 16:13:11 [WARN] memberlist: Was able to connect to repo2.imsxxxx but other probes failed, network may be misconfigured
May 15 16:13:15 repo1 consul[20266]: 2018/05/15 16:13:15 [DEBUG] raft-net: x.x.x.x:5825 accepted connection from: y.y.y.y:25656
May 15 16:13:15 repo1 consul[20266]: 2018/05/15 16:13:15 [INFO] raft: Node at x.x.x.x:5825 [Follower] entering Follower state (Leader: "")
May 15 16:13:15 repo1 consul[20266]: 2018/05/15 16:13:15 [INFO] consul: New leader elected: repo2
May 15 16:13:16 repo1 consul[20266]: 2018/05/15 16:13:16 [DEBUG] raft-net: x.x.x.x:5825 accepted connection from: y.y.y.y:29296
May 15 16:13:16 repo1 consul[20266]: 2018/05/15 16:13:16 [INFO] serf: attempting reconnect to vconsul_float.imsxxxx z.z.z.z:5824
May 15 16:13:16 repo1 consul[20266]: 2018/05/15 16:13:16 [INFO] serf: attempting reconnect to vconsul_float z.z.z.z:5823
May 15 16:13:16 repo1 consul[20266]: 2018/05/15 16:13:16 [INFO] agent: Synced node info
May 15 16:13:17 repo1 consul[20266]: 2018/05/15 16:13:17 [INFO] agent: Synced service "vault:x.x.x.x:5819"
May 15 16:13:17 repo1 consul[20266]: 2018/05/15 16:13:17 [INFO] agent: Synced check "vault:x.x.x.x:5819:vault-sealed-check"
May 15 16:13:20 repo1 consul[20266]: 2018/05/15 16:13:20 [INFO] agent: Synced check "vault:x.x.x.x:5819:vault-sealed-check"
May 15 16:13:46 repo1 consul[20266]: 2018/05/15 16:13:46 [INFO] serf: attempting reconnect to vconsul_float.imsxxxx z.z.z.z:5824
May 15 16:13:48 repo1 consul[20266]: 2018/05/15 16:13:48 [INFO] agent: Deregistered service "vault:x.x.x.x:5819"
May 15 16:13:48 repo1 consul[20266]: 2018/05/15 16:13:48 [INFO] agent: Deregistered check "vault:x.x.x.x:5819:vault-sealed-check"
May 15 16:13:58 repo1 consul[20266]: 2018/05/15 16:13:58 [INFO] agent: Synced service "vault:x.x.x.x:5819"
May 15 16:13:58 repo1 consul[20266]: 2018/05/15 16:13:58 [INFO] agent: Synced check "vault:x.x.x.x:5819:vault-sealed-check"
May 15 16:14:02 repo1 consul[20266]: 2018/05/15 16:14:02 [INFO] agent: Synced check "vault:x.x.x.x:5819:vault-sealed-check"
May 15 16:14:02 repo1 consul[20266]: 2018/05/15 16:14:02 [INFO] agent: Synced service "vault:x.x.x.x:5819"
May 15 16:14:02 repo1 consul[20266]: 2018/05/15 16:14:02 [INFO] agent: Synced check "vault:x.x.x.x:5819:vault-sealed-check"
May 15 16:14:16 repo1 consul[20266]: 2018/05/15 16:14:16 [INFO] serf: attempting reconnect to vconsul_float z.z.z.z:5823
May 15 16:14:46 repo1 consul[20266]: 2018/05/15 16:14:46 [INFO] serf: attempting reconnect to vconsul_float z.z.z.z:5823
May 15 16:15:16 repo1 consul[20266]: 2018/05/15 16:15:16 [INFO] serf: attempting reconnect to vconsul_float.imsxxxx z.z.z.z:5824
May 15 16:15:16 repo1 consul[20266]: 2018/05/15 16:15:16 [INFO] serf: attempting reconnect to vconsul_float z.z.z.z:5823

        consul instance 2 logs(y.y.y.y):
        May 15 16:13:25 repo2 consul[13626]: 2018/05/15 16:13:25 [ERR] raft: Failed to heartbeat to z.z.z.z:5825: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused
May 15 16:13:26 repo2 consul[13626]: 2018/05/15 16:13:26 [WARN] Unable to get address for server id f8591287-efee-97bb-95c0-2ecd39616cb5, using fallback address z.z.z.z:5825: Could not find address for server id f8591287-efee-97bb-95c0-2ecd39616cb5
May 15 16:13:26 repo2 consul[13626]: 2018/05/15 16:13:26 [ERR] raft: Failed to AppendEntries to {Voter f8591287-efee-97bb-95c0-2ecd39616cb5 z.z.z.z:5825}: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused
May 15 16:13:30 repo2 consul[13626]: 2018/05/15 16:13:30 [WARN] Unable to get address for server id f8591287-efee-97bb-95c0-2ecd39616cb5, using fallback address z.z.z.z:5825: Could not find address for server id f8591287-efee-97bb-95c0-2ecd39616cb5
May 15 16:13:30 repo2 consul[13626]: 2018/05/15 16:13:30 [ERR] raft: Failed to heartbeat to z.z.z.z:5825: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused
May 15 16:13:36 repo2 consul[13626]: 2018/05/15 16:13:36 [WARN] Unable to get address for server id f8591287-efee-97bb-95c0-2ecd39616cb5, using fallback address z.z.z.z:5825: Could not find address for server id f8591287-efee-97bb-95c0-2ecd39616cb5
May 15 16:13:36 repo2 consul[13626]: 2018/05/15 16:13:36 [ERR] raft: Failed to AppendEntries to {Voter f8591287-efee-97bb-95c0-2ecd39616cb5 z.z.z.z:5825}: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused
May 15 16:13:40 repo2 consul[13626]: 2018/05/15 16:13:40 [WARN] Unable to get address for server id f8591287-efee-97bb-95c0-2ecd39616cb5, using fallback address z.z.z.z:5825: Could not find address for server id f8591287-efee-97bb-95c0-2ecd39616cb5
May 15 16:13:40 repo2 consul[13626]: 2018/05/15 16:13:40 [ERR] raft: Failed to heartbeat to z.z.z.z:5825: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused
May 15 16:13:45 repo2 consul[13626]: 2018/05/15 16:13:45 [WARN] consul.kvs: Rejecting lock of kmfdata/core/lock due to lock-delay until 2018-05-15 16:14:00.347058073 +0530 IST
May 15 16:13:45 repo2 consul[13626]: 2018/05/15 16:13:45 [WARN] consul.kvs: Rejecting lock of kmfdata/core/lock due to lock-delay until 2018-05-15 16:14:00.347058073 +0530 IST
May 15 16:13:46 repo2 consul[13626]: 2018/05/15 16:13:46 [WARN] Unable to get address for server id f8591287-efee-97bb-95c0-2ecd39616cb5, using fallback address z.z.z.z:5825: Could not find address for server id f8591287-efee-97bb-95c0-2ecd39616cb5
May 15 16:13:46 repo2 consul[13626]: 2018/05/15 16:13:46 [ERR] raft: Failed to AppendEntries to {Voter f8591287-efee-97bb-95c0-2ecd39616cb5 z.z.z.z:5825}: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused
May 15 16:13:48 repo2 consul[13626]: 2018/05/15 16:13:48 [INFO] agent: Deregistered service "vault:y.y.y.y:5819"
May 15 16:13:48 repo2 consul[13626]: 2018/05/15 16:13:48 [INFO] agent: Deregistered check "vault:y.y.y.y:5819:vault-sealed-check"
May 15 16:13:50 repo2 consul[13626]: 2018/05/15 16:13:50 [WARN] Unable to get address for server id f8591287-efee-97bb-95c0-2ecd39616cb5, using fallback address z.z.z.z:5825: Could not find address for server id f8591287-efee-97bb-95c0-2ecd39616cb5
May 15 16:13:50 repo2 consul[13626]: 2018/05/15 16:13:50 [ERR] raft: Failed to heartbeat to z.z.z.z:5825: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused
May 15 16:13:56 repo2 consul[13626]: 2018/05/15 16:13:56 [WARN] Unable to get address for server id f8591287-efee-97bb-95c0-2ecd39616cb5, using fallback address z.z.z.z:5825: Could not find address for server id f8591287-efee-97bb-95c0-2ecd39616cb5
May 15 16:13:56 repo2 consul[13626]: 2018/05/15 16:13:56 [ERR] raft: Failed to AppendEntries to {Voter f8591287-efee-97bb-95c0-2ecd39616cb5 z.z.z.z:5825}: dial tcp y.y.y.y:0->z.z.z.z:5825: getsockopt: connection refused

        consul instance 3 logs(z.z.z.z):
        Consul service instance 3 wan't active at this timeframe.

        vault instance 1 logs(x.x.x.x):
2018/05/15 16:13:39.493898 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:39.520097 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:39.821918 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:39.883150 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.047783 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.058892 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.204434 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.224893 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.395825 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.421182 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.550948 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.562523 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.781571 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.820538 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.908266 [DEBUG] forwarding: error sending echo request to active node: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:41.138147 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:41.165794 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:41.509211 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:41.525078 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
        
        vault instance 2 logs(y.y.y.y):
2018/05/15 16:13:40.087007 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.103014 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.118278 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.136395 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.169163 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.194294 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.258137 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.294508 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.287678 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.337178 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.363053 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.372064 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.437709 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.479494 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.486514 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.502216 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request
2018/05/15 16:13:40.539262 [ERROR] core: error during forwarded RPC request: error=rpc error: code = Unavailable desc = all SubConns are in TransientFailure
2018/05/15 16:13:40.549127 [ERROR] http/handleRequestForwarding: error forwarding request: error=error during forwarding RPC request

        Please let us know when this issue could happen, and why vault returns success, when data hasn't been written to consul or not processed to the end step.

        Thanks in advance.

Best Regards,
Bharath B

Jeff Mitchell

unread,
May 18, 2018, 12:00:39 PM5/18/18
to Vault
Hi there,

You are getting tons of errors in both your Consul and Vault logs. For Vault it's likely misconfiguration; for Consul I'm not sure, but note that Consul uses a consensus protocol and having only two nodes active means no quorum can be established; you *must* have an odd number of nodes for the cluster to be healthy (and in the correct state), and a healthy cluster is a must for Vault to work properly.

Best,
Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/7fecc9f1-308d-4c28-9c76-59a38f05614a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bharath B

unread,
May 18, 2018, 12:14:40 PM5/18/18
to vault...@googlegroups.com
Hi Jeff,

     Thanks for the response.

      I totally agree with your findings, but my expectation during a scenario like this is, write API to return an error to notify user about the write failure or the vault system state like during the scenario where vault leader is not chosen yet, an error like "local node not active" is returned and was expecting a similar error, but instead we are getting a successful response, which is misleading.

Thanks,
Bharath B

You received this message because you are subscribed to a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/LJx5_VfhZr4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GHzjkHZ8pTfa%2B%3DbcAcp%2Bhu-dT7v9BLo%3DhiRx%2BMSo_jXZw%40mail.gmail.com.

Jeff Mitchell

unread,
May 18, 2018, 12:46:52 PM5/18/18
to Vault
Hi Bharath,

I can't really comment on this becuse when your storage is in an unhealthy state all bets are off. It's possible that the write occurred when it was healthy, but then the list is being tried when it's not healthy. I just don't know. You also didn't send output from the write so I can't really eveluate whether it really was telling you success or not.

Best,
Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAAjxnfooY1-tM92XuGBCQ0NbW8HTwnOsqgoUnQc2_oXRBVkg4Q%40mail.gmail.com.

Bharath B

unread,
May 18, 2018, 1:04:27 PM5/18/18
to vault...@googlegroups.com
Hi Jeff,

      Thanks, will attach the code snippet of the vault write API and the relevant logs by Monday.

Best Regards,
Bharath B

Bharath B

unread,
May 21, 2018, 12:44:23 AM5/21/18
to Vault
Hi Jeff,

     Please find below the logs captured by our interface during write API call.

2018/05/15 16:13:40.008259  INFO  -- writeToVault -- Write successful for secret/keys/HttpServer1
2018/05/15 16:13:40.161698  INFO  -- writeToVault -- Write successful for secret/keys/HttpServer2
2018/05/15 16:13:40.354571  INFO  -- writeToVault -- Write successful for secret/keys/HttpServer3

     Below is the code snippet containing the write API.

func writeToVault(paramPath string, secretData map[string]interface{}) error {
    if _, err = logical.Write(paramPath, secretData); err != nil {
logger.Println(" ERROR -- writeToVault -- Error during vault write, err", err)
    } else {
logger.Println(" INFO  -- writeToVault -- Write successful for", paramPath)
    }
    return err
}

Thanks and Regards,
Bharath B

Bharath B

unread,
Jun 6, 2018, 7:41:53 AM6/6/18
to Vault
Hi Jeff,

     Please help me with the query.

     Adding to your comment "I can't really comment on this becuse when your storage is in an unhealthy state all bets are off. It's possible that the write occurred when it was healthy, but then the list is being tried when it's not healthy. I just don't know. You also didn't send output from the write so I can't really eveluate whether it really was telling you success or not."
     We tried listing before and after restarts of vault and consul, in both cases, didn't get the expected result.

     Before restart, we were observing the mentioned errors, and then services were restarted including consul third instance, after which there were no errors observed in both vault and consul logs, but still list returned empty.

     Does vault or consul store data in process memory, before writing to disk in erroneous scenarios like the one reported?? 

     I am not able to understand, how the data written could vanish. Writes were done from both vault instances and none is available. Is there anyway we can find errors like this(before going for write we are checking if vault and consul leaders are available), except from the logs, so that write can be aborted with suitable errors.

Jeff Mitchell

unread,
Jun 6, 2018, 9:54:02 AM6/6/18
to Vault
Hi Bharath,

Vault does not, and Consul usually doesn't but can run in various modes providing different consistency guarantees. If configured in a mode that doesn't provide strong guarantees it's possible you could write data to Consul and if the cluster becomes inconsistent before the data is replicated it could be lost.

Best,
Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/0e02c748-0ce5-43f5-bf5c-7dbce2d59fe7%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages