jetzt sieht es wieder gut aus. (nach update)
sehe wieder zuviele serialization errors. da ist noch was falsch bzw. ich hab sogar einen neuen fehler reingebaut. muss weitersuchen.
ist jetzt aktiviert. mal sehen, wie weit es gutgeht.
CNAME Record auf Metadomains lassen sich nicht anlegen.
Beispielsweise _dmarc.scc.kit.edu
auf _dmarc.kit.edu
ok., ist eingetragen.
wie besprochen: wir nehmen die variante 'separate prozedur'. aufruf als parameterlose prozedur:
call dhcpd.api_set_clnt_sess_params()
bei jeder neuen session. ich bereite dann den code mit shard-state-logik etc. vor.
nach tests hat sich gezeigt, dass es besser ist, alle client-parameter client-seitig zu setzen, dh. im kea-code. alternativ: die parameter in postgresql.conf setzen (ansible: roles/netdb_common/templates/postgresql_conf.d/dhcpd/client_conn_dflts.conf)
m.e. hat postgres da ein etwas komisches verhalten bei der transaktionsbehandlung in den prozeduren. insbesondere gibt es kein explizites TA-start-kommando, sondern die TA beginnt immer implizit mit dem ersten sql-statement in der prozedur. dadurch werden die client-params, wenn sie in der prozedur-internen TA gesetzt werden, nicht wirksam.
demnach also kea-seitig oder postgresql.conf-seitig oder in separater prozedur (die dann je session vor jedem api-call aufgerufen werden muss) setzen:
der exception handler innerhalb der api-prozeduren wuerde dann z.b. fuer statement_timeout funktionieren, so dass man dort die shard-state-tabelle modifizieren koennte.
Wenn man selbst viele Gruppen hat, allerdings keine globalen Leserechte für cntl, wird ein Join über api_fkey_cntl_mgr2group_mgr
immer langsamer. (Scheint mit der Anzahl der Gruppen zu skalieren.)
Führt man die folgende TA mit globalen Rechten aus braucht sie weniger als 1 Sekunde, nimmt man eine Person aus der Gruppe landet man hier schnell bei >= 5 Sekunden.
Liefert das erste Statement mehr als ein Ergebnis wird das entsprechend linear langsamer.
Beispiel:
[
{
"idx": "mgr_groups",
"name": "cntl.group.list",
"old": {
"name": "ra-1"
}
},
{
"name": "cntl.mgr2group.list",
"inner_join_ref": {
"mgr_groups": "default"
},
"idx": "mgr2group_list"
},
{
"name": "cntl.mgr.list",
"inner_join_ref": {
"mgr2group_list": "default"
},
"idx": "mgr_list"
}
]
meine tests mit obiger vorlage sahen gut aus. ich schliesse daher.
wir koennen ueberlegen, ob es besser ist, alle diese timeout-params geschlossen im kea-code zu halten, oder im pgsql-code. also jeweils alternativ.
puh, glueck gehabt. war machbar. sollte jetzt in prod richtig sein?
problem erkannt: antijoin ist gesperrt f. join_grants_read_access
, muss aber bei gegenwart von innerjoin freibleiben.
weiss aber grad nicht, wie ich das gescheit sqlisieren kann. hoffe, ich muss da keine verrenkungen machen....
aktuell wird im kea-code statement_timeout
auf 30s gesetzt. das duerfte wirkungslos sein, solange in den api-procedures jeweils 2s eingestellt sind. beide einstellungen sollten wir moeglichst niedrig halten, um eine ueberlastung des masterservers zu vermeiden. zu tun:
idle_in_transaction_session_timeout
, statement_timeout
: also entweder komplett kea-seitig definieren oder komplett im pl/pgsql-api-code.vllt. wird es nach https://gitlab.net.scc.kit.edu/scc-net/net-suite/db-pgsql-app/-/issues/4 noch etwas einfacher.
deutet auf dieselbe problematik wie bei p-ports (connection pfad) hin: optimizer. ich baue das in 4.1 um, incl. join_grants_read_access fuer
api_fkey_cntl_mgr2ou_mgr
api_fkey_cntl_mgr2group_grp
api_fkey_cntl_mgr2group_mgr
letzteres sollte schon jetzt fuer prod. eine verbesserung bewirken.
for reference: ew4459 ist z.B. ein solcher Problemfall
kleine korrektur zum gegenstand: die duplikate kommen nicht nur bei namensbasierten, sondern potenziell bei allen RRs vor; das ganze hat auch nichts damit zu tun, ob die zone intern delegiert ist oder nicht (weiss grad nicht, was mit intern gemeint ist). die duplikate enstehen, wenn eine zone eine zd. bekommt (einem ns-set zugeordnet wird).
auch sollten wir nochmal ueber die constraint-modellierung sprechen. aktuell besteht der API-PK fuer dns.record
nur aus gpk
. es kaeme aber genaugenommen is_auth
noch dazu. das gleiche fuer weitere UNQ-constraints (fqdn, type, data).
das liegt an der duplizierung durch die materialisierte tabelle pdns_rr
, aus der die rr-objekte geholt werden. aber der gpk wird aus der usprungs-tabelle dns_rr_dst
geholt. ist insgesamt etwas unschoen, liegt aber an der natur der dns-anforderungen.
Mit beliebiger syntaktisch gültiger mac_addr
bekommt man immer alle leases (4.0).