-
Notifications
You must be signed in to change notification settings - Fork 19
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
chore: move lxd related files to lxd_cloud module #254
Conversation
Test coverage for 04a120f
Static code analysis report
|
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.
One comment, otherwise it looks fine to me. I assume that some of the functionality now placed in lxd_cloud
will be extracted into more common modules in the future (e.g. runner_logs
is almost cloud agnostic).
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 think this is independent of the type of cloud, as it is required to schedule reconciliation.
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.
Maybe name the module something like local_lxd
, as the module seems to be focused on running runners locally.
# Copyright 2024 Canonical Ltd. | ||
# See LICENSE file for licensing details. | ||
|
||
"""Module for managing local LXD cloud.""" |
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.
Would this module be local LXD specific or LXD in general?
We might need to support remote LXD cloud in the future.
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 was thinking of having an LXD module and separating it via local/remote flag since many of the code within them will be shared. What do you think?
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.
The local runners needs some logic specific to it, e.g., firewall setup, running a local repo-policy-compliance, etc.
Would it be good for to have the following modules with a eventual RunnerManager interface implementation:
- openstack cloud
- lxd cloud
- local lxd
and modules for the APIs (might be a single file):
- openstack API
- lxd API
- github API
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.
Sounds good 👍
Applicable spec: N/A
Overview
This moves all lxd related files to new lxd_cloud module.
Rationale
To prepare for refactor which caters multiple cloud types.
Juju Events Changes
None.
Module Changes
All LXD related files have been moved to lxd_cloud module.
Library Changes
None.
Checklist
src-docs
urgent
,trivial
,complex
)