Re: Normalization of metric keys

Good idea; I think percent-encoding sounds great. Unless there are any objections, I'll go with that approach. On Fri, Jul 6, 2018 at 5:32 PM, Benjamin Mahler wrote: > Do we also want: > > 3. Has an unambiguous decoding. > > Replacing '/' with '#%$' means I don't know if the user actually suppli

Re: Normalization of metric keys

Do we also want: 3. Has an unambiguous decoding. Replacing '/' with '#%$' means I don't know if the user actually supplied '#%$' or '/'. But using something like percent-encoding would have property 3. On Fri, Jul 6, 2018 at 10:25 AM, Greg Mann wrote: > Thanks for the reply Ben! > > Yea I susp

Re: Normalization of metric keys

Thanks for the reply Ben! Yea I suspect the lack of normalization there was not intentional, and it means that you can no longer reliably split on '/' unless you apply some external controls to user input. Yep, this is bad :) One thing we should consider when normalizing metadata embedded in metr

Re: Normalization of metric keys

I don't think the lack of principal normalization was intentional. Why spread that further? Don't we also have some normalization today? Having slashes show up in components complicates parsing (can no longer split on '/'), no? For example, if we were to introduce the ability to query a subset of

Normalization of metric keys

Hi all! I'm currently working on adding a suite of new per-framework metrics to help schedulers better debug unexpected/unwanted behavior (MESOS-8842 ). One issue that has come up during this work is how we should handle strings like the framework n