Project

General

Profile

« Previous | Next » 

Revision dd170ff9

Added by Marc Dequènes over 13 years ago

  • ID dd170ff94b02ee40893bf7a99e283950938fed6c

[-] added dev ideas

View differences:

IDEAS
Tasks:
- 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
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…)
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

Also available in: Unified diff