The priority defines the maximum number of days that may pass between releasing an update and installation of the images. The update probability with start at 0 after the release time mentioned in the manifest and then slowly rise to 1 after the number of days given by the priority has passed.
Ich kenne zwar grade den Kontext nicht so ganz, aber ich würde das mal so verstehen:
Die „Priority“ ist die maximale Anzahl an Tagen, die nach erscheinen eines Updates bis zum Updatevorgang vergehen darf. Die „Update Probability“ ist die Wahrscheinlichkeit, dass ein Knoten schon das Update hat.
Beispiel:
Du hast 100 Knoten und setzt die Priority auf 10. Dann sollen alle 100 Knoten nach 10 Tagen das Update haben. Die Update Probability sagt dann nur, dass nach 3 Tagen 3/10 der Zeit vergangen ist, also hat die Update Probability einen Wert von 0,3 (30%). Bedeutet nichts anderes als dass rechnerisch 30 Knoten das Update haben und 70 noch fehlen.
Man möge mich korrigieren, wenn ich einen schweren Denkfehler erlitten hab
Würde ich so sehen, allerdings musst du im Blick haben wie viele Knoten das Update brauchen. Wenn alle gleichzeitig auf den Server zugreifen wollen, führt das nur zu Stau
Ich muss die Frage nochmal ausgraben und nachhaken…
Was macht der autoupdater wenn GLUON_PRIORITY=0 ist?
Den Zusammenhang mit der probability aus der site.conf habe ich auch nicht richtig verstanden.
Ich hatte mir aus anderen site.confs hergeleitet das man mit der Rechnung 1 geteilt durch den probability Wert den Updatecheck in Stunden einstellt
Also bei probability = 0.5 wäre der Updatecheck alle 2 Stunden.
1 / 0.5 = 2
Inzwischen scheint es so zu sein, dass einmal pro Nacht (4h-irgendwas, plus random Minuten) schaut er erstmalig nach einem realen Updateversuch.
die Manifest-Datei holt er aber trotzdem vorher schon stündlich. Dann wird er aber nur dann aktiv, wenn seit dem Manifest-Datum schon mehr als 24h vergangen sind, respektive „schon einmal 4h darüber verstrichen ist“.
Nur wie das Ding arbeitet, wenn es keine reale Uhrzeit hat: Keine Ahnung.
Ist etwas obskur, aber nach meiner Beobachtung: Nach 24h haben die meisten Knoten ihr Update, durch welche Mechanik auch immer.
PRIORITY
Specifies the maximum number of days until the update should be attempted (thus lower numbers mean the priority is higher). It must be set either in site.mk or on the make manifest command line.
Updates will be attempted at night, between 04:00 and 5:00, with a specific probability. When less than PRIORITY days have passed (calculated using DATE and the current time), the probability will proportional to the time passed. I.e. the update probability will start at 0 and slowly increase to 1 until PRIORITY days have passed. From then, the probability will be fixed at 1.
Ich setzte beispielsweise bei Beta Updates gerne eine Priorität von 2 und den Zeitraum zu dem die Knoten auch anfangen tagsüber das Update zu ziehen um zwei Tage zu verschieben.
Stable Updates habe ich mit 14 schon über zwei Wochen verteilt um eine Möglichkeit offen zu halten bei auftretenden Problemen die Auslieferung doch noch zu stoppen.
Danke.
So oft wie ich das für die „broken“ bei uns schon manuell getan habe „ausnahmsweise“ (was für eine Selbsttäuschung), habe ich’s jetzt in der Tat ins Sign-Script übernommen.