Project

General

Profile

Download (7.42 KB) Statistics
| Branch: | Tag: | Revision:

misc:
- rename schedule_task to schedule_job, as the <task> argument is not a DSL::Task
or transform it into a real task
- remove I18nTranslation includes in the core to be able to unload i18n.rb
completely when no i18n support is needed in this cyborg
- could help get the bot class/model before it is instanciated
b.cyborg_model do
raise CyberError.new(:grave, "cyborg_init", "no model defined for this cyborg")
end

all bots:
- API:
* list manipulators:
+ /? -> search(<criterias>)
+ /+ -> create(<data>)
+ /- -> delete(<name>)
* 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
- code to share for I18n:
def prefered_language(available_languages)
lang_chooser = HTTPHeaders::AcceptLanguage.parse(self.preferredLanguage)
return nil if lang_chooser.nil?
ordered_list = lang_chooser.reduce(available_languages)
ordered_list.empty? ? nil : ordered_list.first.range
end
- leaf node feature: declare a node as leaf and pass all other node elements as parameters
- list node detection: when no on_request is specified, list of children nodes are given,
back, which could be very useful for auto-completion on the future CLI interface, but
we need to know when a real action is to be run, to avoid completion triggering them

Clerk:
- API:
/Command/* -> execute a command, each part being a node element:
+ needs leaf node feature
+ how to handle refs? (like in "DO SOMETHING FROM @1 TO @2")
preserving refs and giving objects via a parameter Hash seems a good solution
is the leaf node feature really needed?
/Batch(<script>, <parameters>) -> store a batch of commands (array of strings? array
of arrays of strings?) and parameters (hash), execute them, and later send a report
to the sender bot
- command description useful for shell-based IHM

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
- detect available backends instead of having an enum in the config schema

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:
- default error handler to avoid repeating on_error blocks with the
same code
- inheritance: thread data (auth token, I18n prefs…)
- 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

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
(2-2/10)