root/IDEAS @ 14dd8318
| dd170ff9 | Marc Dequènes (Duck) | ||
Postman:
|
|||
- process schema (without intermediate bot for command processing):
|
|||
(reschedule)
|
|||
/---------<--------\
|
|||
| | temp internal err
|
|||
IMAP | |
|
|||
retrieval -----> incoming mail queue ------> process mail ----> order queue ----> process order
|
|||
| |
|
|||
err | | order err or fatal int err
|
|||
| |
|
|||
SMTP reply <------ outgoing mail queue <-----------/------------------<------------------/
|
|||
each queue is an internal channel, each processor is a task.
|
|||
MapMaker:
|
|||
- API:
|
|||
/Services/DNS -> named info
|
|||
/Services/DNSSEC -> DNSSEC system info
|
|||
/Services/ZoneEditor -> Helper for zone content manipulation out of named scope
|
|||
/validate(<zone_name>, <zone_content>)
|
|||
/alter(<zone_content>, <recipe>)
|
|||
/Zones
|
|||
/? -> search zone, params are string/numeric/boolean/regex criterias ANDed
|
|||
/<zone> -> abstraction of a zone (DNS, DNSSEC, content…)
|
|||
/content -> view zone full content
|
|||
/? search RR
|
|||
/content=(<zone_content>) -> change zone full content
|
|||
/alter(<recipe>) -> recipe is a DSL-like list of commands
|
|||
- diag functions for services
|
|||
- distinguish presence of signed zone and which zone is really advertised by DNS
|
|||
Guard (auth bot):
|
|||
- process for delegating auth (needs polish):
|
|||
subject: Bot1 ask Bot2 to do a <job> for another <id>
|
|||
1) Bot1 tries to ident on behalf of Guard
|
|||
2) Guard fetch info into Librarian (LDAP)
|
|||
3) Librarian can tell if Bot1 auth is OK
|
|||
4) if so, Guard tells Bot1 he is identified
|
|||
5) Bot1 ask Bot2 to do a <job> as another user using <id> token
|
|||
6) Bot2, which is supposed to already be identified on behalf of Guard,
|
|||
as seen previously with Bot2, ask Guard if this <id> token is valid
|
|||
7) if valid, replies OK to Bot1 and schedule the job
|
|||
the <id> token can be on for himself, ro one acquired from Guard for
|
|||
another user if Bot1 has enough privileges
|
|||
Actions:
|
|||
- DECLINE:
|
|||
needs better definition and codes to distinguish temporary and fatal,
|
|||
errors, so as to know when to abandon and when to reschedule
|
|||
- CALL:
|
|||
+ exist? / info / act ???
|
|||
+ a reply could give a ref to another node, but how?
|
|||
Conversation:
|
|||
- when disconnect (needs polish):
|
|||
+ without ACK => error (lost), but we may add a mechanism to retry
|
|||
a few times with a delay (increasing delay)
|
|||
+ with ACK => save callback for when reconnected
|
|||
+ pending ACK => drop
|
|||
+ pending tasks => do, reconnect when result ready by ourselves
|
|||
Threads:
|
|||
- goals:
|
|||
+ auth token (negociated with Guard)
|
|||
+ I18n parameters (list of translation prefs)
|
|||
Tasks:
|
|||
- inheritance: thread data (auth token, I18n prefs…)
|
|||
| c29ad62c | Marc Dequènes (Duck) | - wait notif on multiple channels:
|
|
by registering the same callback on multiple channels,
|
|||
and unregistering all of them at once later. there is
|
|||
a chance of throwing the callback twice on different
|
|||
channels, so it is impossible to unsure a single call
|
|||
- work on sending notif to peers through special channels
|
|||
| dd170ff9 | Marc Dequènes (Duck) | ||
API:
|
|||
- node def:
|
|||
+ name
|
|||
+ array of names
|
|||
+ regex: matching names
|
|||
+ nil: method_missing-like catchall
|
|||
- client API:
|
|||
+ exists?
|
|||
+ call
|
|||
+ [<name>]: sub-node
|
|||
- define_interface:
|
|||
support list/ranges/regex for version and define several
|
|||
supported API a client could choose between
|
|||
Channels:
|
|||
- reorganize channel names
|
|||
- enforce msg[:from] with 'task/<task-name>' in send_notification
|
|||
Logging:
|
|||
- mass rework needed, with better "area" identification
|
|||
- multiple hierarchical loggers, using format to add prefixes
|
|||
- use dep-injection to propagate sub-logger to areas where all
|
|||
info needed to recreate prefixes are not available
|
|||
- use more log flags to activate debug only on specific areas
|
|||
Alerts:
|
|||
- actions can lead to problems, which need to be processed to dispatch
|
|||
proper messages to the user but also generate alerts to administrators.
|
|||
For example, of the DNS system is not working well, we need to reply
|
|||
the user the service is not working well and his/her demand connot be
|
|||
processed, without any technical detail, but the DNS admin should be
|
|||
alerted in order to repair it. Moreover, the overall CH admins should
|
|||
be alerted of bot problems and major failures. Moreover, the DNS zone
|
|||
admin could also be willing to receive alerts concerning the zone
|
|||
he/she is in charge of.
|
|||
- we need a process to generate events, and filter them to generate
|
|||
wanted alerts depending on area/severity/… to the right recipients,
|
|||
with a message adapted to the recipient
|
|||
- process events (needs polish):
|
|||
actions ---> events ---> event filter ---> alert ---> media (mail/jabber/…)
|
|||
| /|\ /|\
|
|||
| | |
|
|||
\|/ | |
|
|||
log \------------------- admin prefs
|
|||
- custom rules are needed to filter useful events
|