config_dump returns output in random order

[ramaraochavali]

Currently config_dump returns configs in random as they are defined as a map in the proto.
Is there any better way to to make output more deterministic via protos? Otherwise can we enforce some ordering while displaying?

[mattklein123]

IIRC there is a way to have proto do consistent serialization but I forget the details right now and I don't have time to go poking through the code (check proto utilities). @htuch do you remember?

[htuch]

I'm not sure this is possible in the presence of maps, e.g. https://gist.github.com/kchristidis/39c8b310fd9da43d515c4394c3cd9510. I think for this reason, maps should be avoided in our admin API endpoint output.

[mandarjog]

Maps keys can be optionally sorted to make diffing easier. The question is should this be done inside the config_dump endpoint or is it better left to the client that is consuming the output.

If it is not too expensive, determnistic json output is preferred.

[htuch]

@mandarjog where is the option to have proto do this? I don't see it in JsonPrintOptions.

[htuch]

Also, I'd question what value maps bring to any of our endpoint output, can someone articulate this?

[mattklein123]

I don't think the maps add any value. I would just switch them all to lists.

[ramaraochavali]

@mattklein123 assign this to me. I will work on it

[lizan]

Even we make them lists, the output won't be deterministic in many places where the config is dumped from std::unordered_{set,map} internally, (I'm sure routes are backed by unordered_set of pointers, not sure for others). It is still better the client consuming the output do a semantic comparison.

[htuch]

@lizan from the client perspective, this is unsatisfying, since we use these protos to serialize to JSON and output for humans. Humans aren't very good at comparing large unordered lists 💩

[lizan]

Right, so I would suggest use (or should we make one?) a client side tool to sort them instead of doing admin output, to keep admin endpoints lightweight.

[yangminzhu]

I'm trying to sync Istio with the latest envoy API, Is it always guaranteed that the [bootstrap, listener, cluster, routes] will always appear in the Configs in this specific order?

cc @liamawhite

[ramaraochavali]

@yangminzhu It is always guaranteed to return in the order [bootstrap, cluster, listener, routes] (lexicographic order) as documented here

[ramaraochavali]

@htuch I guess this issue can closed via #4197 unless you would like some thing else to be done here.

[htuch]

Well, there are other maps for stats (https://github.com/envoyproxy/envoy/blob/master/api/envoy/admin/v2alpha/clusters.proto#L49), but I think this is a reasonable step and we can open new issues if folks object.

[ramaraochavali]

Yeah. I saw that. Let me see if I can fix that as well this week.