Zur Info, dies kam über die Mailingliste von Neoraider:
we have recently pushed a new Lua library for site access. This new library
allows more convenient access to nested optional values:
gluon-core: add new gluon.site library for convenient access to optional values
The new gluon.site lua library will eventually replace gluon.site_config
(which is hereby deprecated, but will continue to be supported for a
while).
The new gluon.site library will wrap all values to allow traversing
non-existing tables without errors.
site = require 'gluon.site'
c = site.a.b.c -- doesn't fail even if a or a.b don't exist
The wrapped values must be unwrapped using call syntax:
site_name = site.site_name()
Using the call syntax on a non-existing value will return nil. An
alternative default value may be passed instead:
mac = site.next_node.mac('16:41:95:40:f7:dc')
At the moment, both libaries are available for use in custom packages, but
the old gluon.site_config library will be removed soon.
Site i18n files that access the site configuration from Lua code in the
gluon-config-mode:reboot, gluon-config-mode:pubkey or
gluon-config-mode:novpn messages need to be adjusted, as the config mode
wizard now uses the new site library.
Da sind ja inzwischen schon ein paar mehr Änderungen im master, die man berücksichtigen muss, das sollten wir Mal alles auflisten. Oder gibt es so eine Liste schon?
„eventually“ bedeutet nach Definition nicht wie man meinen könnte „eventuell“, sondern wie ein Blick ins Englisch-Deutsch Wörterbuch verrät, „schließlich“ oder „schlussendlich“
Update: As we are preparing the addition of multi-domain support to Gluon, site_seed has been renamed to domain_seed in the latest master. – @anon75826926
Auf Dauer sollte man sich wahrscheinlich Gedanken machen über in_site() und in_domain(), und gluon.site_config sollte durch gluon.site ersetzt werden, da gluon.site_config irgendwann rausfliegt
das wäre im Gluon wiki (das jeder mit GitHub Account editieren kann) in der Tat deutlich besser aufgehoben als hier…
ist nicht vorgesehen, da das legacy mesh mit dem übernächsten Release wegfallen soll voraussichtlich.
aber das wurde dir ja im IRC eigentlich schon einmal gesagt
wie funktioniert dann das Upgrade von komplexeren Lan-Mesh-Netzen?
Ist da irgendwie parallelbetrieb zeitweise möglich, so wie beim Wechsel von adhoc zu 11s?
ja. ohne manuelles basteln, indem du ein Gerät im „komplexen Lan-Mesh-Netz“ hast, das zwei Ports hat, dann legst du auf einen legacy und auf den anderen VXLAN.
mit manuellem Basteln kannst du auch beides auf den selben Port legen.
weitere Alternative, wie beim Funk-Mesh: den entferntesten node zuerst umstellen, schrittweise bis zum Offloader/VPN-Knoten fortführen.
Das setzt aber voraus, dass man SSH-Zugang auf alle Knoten der Domains hat, was leider/zum Glück illusorisch ist.
Also zumindest für uns wäre da erstmal eine Migration-Sackgasse.
Was heisst denn „beim übernächsten Release“? Sind damit „major revision numbers“ oder „point-releases“ gemeint?
es musst ja nicht du selbst sein, Freifunk ist ja häufig dezentral (heute weniger als früher).
falls gar niemand Zugriff hat:
komplexe IT deployen ohne dass irgendjemand Zugriff hat? very good idea. applause.
Wir haben Richtfunkstrecken (P2MP, Stock-FW) an deren Enden unterschiedliche Sites (und Verantwortliche) zuständig sind.
Das könnte mehr als spannend werden, da einen „zentralen“ Umschalttermin zu vereinbaren, wo alle gleichzeitig an den Konsolen bereit sitzen…