From: Daniel Gomez <da.gomez@kernel.org>
To: Luis Chamberlain <mcgrof@kernel.org>,
Chuck Lever <cel@kernel.org>, Daniel Gomez <da.gomez@kruces.com>,
kdevops@lists.linux.dev
Cc: hui81.qi@samsung.com, kundan.kumar@samsung.com
Subject: Re: [PATCH v3 2/3] declared_hosts: add support for pre-existing infrastructure
Date: Wed, 3 Sep 2025 11:02:59 +0200 [thread overview]
Message-ID: <b1b4c06a-2f67-4548-b21a-c6bcadefd74a@kernel.org> (raw)
In-Reply-To: <20250902235356.639271-3-mcgrof@kernel.org>
On 03/09/2025 01.53, Luis Chamberlain wrote:
> This adds support for using pre-existing infrastructure (bare metal servers,
> pre-provisioned VMs, cloud instances) that users already have SSH access to,
> bypassing the kdevops bringup process.
>
> We borrow the DECLARE_* foo practice from the Linux kernel to ensure the
> user will declare the hosts they already have set up with:
>
> make DECLARE_HOSTS="foo bar" defconfig-foo
> or
> make DECLARE_HOSTS="foo bar" menuconfig
>
> We just skip the data partition setup, at the role level. The user
> is encouraged to set DATA_PATH if they want something other than /data/
> to be expected to be used. The onus is on them to ensure that the
> DATA_PATH works for the user the the host is configured to ssh access
> to already.
>
> Currently no workflows are fully supported with declared hosts.
> Each workflow requires individual review and testing to ensure proper
> operation with pre-existing infrastructure before being enabled.
>
> Generated-by: Claude AI
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
...
> diff --git a/kconfigs/Kconfig.declared_hosts b/kconfigs/Kconfig.declared_hosts
> new file mode 100644
> index 00000000..cfdae8fa
> --- /dev/null
> +++ b/kconfigs/Kconfig.declared_hosts
> @@ -0,0 +1,71 @@
> +# Configuration for declared hosts that skip bringup process
> +
> +config KDEVOPS_USE_DECLARED_HOSTS
> + bool "Use declared hosts (skip bringup process)"
> + select WORKFLOW_INFER_USER_AND_GROUP
> + output yaml
> + help
> + Enable this option to use pre-existing hosts that you have already
> + configured with SSH access. This is useful for:
> +
> + * Bare metal systems
> + * Pre-provisioned VMs or cloud instances
> + * Systems managed by other infrastructure tools
> +
> + When this option is enabled:
> + - SSH keys will not be generated (assumes you already have access)
> + - Bringup and teardown operations will be skipped
> + - User and group settings will be inferred from the target hosts
> + - You must provide the list of hosts in KDEVOPS_DECLARED_HOSTS
> +
> + This option automatically:
> + - Selects WORKFLOW_INFER_USER_AND_GROUP to detect the correct
> + user and group on the target systems
> + - Assumes SSH access is already configured
> +
> +if KDEVOPS_USE_DECLARED_HOSTS
> +
> +config KDEVOPS_DECLARED_HOSTS
> + string "List of declared hosts"
> + output yaml
> + default "$(shell, echo ${DECLARED_HOSTS})"
> + default ""
> + help
> + Provide a list of hostnames or IP addresses for the pre-existing
> + systems you want to use. These hosts must already be accessible
> + via SSH with the appropriate keys configured.
> +
> + Format: Space or comma-separated list
> + Example: "host1 host2 host3" or "host1,host2,host3"
> +
> + These hosts will be used directly without any bringup process.
> + Make sure you have:
> + - SSH access configured
> + - Required packages installed
> + - Appropriate user permissions
> +
> +config KDEVOPS_DECLARED_HOSTS_PYTHON_INTERPRETER
> + string "Python interpreter path on declared hosts"
> + default "/usr/bin/python3"
> + output yaml
> + help
> + Specify the path to the Python interpreter on the declared hosts.
> + This is required for Ansible to function properly.
> +
> + Common values:
> + - /usr/bin/python3 (most modern systems)
> + - /usr/bin/python (older systems)
> + - /usr/local/bin/python3 (custom installations)
Isn't this redundant?
In the hosts template files, this patch does this:
ansible_python_interpreter = "{{ kdevops_declared_hosts_python_interpreter | default(kdevops_python_interpreter) }}"
I think, using the kdevops_python_interperter config/yaml directly should be
sufficient. Or what I am missing?
next prev parent reply other threads:[~2025-09-03 9:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 23:53 [PATCH v3 0/3] declared hosts support Luis Chamberlain
2025-09-02 23:53 ` [PATCH v3 1/3] gen_hosts: use kdevops_workflow_name directly for template selection Luis Chamberlain
2025-09-02 23:53 ` [PATCH v3 2/3] declared_hosts: add support for pre-existing infrastructure Luis Chamberlain
2025-09-03 9:02 ` Daniel Gomez [this message]
2025-09-02 23:53 ` [PATCH v3 3/3] minio: add MinIO Warp S3 benchmarking with declared hosts support Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1b4c06a-2f67-4548-b21a-c6bcadefd74a@kernel.org \
--to=da.gomez@kernel.org \
--cc=cel@kernel.org \
--cc=da.gomez@kruces.com \
--cc=hui81.qi@samsung.com \
--cc=kdevops@lists.linux.dev \
--cc=kundan.kumar@samsung.com \
--cc=mcgrof@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox