Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NodeMeta Data is not stored in snapshots #4524

Closed
nickmy9729 opened this issue Aug 13, 2018 · 3 comments
Closed

NodeMeta Data is not stored in snapshots #4524

nickmy9729 opened this issue Aug 13, 2018 · 3 comments
Labels
good first issue A well-defined bug or improvement with sufficient context which should be approachable for new contr type/bug Feature does not function as expected
Milestone

Comments

@nickmy9729
Copy link
Contributor

nickmy9729 commented Aug 13, 2018

When issuing command consul snapshot save /somedir/filename.snap. The snapshot produced does not contain the NodeMeta data. This is important when you have registered an external node that is not using a Consul agent via the /v1/catalog/register API that include NodeMeta. Once restoring the snapshot the node is visible but it's MetaData is gone.

I have also seen similar behavior when all servers have been restarted the NodeMeta would not persist in the data directory, even though on closer inspection it appears to be in the raft.db file.

@mkeeler
Copy link
Member

mkeeler commented Aug 13, 2018

@nickmy9729 Thanks for the report.

I think the problem is around here in the code:

req := structs.RegisterRequest{
Node: n.Node,
Address: n.Address,
TaggedAddresses: n.TaggedAddresses,
}

I ran into a similar issue recently where we weren't putting some of the data into the snapshot and restoring it out of a snapshot properly. That is when its in raft too. So the situation sounds pretty similar.

@mkeeler mkeeler added type/bug Feature does not function as expected good first issue A well-defined bug or improvement with sufficient context which should be approachable for new contr labels Aug 13, 2018
@mkeeler mkeeler added this to the 1.2.3 milestone Aug 13, 2018
@shubheksha
Copy link
Contributor

I'll pick this up!

@nickmy9729
Copy link
Contributor Author

I just submitted a PR that seems to fix this issue #4527

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue A well-defined bug or improvement with sufficient context which should be approachable for new contr type/bug Feature does not function as expected
Projects
None yet
Development

No branches or pull requests

3 participants