DuckCorp » CyborgHood

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