-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOCS-3174: Update machine settings #3930
Conversation
✅ Deploy Preview for viam-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
5360692
to
d56362e
Compare
7aba092
to
8417260
Compare
I haven't had time to properly review this yet, as I'm still trying to get the work this is documenting done first. I believe this doesn't need to go live until the actual changes do though, so I should be able to get to it before that. |
No problem. The docs are also very close to what we merged into the app so if we end up merging this when the changes go live, we can review afterwards too. |
docs/manage/fleet/provision/setup.md
Outdated
@@ -187,7 +187,7 @@ Create a file called <FILE>viam-provisioning.json</FILE> with the following form | |||
"model": "<NAME>", # the machine's model | |||
"fragment_id": "<ID>", # the fragment id, required for mobile app | |||
"hotspot_prefix": "<PREFIX>", # machine creates a hotspot during setup | |||
"disable_dns_redirect": true, # disable if using a mobile app | |||
"disable_captive_portal_redirect": false, # disable if using a mobile app |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
set to true if using a mobile app
or something like that
i think explicit makes it easier to understand. someone reading quickly could interpret that is already disabled
docs/manage/fleet/provision/setup.md
Outdated
| `networks` | array | Optional | Add additional networks the machine can connect to for provisioning. We recommend that you add WiFi settings in the operating system (for example, directly in NetworkManager) rather than in this file, or in the corresponding machine config in the Viam app, if networks aren't needed until after initial provisioning. See [Networks](/manage/reference/viam-agent/#networks). Default: `[]`. | | ||
| `wifi_power_save` | boolean | Optional | If set, will explicitly enable or disable power save for all WiFi connections managed by NetworkManager. | | ||
| `device_reboot_after_offline_minutes` | integer | Optional | If set, `viam-agent` will reboot the device after it has been offline for the specified duration. Default: `0` (disabled). | | ||
| `disable_captive_portal_redirect` | boolean | Optional | By default, ALL DNS lookups using the provisioning hotspot will redirect to the device. This causes most phones/mobile devices to automatically redirect the user to the captive portal as a "sign in" screen. When disabled, only domains ending in .setup (ex: viam.setup) will be redirected. This generally avoids displaying the portal to users and is mainly used in conjunction with a mobile provisioning application workflow. Default: `false`. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder is saying something like this would be a little bit easier to understand
By default (false), all DNS lookups are redirected, which can cause mobile devices to automatically display the portal. When set to true, only DNS requests for domains ending in .setup are redirected, preventing the portal from appearing unexpectedly, specially convenient when using a mobile app for provisioning.
docs/manage/fleet/provision/setup.md
Outdated
| `wifi_power_save` | boolean | Optional | If set, will explicitly enable or disable power save for all WiFi connections managed by NetworkManager. | | ||
| `device_reboot_after_offline_minutes` | integer | Optional | If set, `viam-agent` will reboot the device after it has been offline for the specified duration. Default: `0` (disabled). | | ||
| `disable_captive_portal_redirect` | boolean | Optional | By default, ALL DNS lookups using the provisioning hotspot will redirect to the device. This causes most phones/mobile devices to automatically redirect the user to the captive portal as a "sign in" screen. When disabled, only domains ending in .setup (ex: viam.setup) will be redirected. This generally avoids displaying the portal to users and is mainly used in conjunction with a mobile provisioning application workflow. Default: `false`. | | ||
| `turn_on_hotspot_if_wifi_has_no_internet` | boolean | Optional | By default, the device will only attempt to connect to a single wifi network (the one with the highest priority), provided during initial provisioning/setup using the provisioning mobile app or captive web portal. Wifi connection alone is enough to consider the device as "online" even if the global internet is not reachable. If the primary network configured during provisioning cannot be connected to and `turn_on_hotspot_if_wifi_has_no_internet` mode is enabled, the device will attempt connections to all configured networks in `networks`, and only consider the device online if the internet is reachable. Default: `false`. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to above and because I feel verbose documentation can lead folks to not read.
By default (false), the device connects to a single prioritized WiFi network (provided during provisioning) and is considered online even if the global internet is not reachable. When turn_on_hotspot_if_wifi_has_no_internet is true and the primary network lacks internet connectivity, the device will try all configured networks and only mark itself as online if it successfully connects to the internet.
### `viam-agent` | ||
## `version_control`: Version management for `viam-agent` and `viam-server` | ||
|
||
By default, when a new version of `viam-server` becomes available, `viam-agent` will restart and upgrade `viam-server` immediately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is not accurate. agent will download the new version when available but it will not be used until agent restarts. This is why we introduce maintenance windows so the agent knows when is safe to do it automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line 227 is accurate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but then it would never update until someone eventually power cycles?
Is this accurate?
By default, when a new version of `viam-server` becomes available, `viam-agent` will restart and upgrade `viam-server` immediately. | |
By default, when a new version of `viam-server` becomes available, it will automatically download. | |
When `viam-agent` next restarts, it installs and starts using the new version of `viam-server`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, either restarts viam-server or power cycles
Co-authored-by: Naomi Pentrel <[email protected]>
Co-authored-by: Sierra Guequierre <[email protected]>
🔎💬 Inkeep AI search and chat service is syncing content for source 'Viam Docs (https://docs.viam.com)' |
https://deploy-preview-3930--viam-docs.netlify.app/manage/fleet/system-settings/
https://deploy-preview-3930--viam-docs.netlify.app/manage/reference/viam-agent/