Education using FIRE

Editor's Notes

• #11: Fire facilities
• #12: Created/operated/maintained via research projects , EU funding
• #13: In this example an experimenter has developed a mechanism to automatically create a wifi mesh network (multi-hop network). The experimenter wants to test this at a larger scale, hoping to proof that the new solution can easily forward multiple streams at the same time without sacrificing any performance.
• #14: As mentioned in the previous slide, there are 3 types of experimenter tools supported, and for each of them the experimenter has several options to choose from because we adopted 3 APIs in the Fed4FIRE architecture. For resource discovery, reservation and provisioning, the experimenter can choose to use the Fed4FIRE portal, Flack, Omni and SFI. All these tools use the SFA interface to talk to the specific testbed management components (called Aggregate Managers). For Experiment control, the experimenter can run its own instance of an experiment controller. This can be the OMF6 Experiment Controller, or NEPI. The user can also directly log in on the nodes using its local SSH client, and perform experiment control actions manually using the console on the resource. For measurement and monitoring, the experimenter can use several OML tools: filters, persistence tools (store in SQL database) and visualization tools. In case of experiment measurement, these tools will use OML streams that are directly originating from the OML measurement library component that is deployed on the resource. For facility and infrastructure monitoring, the testbed will wrap its existing monitoring infrastructure (being Nagios, Zabbix or Collectd) in an OML stream, which will be used by the OML experimenter tools. To support all these tools, it is required that testbeds expose their management software through the SFA interface, that they deploy OMF6 experiment contorl on their testbed, and that they provide one of the mentioned monitoring frameworks and wrap its output in OML streams. On the resources three agents have to be deployed: an OMF resource controller, an OML measurement library and the appropriate monitoring agent that corresponds with their adopted monitor framework.
• #16: Demo the course, Show iPad Show learning locker
• #34: Deployed anytime ; taught anywhere
• #35: Experiment on wilab for actual wireless nodes + web interface also as an experiment on other facility to make it all dynamic
• #36: As mentioned in the previous slide, there are 3 types of experimenter tools supported, and for each of them the experimenter has several options to choose from because we adopted 3 APIs in the Fed4FIRE architecture. For resource discovery, reservation and provisioning, the experimenter can choose to use the Fed4FIRE portal, Flack, Omni and SFI. All these tools use the SFA interface to talk to the specific testbed management components (called Aggregate Managers). For Experiment control, the experimenter can run its own instance of an experiment controller. This can be the OMF6 Experiment Controller, or NEPI. The user can also directly log in on the nodes using its local SSH client, and perform experiment control actions manually using the console on the resource. For measurement and monitoring, the experimenter can use several OML tools: filters, persistence tools (store in SQL database) and visualization tools. In case of experiment measurement, these tools will use OML streams that are directly originating from the OML measurement library component that is deployed on the resource. For facility and infrastructure monitoring, the testbed will wrap its existing monitoring infrastructure (being Nagios, Zabbix or Collectd) in an OML stream, which will be used by the OML experimenter tools. To support all these tools, it is required that testbeds expose their management software through the SFA interface, that they deploy OMF6 experiment contorl on their testbed, and that they provide one of the mentioned monitoring frameworks and wrap its output in OML streams. On the resources three agents have to be deployed: an OMF resource controller, an OML measurement library and the appropriate monitoring agent that corresponds with their adopted monitor framework.
• #43: The problem is that there are different testbeds with each their management software, Experiment description : FULL description of entire configuration + FLOW of experiment + measurements definition -> Easier to re-run experiments under different environment + show scientific relevance by including entire description of the experiment + easier to compare results!
• #52: The FORGE project launches an Open Call as continuous open access to the FORGE tools, meaning that no strict procedures for proposal submission and evaluation will be applied. The call offers free access to the FORGE tools and processes. The open call will apply a fast submission process based on a simple proposal template. In addition, the collaboration of successful participants with the FORGE project will be formalised with a lean Memorandum of Understanding (MoU); therefore the administrative burden for proposers is limited, since there will be no Grant Agreement, no Consortium Agreement and no official deliverables. The FORGE consortium will provide support to the interested users throughout the development of their courses, covering guided training and technical assistance. Moreover, the participants will be acknowledged as associate partners and will receive wide recognition and high visibility through the project’s website. Participants from successful proposals within this call will not receive EC funding and will not become official partners in the FORGE project.