Remove automatic assignment of gpu label

Bug #1849326 reported by Brent Rowsell
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
StarlingX
Fix Released
High
Ran An

Bug Description

The following commit, https://review.opendev.org/#/c/666511/ automatically add the intelgpu label to any host that has a intel gpu.

This is incorrect. The decision whether to leverage the device on the host needs to be a user decision not the system. Please remove the automated assignment of the labels.

Revision history for this message
Ghada Khalil (gkhalil) wrote :

Marking as stx.3.0 / high priority as this needs to be resolved asap so that the QAT & FPGA feature code can be updated and merged as this code builds on the same premise.

This was somehow missed during the code review phase.

Changed in starlingx:
importance: Undecided → High
status: New → Triaged
tags: added: stx.3.0 stx.config
Changed in starlingx:
assignee: nobody → Ran An (an.ran)
Revision history for this message
Ran An (an.ran) wrote :

Hi Brent,
according to commit https://review.opendev.org/666511/, the label "intelgpu: enabled" will only be assigned to nodes if all of the following conditions are met:
1. the user deployed intel-gpu-plugin daemon set. (override "k8s_plugins" adding "intel-gpu-plugin:intelgpu=enabled").
2. the nodes was detected intel gpu.

I think the first condition has already met your requirement.

Changed in starlingx:
status: Triaged → Invalid
Revision history for this message
Brent Rowsell (brent-rowsell) wrote :

I do not agree. The commit blindly assumes that the user would want to make gpu's on any server available to k8s. The user has to be given the opportunity to explicitly declare which servers they wish to deploy with gpu's.

Changed in starlingx:
status: Invalid → Triaged
Revision history for this message
Ran An (an.ran) wrote :

If the user here means "normal users" (K8S tenants), they can choose to require the GPU resource or not in their pod YAML (of "application" workloads). It doesn't mean they have the permission of deciding whether or not the node with the GPU plugin should be enabled by the label.

------------------------------------------------------------------------------
On the other hand, if user here you meant "sysadmin", yes, we can modify this patch so that sysadmin can do it manually based on his/her needs.

Revision history for this message
Brent Rowsell (brent-rowsell) wrote :

It is up to the user (system administrator) to assign label to the nodes they want to assign gpu workloads to.

Revision history for this message
Ran An (an.ran) wrote :

1. Currently, the system administrator could remove the label by cmd "system host-label-remove" if he/she want to keep a node away from gpu workloads.
Does this meet the requirement?

2. for the labels of device plugins, following checks are required before they are assigned to nodes:
  1). ensure the node support specify HW.
  2). ensure the system support specify device plugin.

if we don't check and assign plugin labels at provisioning time (automatically), we need to add a new sysinv command for the administrator to do above checks before assign k8s label to node.

Revision history for this message
Matt Peters (mpeters-wrs) wrote :

In addition to the undesired operational behavior, there are technical issues with the current implementation. Currently /etc/platform/enabled_kube_plugins is only set at bootstrap, which means it will only be created on the bootstrap controller. A switch of activity to the other controller will have the sysinv-conductor running on controller-1 and will therefore not automatically label any additional nodes.

Furthermore, the user will not be able to suppress the label configuration as you describe above because a restart of the sysinv-agent will trigger any removed labels to be repopulated.

Revision history for this message
Ran An (an.ran) wrote :

thanks for Matt's comment, it make sense. I'll remove the automatic label assign.

in addition, it would solve the file sync issue if file "enabled_kube_plugins" is set under path "/opt/extension/" (a drbd path), right?

Revision history for this message
Matt Peters (mpeters-wrs) wrote :

Yes a DRBD path would be replicated and available on the active controller.

Revision history for this message
Ghada Khalil (gkhalil) wrote :

Hi Ran, can you please put up the review for this as soon as possible? We would like this code simplification to go in so that the QAT and FPGA code changes are updated accordingly before they merge.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to config (master)

Fix proposed to branch: master
Review: https://review.opendev.org/691699

Changed in starlingx:
status: Triaged → In Progress
Revision history for this message
Ran An (an.ran) wrote :

Hi Ghada, based on committed patch above, there are no changes of QAT&FPGA codes in sysinv (getting plugin labels part).

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ansible-playbooks (master)

Fix proposed to branch: master
Review: https://review.opendev.org/691801

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to config (master)

Fix proposed to branch: master
Review: https://review.opendev.org/693222

Revision history for this message
Ghada Khalil (gkhalil) wrote :

Based on discussion with Ran during the community meeting on 11/6, the immediate focus will be on the following two commits:
https://review.opendev.org/#/c/693222/ -- revert the automatic addition of labels in sysinv
https://review.opendev.org/#/c/691801/ -- address issues w/ controller swact & restore

As a future enhancement (longer term), https://review.opendev.org/#/c/691699/ will add semantic checks to ensure the user is adding the labels on nodes that actually have the required hardware.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to config (master)

Reviewed: https://review.opendev.org/693222
Committed: https://git.openstack.org/cgit/starlingx/config/commit/?id=93320956b4d150904fc3c988f9ea02619566b3f6
Submitter: Zuul
Branch: master

commit 93320956b4d150904fc3c988f9ea02619566b3f6
Author: SidneyAn <email address hidden>
Date: Thu Nov 7 00:09:45 2019 +0800

    Revert "add support for intel gpu device plugin"

    This reverts commit 023be74256c09ec84dc547443af07a7bc73cce57.
    according to the architectural direction, labels should be
    assigned by user manually instead of automaticly.

    The HW detect and k8s_plugins configuration check which can
    avoid user to assign plugin labels in imporper node will be
    kept as semantic checks of labels.
    it will be implemeted at https://review.opendev.org/#/c/691699/

    Change-Id: I601dc84264864eb5b292edd47f5c53668193f994
    Closes-bug: 1849326

Changed in starlingx:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to ansible-playbooks (master)

Reviewed: https://review.opendev.org/691801
Committed: https://git.openstack.org/cgit/starlingx/ansible-playbooks/commit/?id=52f924b547ae2a50bb6458870ae985907ec81aef
Submitter: Zuul
Branch: master

commit 52f924b547ae2a50bb6458870ae985907ec81aef
Author: SidneyAn <email address hidden>
Date: Tue Oct 29 10:55:19 2019 +0800

    enhance user defined "k8s_device_plugins": support controller switch and system restore

    this commit include following changes:
    1. relocate file "enabled_kube_plugins" on drbd path. file "enabled_kube_plugins"
    record the plugins enabled by administrator which is only set at bootstrap. to avoid
    missing this file after controller switch, it should be set in folder monitored by drbd.

    2. set fact "k8s_plugins" during restore process according to file
    "enabled_kube_plugins" in backup tar file.

    Change-Id: Idea0034516d844f8a6a6772b8f4249fdfba86397
    Partial-bug: 1849326
    Signed-off-by: SidneyAn <email address hidden>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.