|
|
|
misc:
|
|
- rename schedule_task to schedule_job, as the <task> argument is not a DSL::Task
|
|
or transform it into a real task
|
|
|
|
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
|