You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The new platform driver needs to load all device configurations together at start time, but still wants to be able to receive individual NEW or UPDATEed device configurations at a later time. In an attempt to accommodate this, a lock variable is set before subscribing to the "devices/" pattern, then the device configurations are loaded manually using vip.config.get('devices/') during the NEW event for "config" (the agent configuration). The lock must then be held long enough that the remaining callbacks for all the initial "NEW" events have finished. Then the lock is released in on_start(). Unfortunately, the "on_start" event is capable of being (and observed to be) fired before the "on_configure" event. This means the lock is released before the NEW configuration callbacks have run.
Describe the solution you'd like
The "on_start" event should deterministically run after "on_configure" or there should be another lifecycle event which does, e.g., "configuration_complete".
Describe alternatives you've considered
Another solution would be to have an additional type of "action" beyond NEW, UPDATE, and DELETE. When the agent starts, a NEW action is sent for each configuration. When these configurations are updated later, an UPDATE action is sent. If a brand new configuration is added, however, a NEW action is sent (though only for the newly added config). For this reason, it is not possible to subscribe only to NEW events which occur after startup nor to only events happening at startup, since they use the same action type (NEW). Really, these two types of NEW actions are distinct. There is (in principle) an INITIAL action which runs when the agent starts and an ADD action which runs when a file is added after the INITIAL actions have completed. While it may not be possible to remove the NEW action, adding INTIAL and ADD actions in parallel with NEW would allow these distinct events to be captured. This alternative would actually be useful even if the lifecycle events are made deterministic, and I would probably advocate that we should do both.
Additional context
A (selective) log of starting the new driver agent with the above described lock. The :
Is your feature request related to a problem? Please describe.
The new platform driver needs to load all device configurations together at start time, but still wants to be able to receive individual NEW or UPDATEed device configurations at a later time. In an attempt to accommodate this, a lock variable is set before subscribing to the "devices/" pattern, then the device configurations are loaded manually using vip.config.get('devices/') during the NEW event for "config" (the agent configuration). The lock must then be held long enough that the remaining callbacks for all the initial "NEW" events have finished. Then the lock is released in on_start(). Unfortunately, the "on_start" event is capable of being (and observed to be) fired before the "on_configure" event. This means the lock is released before the NEW configuration callbacks have run.
Describe the solution you'd like
The "on_start" event should deterministically run after "on_configure" or there should be another lifecycle event which does, e.g., "configuration_complete".
Describe alternatives you've considered
Another solution would be to have an additional type of "action" beyond NEW, UPDATE, and DELETE. When the agent starts, a NEW action is sent for each configuration. When these configurations are updated later, an UPDATE action is sent. If a brand new configuration is added, however, a NEW action is sent (though only for the newly added config). For this reason, it is not possible to subscribe only to NEW events which occur after startup nor to only events happening at startup, since they use the same action type (NEW). Really, these two types of NEW actions are distinct. There is (in principle) an INITIAL action which runs when the agent starts and an ADD action which runs when a file is added after the INITIAL actions have completed. While it may not be possible to remove the NEW action, adding INTIAL and ADD actions in parallel with NEW would allow these distinct events to be captured. This alternative would actually be useful even if the lifecycle events are made deterministic, and I would probably advocate that we should do both.
Additional context
A (selective) log of starting the new driver agent with the above described lock. The :
The text was updated successfully, but these errors were encountered: