Skip to content

Conversation

@doanac
Copy link
Member

@doanac doanac commented Jan 29, 2026

PR Template and Checklist

Please complete as much as possible to speed up the reviewing process.
You may delete items that are not relevant to your contribution.
Readiness and adding reviewers as appropriate is required.

All PRs should be reviewed by a technical writer/documentation team and a peer.
If effecting customers—which is a majority of content changes—a member of Customer Success must also review.

Readiness

  • Merge (pending reviews)
  • Merge after date or event
  • Draft

Checklist

  • Run spelling and grammar check, preferably with linter.
  • Step through instructions (or ask someone to do so).
  • Review for wordiness
  • Match tone and style of page/section.
  • Run make linkcheck, and add redirects for any moved or deleted pages.
  • View HTML in a browser to check rendering.
  • Use semantic newlines.
  • follow best practices for commits.
    • Descriptive title written in the imperative.
    • Include brief overview of QA steps taken.
    • Mention any related issues numbers.
    • End message with sign off/DCO line (-s, --signoff).
    • Sign commit with your gpg key (-S, --gpg-sign).
    • Squash commits if needed.
  • Request PR review by a technical writer and at least one peer.

Comments

Any thing else that a maintainer/reviewer should know.
This could include potential issues, rational for approach, etc.

Signed-off-by: Andy Doan <andy@foundries.io>
Copy link
Contributor

@kprosise kprosise left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestions based on Vale linter feedback and changes to code blocks to have them recognized as console output

@kprosise kprosise requested a review from vanmaegima January 30, 2026 12:50
Copy link
Collaborator

@angolini angolini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only minor comments

==============

Remote actions allow you to execute pre-configured scripts on a device and view the results.
Default LmP builds include:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We usually don't say "LmP builds", I think we say "Target"

@kprosise do we have something on this regard on the style guide?


fioctl devices triggers list-configured <device>

Triggering an action
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

before going to the "triggering", can we have an example of output?

I would also like to see a list of possible actions available with a description. If you think it does not fit the UG, it could include a link to RN

Remote actions are sent to the device using :ref:`ref-fioconfig`.
This means that the action will be run asynchronously and reported once the device has seen and processed the request.
By default, Fioconfig will check in with the server every 5 minutes.
The results of the action will be available from the ``fioctl devices tests`` command.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the results or the status?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the status is part of the results?

How It Works
------------

The remote actions feature is implemented with Fioconfig.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kprosise do we have a glossary term for Fioconfig? For me it feels like missing a cross reference here

The remote actions feature is implemented with Fioconfig.
When Fioconfig starts up, it will look under ``/usr/share/fioconfig/actions`` to find actions it can perform.
This list will be uploaded to the server if/when it changes.
You can see this with::
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't quite understand what you can see? Is it the content of /usr/share/fioconfig/actions? Or what is still local to be uploaded to the server?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the content of the file is shown below in the example output.

| reboot
...

This file lets Fioctl know what actions it can trigger.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"this file" I assume it's /usr/share/fioconfig/actions
lists the actions fioctl can trigger or will trigger? I mean, the possible actions or the actions that are scheduled?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no - the file is shown above fio-remote-actions - its the list of actions found under /usr/share/fioconfig/actions. It is what's possible to trigger. We then cover below how one gets triggered

Co-authored-by: Daiane Angolini <angolini@gmail.com>
Co-authored-by: Katrina Prosise <katrina.prosise@foundries.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants