2023.1 Series Release Notes

2023.1-eom

New Features

  • Complete VGPU management feature. VGPU driver is nvidia_gpu_driver same as PGPU driver. The GPU devices configration is same as Nova side, the difference is we delete mdev when the vm is destroy and assign VGPU trait to create vm.

Bug Fixes

  • Fix the api-ref docs of moving device_profile_uuid parameter from path to body in create and get device_profile api.

9.0.0

New Features

  • Add the Xilinx FPGA driver. Through this driver Cyborg can manage Xilinx FPGA devices, including discovering devices’ info and programming xclbin.

  • Add ARQ_UNBIND_FAILED status for Accelerator Requests (arq) unbind process. Nowdays the status is needed to accurate record the arq status.

Upgrade Notes

  • In zed cycle, OpenStack projects and oslo lib has dropped the py3.6 and py3.7 support [1], Cyborg also not supporting the py3.6 and py3.7, Cyborg master is failing and cannot be run on py3.6|7 env. So from Zed release, we will remove py3.6 and py3.7 env.

8.0.0

New Features

  • Changed device_profile_uuid to device_profile_name_or_uuid in Get One Device Profile API path, so it can support getting one device profile by its name since microversion 2.2, not just uuid.

    • GET /v2/device_profiles/{device_profile_name_or_uuid}

7.0.0

New Features

  • Bug 1928174 is cleaned the old device trait on reporting data. the trait will be removing succesfully if no rp uses, otherwise placement will raise 409 exception.

6.0.0.0rc1

New Features

  • The Inspur NVMe SSD driver provides the discover and report proposal of Inspur NVMe SSD disks, then we can use these disks binding and unbinding with VM like PGPU to accelerator the io rate for the VM. The Inspur NVMe SSD doesnot support virtualization, one disk can be only bind to one VM.

  • The Intel nic driver defines the Intel x710 NIC’s data model in Cyborg. It also proposes a standard configuration format to manage networking related devices. The Intel X710 NIC supports DDP(Dynamic Device Personalization) which provides the ability to reconfigure the packet processing pipeline to support a broader range of traffic types. It also supports SR-IOV technology, each physical card can be virtualized into mulitiple VFs.

  • In the Victoria release, cyborg introduced the new scoped RBAC policy authorization for API access, and partially implemented the blueprints. What implemented are new default rules in base policy and device_profile policy.

    During the development period(victoria and wallaby releases), the new and old policy will both work because a deployment sets cyborg.conf [oslo_policy] enforce_scope = False as the default set. Although users can set cyborg.conf [oslo_policy] enforce_scope = True by default in their deployment, if they want to ignore old rules and support new rules only. After we implement all the features, we’ll give two cycles transition period for operators. For specification of new policy, please refer to policy default refresh.

    • Scope

      Cyborg introduced scope_type to protect each policy. Cyborg support two types of sope_type with their combination. ['system'], ['project'] and ['system', 'project'].

      To know each policy scope_type, please refer the Policy Reference

      This feature is disabled by default can be enabled via config option [oslo_policy]enforce_scope in cyborg.conf

      • New Defaults Configuration

      Policies are default to Admin, Member and Reader roles. Old roles are also supproted. You can switch to new defaults via config option [oslo_policy]enforce_new_defaults in cyborg.conf file.

    • New Base policy roles

      Cyborg introduced seven basic roles based on the new defaults combined with different scope_types.

      • project_reader

      • project_member

      • project_admin

      • system_admin

      • system_reader

      • system_admin_or_owner

      • system_or_project_reader

    • New Defaults for device_profile APIs

      Rewrite check string(authorization rules) using new personas for device profile APIs.

      Add checkstr=base.PROJECT_READER_OR_SYSTEM_READER and deprecated checkstr=base.deprecated_default for

      • cyborg:device_profile:get_one

      • cyborg:device_profile:get_all

      Add check_str=base.SYSTEM_ADMIN and deprecated check_str=base.deprecated_is_admin for

      • cyborg:device_profile:create

      Add check_str=base.SYSTEM_ADMIN and deprecated base.deprecated_default for

      • cyborg:device_profile:delete

    • Added policy configuration guide on cyborg doc page

      Please refer to policy configuration guide

Upgrade Notes

  • The default value of [oslo_policy] policy_file config option has been changed from policy.json to policy.yaml. Cyborg policy new defaults since 5.0.0 and current default value of [oslo_policy] policy_file config option (policy.json) does not work when policy.json is generated by oslopolicy-sample-generator tool. Refer to bug 1875418 for more details. Also check oslopolicy-convert-json-to-yaml tool to convert the JSON to YAML formatted policy file in backward compatible way.

Deprecation Notes

  • The old basic personas below are marked as deprecated rules in base policy.

    • public_api

    • allow

    • deny

    • admin_api

    • is_admin

    • admin_or_owner

    • admin_or_user

5.0.0.0rc1

New Features

  • Add programming method to Deployable API. This method supports dynamic programming of Intel FPGAs. And it requires Intel OPAE(Open Programmable Acceleration Engine).

  • Add project_id for Accelerator Requests (arq) PATCH API from microversion 2.1 in order to control operations of accelerator requests with different roles.

  • The inspur-fpga-driver-proposal spec provides the first proposal of an inspur fpga driver. Currently only discover operation is supported, the program function and virtualization will be supported in Wallaby.

  • The cyborg-intel-qat-driver-proposal spec defines the Intel QAT accelerator driver managed by Cyborg. Intel QAT card is an accelerator that can accelerate encrytion and compression/decompression operation in data center. It also support SR-IOV technology, each physical card can be virtualized into mulitiple VFs.

Upgrade Notes

  • cyborg.image.download.modules extension point and support for allow_direct_url_schemes configuration setting, which have been deprecated since the Queens release, have been removed.

Deprecation Notes

  • Intel OPAE driver dependency is removed from the devstack installation dependencies due to the following reasons: 1) In the kolla cyborg-agent image we install OPAE, but OPAE is not available for CentOS 8 for the moment. This will make the cyborg-agent image unbuildable in Ussuri. 2) In devstack, due to the fact that OPAE packages depend on libjson0, which is not available after Ubuntu 16.04, so cyborg can’t be installed on Ubuntu higher than 16.04 now(unless disable dependency manually). Moreover,from cyborg’s perspective, it does not need to contain any hardware driver dependency, we can assume the admin should know about it and install the correct version.

4.0.0

New Features

  • Add description as a column of the device_profiles table in the device profile to allow end users to set some descriptions for the device profile when creating a device profile.

  • Cyborg now supports microversion in order to allow changes to the API while preserving backward compatibility. User requests must include an HTTP header OpenStack-API-Version: accelerator 2.0 which is a monotonically increasing semantic version number starting from 2.0. If that header is absent, the request defaults to the default microverison 2.0.

Security Issues

  • Introduce bandit check as the code security check, which can help us avoid possible security issues. For example, shell-related operations for drivers may be insecure. With bandit test, it can check the potential security issues.

Other Notes

  • Drop support for python2 as per this message

3.0.0

Security Issues

  • Privsep transitions. Cyborg is transitioning from using the older style rootwrap privilege escalation path to the new style Oslo privsep path. This should improve performance and security of Cyborg in the long term.

  • Privsep daemons are now started by Cyborg when required. These daemons can be started via rootwrap if required. rootwrap configs therefore need to be updated to include new privsep daemon invocations.

  • Use oslo.privsep instead of subprocess to execute sudo related shell operations can prevent shell injection attacks.

2.0.0

Prelude

Added new tool cyborg-status upgrade check.

New Features

  • New framework for cyborg-status upgrade check command is added. This framework allows adding various checks which can be run before a Cyborg upgrade to ensure if the upgrade can be performed safely.

Upgrade Notes

  • Operator can now use new CLI tool cyborg-status upgrade check to check if Cyborg deployment can be safely upgraded from N-1 to N release.

0.1.0

New Features

  • The cyborg framework consists of three core services - API, Conductor and Agent. cyborg-api supports GET/POST/PUT/DELETE operations for accelerators. cyborg-conductor is responsible for handling all API requests that come in via the API service. cyborg-agent is responsible for all the Nova Cyborg interaction. It should be noted that for operations that are not associated with DB change, the cyborg-api could directly call cyborg-agent.

  • Cyborg-Nova interaction was completed in Queens via three specs. The cyborg-nova-interaction spec serves as the main spec defines the interaction mechanism between Cyborg and Nova is via Placement to which cyborg-conductor will periodically report the accelerator resource info, which is acquired via resource tracker functionality in the agent. The cyborg-internal-api spec defines the internal api that is mainly used for internal communication between conductor/agent and driver. The cyborg-fpga-model-proposal spec defines the first tryout of data modeling of accelerator resources via resource provider. Two types of tables (accelerator for base PF and deployable for VF) are defined there and nested resource provider will be utilized in Rocky release.

  • The cyborg-fpga-driver-proposal spec provides the first proposal of a cyborg fpga driver. Two operations are supported - discover and program, although the latter was not finished in Queens and will be in Rocky. The code implementation starts with an Intel FPGA card, but more vendor card support should be added later and the driver support should be generalized.

  • The cyborg generic driver provide a full implementation of CRUD operations, for testing purpose only. This is only an examplary implementation of a driver which specific accelerator driver could refer to.

  • The cyborg-spdk-driver-proposal spec defines the first software accelerator driver managed by Cyborg. SPDK is widely used in NVMe SSD user space driver to have a high performance. In Queens only basic operations on SPDK (discover, list, construct/delete subsystem for NVMeOF devices, add/delete ip address for vhost) are supported, more completed operation support should be expected in the next couple releases.