Skip to content

Mini design for openbmc python framework

Bin Xu edited this page Feb 5, 2018 · 5 revisions

This framework is used to develop the plugin in python to interact with the BMC via REST, it depends on python requests and gevent modules, and leverage coroutions to do things in parallel.

Components

Plugin broker in perl (openbmc2.pm)

  • handle the arguments parsing in preprocess_request and process_request
  • handle dispatching requests to service nodes
  • when handling in process_request, collect enough nodes information and fork python agent, and send the requests to agent; After that, it acts as a broker between xcatd and python agent.

Python Agent

Run as a program and listening on UNIX domain socket file, and then to communicate with openbmc2.pm to get requesting commands and send response.

All codes will be packaged in xCAT-openbmc-py Directory layout for package by run tree xCAT-openbmc-py/lib/python/agent

xCAT-openbmc-py/lib/python/agent
├── agent.py
├── client.py
├── common
│   ├── __init__.py
│   ├── exceptions.py
│   ├── rest.py
│   ├── task.py
│   └── utils.py
├── hwctl
│   ├── __init__.py
│   ├── executor
│   │   ├── __init__.py
│   │   ├── openbmc_power.py
│   │   └── openbmc_setboot.py
│   ├── openbmc_client.py
│   ├── power.py
│   └── setboot.py
└── xcatagent
    ├── __init__.py
    ├── base.py
    ├── openbmc.py
    ├── openbmc_rest.py  (It will be removed)
    └── server.py

4 directories, 18 files

common

This module contains common utils and base classes for run the agent.

hwctl

This module contains all the business logic to process hardware control commands via OpenBMC and later on Redfish, etc. It is composed with three parts:

  • HardWare Control Managers - to define the abstract interface for hw ctl.

    • power.py - responsible to define power management interfaces
    • setboot.py - responsible to define boot target management interfaces
    • ...
  • HardWare Control Executors

    • openbmc_power.py
    • openbmc_setboot.py
    • ...
  • BMC clients

    • openbmc_client.py - to define the atomic API based on one REST API or some tight integrated REST APIs
    • ...

How to implement executors (inherit from ParallelNodesCommand)

Manager will invoke the specified functions defined in executors based on reflection. For example, the interface is get_example, it will invoke a series of functions (when it is defined in executor class) in below order: validate_get_example -> pre_get_example -> get_example -> post_get_example

class OpenBMCExampleTask(ParallelNodesCommand):
    """Executor for example-related actions."""

    def validate_get_example(self, **kw): pass
    def pre_get_example(self, **kw): pass
    def get_example(self, **kw): pass
    def post_example(self, **kw): pass

News

History

  • Oct 22, 2010: xCAT 2.5 released.
  • Apr 30, 2010: xCAT 2.4 is released.
  • Oct 31, 2009: xCAT 2.3 released. xCAT's 10 year anniversary!
  • Apr 16, 2009: xCAT 2.2 released.
  • Oct 31, 2008: xCAT 2.1 released.
  • Sep 12, 2008: Support for xCAT 2 can now be purchased!
  • June 9, 2008: xCAT breaths life into (at the time) the fastest supercomputer on the planet
  • May 30, 2008: xCAT 2.0 for Linux officially released!
  • Oct 31, 2007: IBM open sources xCAT 2.0 to allow collaboration among all of the xCAT users.
  • Oct 31, 1999: xCAT 1.0 is born!
    xCAT started out as a project in IBM developed by Egan Ford. It was quickly adopted by customers and IBM manufacturing sites to rapidly deploy clusters.
Clone this wiki locally