cray-hpe / docs-csm Goto Github PK

hello, EVERYONE!
I got a AMD MI250X GPU card recently. Obviously it was a part from HPE cray EX235a system.
But I got problem in using it now in ubuntu. Probably no driver suitable in ubuntu?
So, do you have drivers or BIOS that can make my card alive? It is writtern D65201-OB Rev13 on GPU.
THANK YOU SO MUCH!

There are a swathe of instances, throughout the source of these docs,
where "code blocks" are begun with the triple-backtick marker, but
are never closed with a corresponding one.

Whilst appreciating that you can "get away with it" in some rendering
environments, it's rather poor form, and, more importantly, it does
break rendering in some envirtonments, with Jekyll/Liquid being the
one I have been trying to use locally.

Given that there are examples of code block markup where the author
has done the "right thing", it's clearly not some "internal style guide
authoring thing": more likely the result of an ad-hoc approach?

Any chance of fixing this up?

Reason for not forking is that there is just too much of it to clean up!

We can't auto-delete branches via the GitHub repository settings because we need to allow time for backports to be created, and backports require the original branch to exist in order to create.

Use a GitHub action to do this automatically.

Hi

On : Utility Storage
chapter, we have a broken link.

Troubleshoot Pods Failing to Restart on Other Worker Nodes

Regards

We need a .github/CONTRIBUTING.md file, containing details for how another user/developer/maintainer may contribute new content or make amends to existing content.

How will the ./RELEASE_NOTES.md be updated for newer than 1.2 releases (and/or for older)? Ie, will 1.3 info go above the 1.2 info (Text over, full under) or some other process? I'm not seeing other / older release notes in the repo.

This pull-request has not had activity in over ${expiration} days and is being marked as stale.

Originally posted by @github-actions[bot] in #512 (comment)

Compare and contrast the text for getting the SYSTEM_DOMAIN_NAME
in these two sections of the manual:

operations/conman/Access_Console_Log_Data_Via_the_System_Monitoring_Framework_SMF.md

operations/system_management_health/Access_System_Management_Health_Services.md

In the former we read

Determine the external domain name by running the following command on any NCN:

kubectl get secret site-init -n loftsman -o jsonpath='{.data.customizations.yaml}' |
        base64 -d | grep "external:"
      external: SHASTA_EXTERNAL_DOMAIN.com

whilst in the latter, we read

The SYSTEM_DOMAIN_NAME value in the URLs on this page is an Ansible
variable that can be retrieved as follows. It is expected to be the
system’s fully qualified domain name (FQDN).

(ncn-mw#) This command can be run on any master or worker NCN.

kubectl get secret site-init -n loftsman -o jsonpath='{.data.customizations\.yaml}' | base64 -d | grep "external:"

Example output:

      external: SYSTEM_DOMAIN_NAME

The latter makes more sense, as it doesn't presume that
your site will be a dot-com, whilst the addition of that
dot-com in the former might have the uninitiated, and/or
naive, thinking that they have to add a dot-com to any
name that gets returned.

Probably worth taking the text from the latter and replacing
the text in the former with it, so as to be consistent.

FWIW, there's even a third way to do it presented in

operations/package_repository_management/Restrict_Admin_Privileges_in_Nexus.md

but that's so different to the other two as to not cause confusion.

HTH

Need to update some of the manual steps to align with the latest changes for the automatic wipe.

Originally posted by @rustydb in #2014 (comment)

Namely:

• include wiping nvme
• use a for loop to avoid early exists on bulk calls to wipefs where some targets may be skipped

Not so much an "issue" with, as an observation prompting a question on. the text in the file

operations/boot_orchestration/Clean_Up_After_a_BOS-BOA_Job_is_Completed_or_Cancelled.md

We read (my formatting):

ConfigMap for BOA:

This ConfigMap contains the configuration information that the BOA job uses.
The BOA pod mounts a ConfigMap named boot-session at /mnt/boot_session
inside the pod.
This ConfigMap has a random UUID name, such as
e786def5-37a6-40db-b36b-6b67ebe174ee.
This name does not obviously connect it to the BOA job.

however, I am currently im the process of cleaning up four day's
worth of BOS Sessions, created whilst trying to solve an issue
that eventaully appeared to solve itself, and I am constantly seeing
that the ConfigMap's UUID doesn't appear to be random, but in
fact appears to be the same as the BOS Session ID, for example:

# export BOA_JOB_NAME=boa-7a98ae9d-512b-4623-8a90-4d3c6426e5fd
#
# export BOS_SESSION_ID=${BOA_JOB_NAME#boa-}
# echo  $BOS_SESSION_ID
7a98ae9d-512b-4623-8a90-4d3c6426e5fd
#
# kubectl -n services describe job ${BOA_JOB_NAME} | \
  grep -A3 boot-session:
   boot-session:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      7a98ae9d-512b-4623-8a90-4d3c6426e5fd
    Optional:  false
#

so, have I just been "lucky", or has the underlying process been
altered so that the BOS Session ID is now propagated into the
ConfigMap UUID for the BOA ?

In which case the documentation doesn't relect that change.