2.5.2 entwickelt sich IMHO sehr gut

slu

@jegr
ja das sind schon Punkte die man nachvollziehen kann.
Ich freue mich auf das 2.5.2 Release :)

fireodo

@slu said in 2.5.2 entwickelt sich IMHO sehr gut:

Ich freue mich auf das 2.5.2 Release :)

... ich auch, bin gespannt wann es soweit ist!

Schönes WoE,
fireodo

p54

@slu ja ich auch. Kann es kaum erwarten, aber da ich jetzt Urlaub habe brennt es mich gerade nicht so sehr unter den Fingern.
@fireodo Der Status seit dieser Woche verändert sich nur geringfügig im redmine. Aber wenigstens kommen nun keine weiteren mehr dazu. Könnte bald soweit sein. Aber was bedeutet der Status: Feedback jetzt genau wenn dieser im request darauf gesetzt wird?

fireodo

@p54 said in 2.5.2 entwickelt sich IMHO sehr gut:

Aber was bedeutet der Status: Feedback jetzt genau wenn dieser im request darauf gesetzt wird?

Man wartet ab ob die Änderungen tatsächlich so wirken wie beabsichtigt und wartet auf Rückmeldungen von den Usern bevor man die Änderung auf gelöst/geschlossen setzt. (Oder hab ich deine Frage falsch verstanden?)

Schöne WoE,
firodo

p54

@fireodo ne alles richtig verstanden. Danke jetzt weiß ich was es mit dem "feedback" auf sich hat. Wünsche ebenso ein ruhiges weekend.

fireodo

@p54 said in 2.5.2 entwickelt sich IMHO sehr gut:

Wünsche ebenso ein ruhiges weekend.

Danke!

JeGr

@p54 kommt aber hart drauf an, wie man das eben im Devel-Team organisiert hat und was damit gemeint ist. Wir nutzen selbst auch Redmine intern und der Feedback Status ist bei uns intern im Team. Sprich der Status symbolisiert, dass der Ticket-Eigentümer noch mit/von irgendwem Feedback einholt oder nachfragen muss und es deshalb nicht weiter geht. Also quasi ein Blocker. Da ich keinen Einblick habe, wie Netgate das nutzt kann @fireodo natürlich recht haben und es sind User gemeint, es kann aber genauso gut internes Feedback durch Testbenches oder andere Prozesse gemeint sein :)

fireodo

@jegr said in 2.5.2 entwickelt sich IMHO sehr gut:

natürlich recht haben und es sind User gemeint, es kann aber genauso gut internes Feedback durch Testbenches oder andere Prozesse gemeint sein :)

Ich bezog mich hauptsächlich auf diese von Jim (Pingle) getätigte Aussage auf redmine:
"Will hold open for now to wait for additional feedback, but can be closed if none is received before release." (11805)
als Antwort auf mehrere User Posts.

Schönes WoE,
fireodo

JeGr

@fireodo Ja klar, war auch keine direkte Kritik an dir. Man weiß nur nicht ob das generell so gehandhabt wird oder in dem Fall nur. Trotzdem gut erkannt :)

Was sich jetzt bei der 2.5.2RC im letzten Snapshot m.E. auch verbessert hat ist das OVPN reconnection handling. Ich hatte dazu schon nen Bugpost aufgemacht, da bei gesetzten "explicit exit notifiy" auf 1 oder 2 gerade Tunnel einem schön um die Ohren geflogen sind. Sprich: statt exit notify hat die entsprechende Seite den Tunnel beendet statt nur mitzubekommen, dass die Gegenstelle sich abgemeldet hat. Bei S2S Tunneln hatte das die Auswirkung, dass - sollte es gesetzt gewesen sein - sich bei einem Restart der Seite A die Seite B einfach den Service beendet hat. Seite A konnte nach Restart dann nicht mehr verbinden.

Gleiches Spiel gabs bei RAS Clients auch, dann war der ganze Server weg. Das habe ich zumindest in letzter Instanz jetzt bei RAS Clients (Tunnel noch keine Zeit) nicht mehr, statt dessen wird jetzt - extrem sauber und schnell! - erkannt, dass der Client sich disconnected hat und der Client steht nicht mehr elend lang in der Connection list bis er timeouted (wenn in der Client Conf explicit-exit-notify drin ist natürlich). Umgekehrt ist es beim Server dann so, dass Clients sofort(!) auf Stufe gelb wechseln und nach 5s die Verbindung neu aufbauen, wenn vom Server ein "Restarte" kommt. Sehr gut, weil man damit die Downtime bei Änderungen an der Config minimieren kann - nach 10s sind die Clients wieder da. (5s timeout, 5s beim User/Passwort Dialog)

Muss noch das Verhalten bei S2S testen, sieht aber bislang sehr gut aus.

p54

@jegr Ah sehr guter Hinweis mit dem timeout, danke. cya

JeGr

@jegr said in 2.5.2 entwickelt sich IMHO sehr gut:

Muss noch das Verhalten bei S2S testen, sieht aber bislang sehr gut aus.

Mein erster Test zwischen 2.5.2RC und 2.6 war bei Tunnelsetup auf den ersten Blick wieder genau das beschriebene Problem. Hat man einen Tunnel und auf beiden Enden Retry Once ausgewählt wird bei Restart einer Seite der Tunnel auf der anderen Seite beendet (entsprechender Prozess stirbt).

Irgendwie kann ich nicht glauben, dass das Absicht sein soll.