chore(docs): update new datasource developer docs #5715
Conversation
github-actions
bot
added
the
documentation
blackboxsw
force-pushed
the
docs-ds-development
branch
2 times, most recently
from
1909fb9
to
77ec8c1
Compare
Use links instead of :file: for repo-local files to ensure CI validates linkcheck on those files in the event that upstream changes their names or location in the future. Reorder ds-identify docs above python DataSource module as the python module needs to reflect the same ds-identify detection logic in a ds_detect module. Add that ds-identify does rely on identification alternatives to DMI such as attached device labels, kernel command line and virt type. Add example reference to simple NWCS datasource commit for ds-identify docs.
blackboxsw
force-pushed
the
docs-ds-development
branch
from
77ec8c1
to
bbc8ec8
Compare
| Update ``ds-identify`` | ||
| ---------------------- | ||
|
|
||
| In ``systemd`` systems, ``ds-identify`` is used to detect which datasource |
There was a problem hiding this comment.
Added mention of Alpine and BSD too as this is broader than just systemd nowadays
| Use one of the simpler datasources such as ``DataSourceHetzner`` as a guiding | ||
| template for style and expectations. The DataSource module should implement a | ||
| ``ds_detect`` method validates the same identification conditions defined | ||
| in ds-identify and returns ``True`` when met. This allows cloud-init to support |
There was a problem hiding this comment.
@blackboxsw add netv2 discussion here. from Alberto
There was a problem hiding this comment.
I do not see changes covering this. Maybe they got mangled by some git operation?
| Update ``ds-identify`` | ||
| ---------------------- | ||
|
|
||
| In ``systemd``, Alpine and BSD environments, ``ds-identify`` runs in early boot |
There was a problem hiding this comment.
I think we can skip the bit about systemd, alpine and bsd environments. I would be very surprised if a new datasource doesn't support any OS that uses ds-identify.
|
|
||
| Each cloud platform must positively identify itself to the guest. This allows | ||
| the guest to make educated decisions based on the platform on which it is | ||
| running. On the x86 and arm64 architectures, many clouds identify themselves | ||
| through `DMI`_ data. For example, Oracle's public cloud provides the string | ||
| ``'OracleCloud.com'`` in the DMI chassis-asset field. | ||
| ``'OracleCloud.com'`` in the DMI chassis-asset field. Some platforms present | ||
| attached devices with well known filesystem label, kernel command line flags or |
There was a problem hiding this comment.
Either
| attached devices with well known filesystem label, kernel command line flags or | |
| attached devices with a well known filesystem label, kernel command line flags or |
or
| attached devices with well known filesystem label, kernel command line flags or | |
| attached devices with well known filesystem labels, kernel command line flags or |
right?
| to detect which datasource should be enabled, or if ``cloud-init`` should run | ||
| at all. You'll need to add early identification support for the platform via a | ||
| ``dscheck_<CloudPlatform>`` function in `tools/ds-identify`_. | ||
| For example, see `NWCS support`_ |
There was a problem hiding this comment.
| For example, see `NWCS support`_ | |
| For example, see `NWCS support`_. |
| Add datasource module cloudinit/sources/DataSource<CloudPlatform>.py | ||
| -------------------------------------------------------------------- | ||
|
|
||
| We suggest you start by copying one of the simpler datasources | ||
| such as ``DataSourceHetzner``. | ||
| Use one of the simpler datasources such as ``DataSourceHetzner`` as a guiding |
There was a problem hiding this comment.
| Use one of the simpler datasources such as ``DataSourceHetzner`` as a guiding | |
| Use one of the simpler datasources, such as ``DataSourceHetzner``, as a guiding |
| Use one of the simpler datasources such as ``DataSourceHetzner`` as a guiding | ||
| template for style and expectations. The DataSource module should implement a | ||
| ``ds_detect`` method validates the same identification conditions defined | ||
| in ds-identify and returns ``True`` when met. This allows cloud-init to support |
There was a problem hiding this comment.
I do not see changes covering this. Maybe they got mangled by some git operation?
|
Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close. If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging TheRealFalcon, and he will ensure that someone takes a look soon. (If the pull request is closed and you would like to continue working on it, please do tag TheRealFalcon to reopen it.) |
github-actions
bot
added
the
stale-pr
Adding a bit more context to new datasource developer docs having mentioned a few of these details in review suggestions on new datasource additions for WSL, CloudCIX and Aeza.net.
Proposed Commit Message
Additional Context
Test Steps
tox -e doc
xdg-open doc/rtd_html/development/datasource_creation.html
Merge type