Meta Tool RPC Communication Master Slave

[na-oma]

_getwork:

• Task
  • Level
  • Seed
  • Constraints (Zeit, Cores, ...?)
• Version
  • git hash or tag

_submitwork:

• Task
• Version
• Solution
  • output

Can we pickle peewee Model Objects? We could do evaluation of solutions on Slave and send it over the wire or central on Master before entering in DB. If evaluating is not too expensive, Master is better, easier to change/extend evaluation method.

[tilsche]

I think its safe to assume that evaluation is cheap and near instant. Otherwise the organizers would have a big problem... I would do all evaluation exclusively on the master.

[na-oma]

Der Roundtrip:

• jemand pusht neuen GIT tag
• Master: work wird automatisch geadded für neuen Tag in Q
• Slave: work kann geholt werden
• _missing_: Slave [work holen, GIT Pull, Build, Exec]
• Slave: completed work kann submitted werden
• Master: evaluate solution + add to db

geht jetze, bis auf das kleine ding da in der mitte. Hab sogar geschafft XML zu nutzen, damit der Buzzwordcounter nicht stehenbleibt.

[tilsche]

In welchem branch ist das?

XML :( War JSON etwa alle?

[na-oma]

Branch: icfpc_metatool git.py und work*.py ist dir aber bestimmt zu hässlich ;) Werd das dashboard auch bald reinmergen.

XMLRPC ist in der python stl, daher hab ich das für rpc genommen. Gibt noch mehr Möglichkeiten für rpc, sicher cooler: http://stackoverflow.com/questions/1879971/what-is-the-current-choice-for-doing-rpc-in-python