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

Accommodate data center info metadata for types other than "Amazon" #42

Closed
seh opened this issue Aug 28, 2016 · 2 comments
Closed

Accommodate data center info metadata for types other than "Amazon" #42

seh opened this issue Aug 28, 2016 · 2 comments

Comments

@seh
Copy link
Contributor

seh commented Aug 28, 2016

Fargo allows one to specify and retrieve Amazon-specific data center metadata, but does not accommodate any such metadata for other types of data centers. The Eureka XML schema for instance registration is loose here; it mentions that the Amazon-specific schema for the dataCenterInfo element's metadata element applies only when the name element is "Amazon".

metadata is only required if name is Amazon

That says that it's only required; what it really should say is that anything is tolerated, at the discretion of the data center-specific Java type that parses this metadata in the Eureka server. What actually happens is that the Eureka server parses the metadata element into a Map<String, String> and allows types implementing com.netflix.appinfo.DataCenterInfo to interpret that mapping as they see fit. It just so happens that the Eureka authors were only concerned with one concrete kind of data center. My company has implemented several more data center types in our Eureka fork.

I propose adding a field to fargo.DataCenterInfo—called "AlternateMetadata" of type map[string]string—that allows callers to send and receive this metadata for data center types other than "Amazon". Doing so is necessary for clients to decide on an instance ID that the server will accept. Without this concession, the server always uses the submitted host name. (See #39 for related discussion.)

I will submit a PR that takes care of the marshaling, but first I thought that we might like to discuss the need for and merits of this approach here first.

@seh
Copy link
Contributor Author

seh commented Aug 30, 2016

I will submit a PR that takes care of the marshaling

To that end, see #44.

@seh
Copy link
Contributor Author

seh commented Sep 28, 2016

With #44 merged, I consider this issue to be resolved.

@seh seh closed this as completed Sep 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant