tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 225c79d5e87806224691c9907f6bd67ba636ff34..ade00db5c6db748fe3fe22a5c57794c5eec698c9 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -40223,6 +40223,15 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   </summary>
 </histogram>
 
+<histogram name="UMA.EnrollmentStatus" enum="EnrollmentStatus">
+  <owner>asvitkine@chromium.org</owner>
+  <owner>kaznacheev@chromium.org</owner>
+  <summary>
+    Logs the device enrollment status for Chrome OS device. Logged with every
+    UMA upload.
+  </summary>
+</histogram>
+
 <histogram name="UMA.EntropySourceType" enum="UmaEntropySourceType">
   <owner>asvitkine@chromium.org</owner>
   <summary>
@@ -46807,6 +46816,12 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   <int value="1" label="Screen unlocked (via EasyUnlock)"/>
 </enum>
 
+<enum name="EnrollmentStatus" type="int">
+  <int value="0" label="Non-managed"/>
+  <int value="1" label="Managed EDU"/>
+  <int value="2" label="Managed non-EDU"/>

[Thiemo Nagel, 2015/03/06 06:03:29]

In the future, I plan to extend this for other platforms, eg. reporting whether
a Windows machine is joined to an Active Directory domain or whether the
MSI-specific brand code is being used.  As far as I understand, that would be
easier to accomplish if EnrollmentStatus was interpreted as a bitmask.  I'd
suggest to change to:

<int value="0" label="Install Attributes managed"/>
<int value="1" label="EDU Domain"/>

In that scenario, a machine enrolled to an EDU domain would have two histogram
entries and an unenrolled machine would have zero entries.

This could later be extended eg. by:
<int value="2" label="Active Directory managed"/>
<int value="3" label="MSI installer"/>
...

Alexei, would that look reasonable to you?

[Alexei Svitkine (slow), 2015/03/10 15:16:10]

I'm not sure I'm understanding your suggestion. In your proposal, how is
"unmanaged" being tracked? It seems none of the cases above say "unmanaged"
whereas as it is currently in this CL, it is tracked as value 0. What am I
missing?

Note, that in general, UMA dashboards don't currently have built-in support for
dealing with bit masks. e.g. if you have values "1, 3 and 7" that both have bit
1 set, there's no easy way to ask the dashboards to just show me values where
that bit is set - without manually group-selecting those cases together, which
is no different than not using bit masks. But maybe I'm missing some other
advantage of the solution you're proposing - which is likely true, since as I
mentioned above, I don't actually understand your proposal. Could you clarify?

[Thiemo Nagel, 2015/03/10 15:37:12]

My intent is to track "unmanaged" by not setting any value, but it seems that
this does not play nice with the UMA design?
While on Chrome OS the "enterprise" vs. "consumer" distinction is easy to make
by referencing install attributes, we don't have that luxury on other platforms
and thus need get by with somewhat ambiguous and potentially overlapping
indicators as described above.  In order to study the systematics of these
ambiguous indicators (let's call them i1, i2, i3), I'd like to be able to look
at the stats for different logical combinations (such as eg. i1 && !i2 || i3). 
To that end, I had intended to treat the histogram as a bitmask and fill it once
for every indicator that is observed, but this doesn't seem to work out.

From your perspective, what would be the best way to implement multiple,
overlapping indicators and their logical combinations?

[asvitkine_google, 2015/03/11 14:36:03]

Yes, this is problematic. Because if we see no value, we don't know if it means
"unmanaged" or simply from clients that don't report it - e.g. old versions,
platforms where it's not implemented, etc. It would be misleading to just say
"unmanaged" for these rather than "unknown".

However, I actually don't think that reporting an "unmanaged" value is
incomatible with the bitmask proposal. 0 can still mean unmanaged, whereas
non-zero values can be intrepreted as bit-masks.
We don't have a good way to implement this. If it's just a regular histogram,
then it's fine to use bit-masks with the inconvenience that you have to have
enum entries for all possible bit combinations (which doesn't scale well but can
work ok for a small number of bits - e.g. 3). But actually we want to make this
a filter that can be used to slice other histograms. Which would require a lot
of logic specific to this histogram in our dashboards to get meaning out of the
values - which we prefer not to add (we don't want logic that's custom tailored
to specific histograms).

How about this:

Have two histograms. One that logs the overall summary stats (e.g. as it is
here) and a second histogram (that can be added later when we implement this for
Windows) that logs more details in the bit-mask approach you suggest. This way,
we can move forward with this approach now and add the more detailed cases once
we do the Windows implementation - which won't need to conflict with this
initial approach.

+</enum>
+
 <enum name="EnterpriseCheckError" type="int">
   <summary>
     Defined as DomainCheckErrors in