Set vpd value first_active_omaha_ping_sent=0 in factory |
||
Issue descriptionWe currently only set the first_active_omaha_ping_sent=1 in vpd in the update engine after the first active ping is sent or after we found out that we have already sent the active ping. It would be better to set its value to 0 in the factory and change it to 1 after the active ping is sent. This might reduces that chances of vpd not responding correctly when trying to get the value. Also this needs to be reflected in dev mode switch. If we switch to dev-mode and vice versa, we should be able to set the value to 0 instead of wiping it off! Also reduce the frequency of writing it to only update checks and not update response responses replies to omaha.
,
Nov 1
,
Nov 1
1. for the case we failed to read VPD, what should we do? should we read again? 2. what if somehow RW VPD is cleared? Do we treat it as first_active_omaha_ping_sent=0 or first_active_omaha_ping_sent=1? 3. Can you give more detail aobut "If we switch to dev-mode and vice versa, we should be able to set the value to 0 instead of wiping it off!". Why do you want to resend omaha ping when getting in / out dev mode? Are we doing this now?
,
Nov 1
> 1. for the case we failed to read VPD, what should we do? should we read again? With the current implementation of vpd_get_value, it never fails as hungte@ suggested. So I don't really think that applies unless we change the implementation to vpd -i RW_VPD -g <> > 2. what if somehow RW VPD is cleared? Do we treat it as first_active_omaha_ping_sent=0 or first_active_omaha_ping_sent=1? Yeah, if it is cleared, then we treat it as first_active_omaha_ping_sent = 0 > 3. Can you give more detail aobut "If we switch to dev-mode and vice versa, we should be able to set the value to 0 instead of wiping it off!". > Why do you want to resend omaha ping when getting in / out dev mode? > Are we doing this now? Yeah, currently on a dev mode switch we wipe the first_active_omaha_ping_sent and the rationale for it was that we can get a device fresh out of factory. Basically removing any extra sticky state. So I'm guessing if we set this flag to zero in factory, then the course of action would be to set it to zero when switching to dev mode. But, to he honest, I have my doubts that this will really help us with the current high number of active counts coming from non-FSI boards. We haven't figured out the root cause of that.
,
Nov 2
I assume this bug is filed for discussion only. Let's not act on this until we agree. If we do this I would generally like to ever set the value back to 0. I know that's contrary to the privacy discussion we had so that may need to be revisited. I'm OK if the field is completed removed once the ping is sent, and the default behavior should be NOT the send the ping unless it's explicitly set to 0. Actually, my suggestion would be to deprecate the existing field and introduce a new one like should_sent_omaha_first_active_ping that parallels the behavior of the should_send_rlz_ping boolean.
,
Nov 2
What is the condition to send omaha ping and rlz ping? a) the first login / boot up after the system is power washed? b) the first login / boot up after the system left factory? or some other condition?
,
Nov 2
re #5. Oh, Actually that's more clever! We remove it once we send the ping. So in case it gets deleted or something we don't have to worry about it. |
||
►
Sign in to add a comment |
||
Comment 1 by ahass...@chromium.org
, Nov 1