isabelcosta / sesdad Goto Github PK

Related to #11

Should execute every single command in the script

Additional command (only for script):

• Wait x ms - This command instructs the pupper master to sleep for x milliseconds
  before reading and executing the following command in the script file

Processes should not receive orders from Puppet Master while they're in freeze/unfreeze state

Procedure:

• Freeze state
  • Flags the service to freeze = true
  • for each remote method:
    if not in freeze state executes order
    else adds instruction and args to vector in order
• Unfreeze state
  • Flags the service to freeze = false
  • calls remote invocation to execute all orders awating in vector in order

Should have a Single Puppet Master mode.

• Master should receive a special argument: -SingleCommand

Only one puppet controls the system.

• Master URL: tcp://:30000/puppet
• Slaves URL: tcp://:3000[siteID]/puppet
• Have special mode to test only with Puppet Master (Master)
• Slaves start their own machines in full testing mode
• Slaves send logs to Master

Related to #16

All events published with FIFO order guarantee by a publisher P are delivered in the same order according to which P published them.

• option available for configuration file

Nodes processes like brokers, publishers and subscribers should run within threads for better performance.

Do a parser method of single input commands given to the Puppet Master GUI.

• Subscriber processname Subscribe topicname
• Subscriber processname Unsubscribe topicname
• Publisher processname Publish numberofevents Ontopic topicname Interval x ms
• Status
• Crash processname
• Freeze processname
• Unfreeze processname

Problem

• The basic architecture described above has the disadvantage that, if a broker fails, the entire system stops operating, because events can no longer be routed from publishers to providers.
  The fault-tolerant variant of the architecture aims at overcoming this limitations.

Objective

• In this version of the system, 3 brokers are assigned to each site. This should ensure that a site remains operational in face of the failure of a single broker at each site. Note 3 that, in the fault-tolerant version, sites are still organised in a tree. However, a broker at a site can now connect to one or more of the 3 servers that may be operational in its parent site. Similarly, a broker may connect to more than one broker at each of its children sites.
• Finally, publishers and subscribers may connect to any of the brokers in their site. In case of failures, the system should reconfigure automatically, without disrupting the reliable stream of events. For instance, if the broker to which a publisher is connected crashes, the publisher should automatically reconnect to another broker at its site and subscribers should receive, nevertheless, all the events in the order by which they have been sent.
• The students are free to use the replication technique they feel more appropriate to solve the problem at hand. Also, the students are encouraged to use techniques that may leverage from the availability of different brokers to perform some load balancing whenever possible.

All events published with total order guarantees are delivered in the same order at all matching subscribers. More formally, if two subscribers s1, s2 deliver events e1, e2, s1 and s2 deliver e1 and e2 in the same order. This ordering property is established on all events published with total order guarantee, independently of the identity of the producer and of the topic of the event.

Related to #2

Manual script to run on command line.

• Asks for number os puppets

Tasks:

• Create PuppetMaster Console/GUI #1
• LoggingLevel #6
• Parse single commands #11
• Parse a script file #12
• Communication among master and slaves #13

Explanation of algorithms

• Event Routing
  • Flooding
  • Filtering
• Ordering
  • Total Order
  • FIFO

Fault-Tolerant Architecture
Distributed Experience with laptops

Format in configuration file:

Ordering NO | FIFO | TOTAL

• Total order #9
• FIFO order #8
• No ordering #7

Format used in configuration file:

LoggingLevel full | light

• default level: light;
• full: all events described above should be included in the log;
• light: the forwarding of events by the brokers need not be included in the log
  and therefore the brokers need not notify the PuppetMaster of those events;
• Same as full mode without the BroEvents

Related to story: #2 PuppetMaster

Fifo manager is keeping an entry even if it is the last message of the flow
Solution
When verifying the Fifo manager:

• If the number of the next message is equal or higher than the total of the respective flow then delete that entry

No guarantee is provided on the order of notification of events.

• option available for configuration file

• In this approach events are broadcast across the tree.
• This is the default routing policy.

A resolver

• Brokers não conseguem adicionar brokers, esta em ciclo infinito
• Brokers não estão a verificar se o subscriber esta subscrito, apenas reencaminham
• PuppetMaster ainda não é o responsável por criar os processos
• Processos ainda não têm ID
• ...

Format in configuration file:

RoutingPolicy flooding | filter

• Flooding #3 - events are broadcast across the tree.
• Filter #4 - events are only forwarded only along paths leading
  to interested subscribers

• Events are only forwarded only along paths leading
  to interested subscribers. To this end, brokers maintain information regarding which
  events should be forwarded to their neighbours.