-
Notifications
You must be signed in to change notification settings - Fork 6
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
Bring elemental-cli code into the agent #13
Conversation
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## main #13 +/- ##
===========================================
+ Coverage 22.10% 61.36% +39.25%
===========================================
Files 17 50 +33
Lines 1330 6038 +4708
===========================================
+ Hits 294 3705 +3411
- Misses 983 2010 +1027
- Partials 53 323 +270
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Brings the elemental-cli config generation methods so the installer reads the config files for elemental and merges them back into the final config. This has the side effect of bringing viper as a dep as we rely heavily on viper to unmarshall everything so maybe we should move the cli to use viper Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
only install for now uses elemental libs directly integrated, seems to work as expected. config merge will be a pita! elemental does a lot of stuff... And still missing dropping all unneeded stuff for build... |
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Available on commit 0c9d2bd9e6ae0a312ed46b441f00d93b93b79a24 Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
upgrade+reset done reset fails with a panic so not ready yet :D |
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Reset Works! Upgrade Works! |
@@ -249,47 +251,29 @@ func Install(dir ...string) error { | |||
} | |||
|
|||
func RunInstall(options map[string]string) error { | |||
// TODO: run yip directly | |||
utils.SH("elemental run-stage kairos-install.pre") //nolint:errcheck |
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 thought the goal of this PR was to not have "elemental" in the image at all. Are we doing it in steps?
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.
we can work on that afterwards in paralell with other work, no need to block this further with that
_, reboot := options["reboot"] | ||
_, poweroff := options["poweroff"] |
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.
_, reboot := options["reboot"] | |
_, poweroff := options["poweroff"] | |
reboot := options["reboot"] | |
poweroff := options["poweroff"] |
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.
this is a map[string]string], so cant get just that without more work afterwards. Doing it trhis way means that the reboot and poweroff are directly a bool type :)
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.
could options["reboot"]
be set to "false"
? Because in that case reboot
would be true
(because the key exists), although it's value is "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.
That is a good point!
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.
welp, this actually does the same behaviour that the old one! so yeah, not touching this in the PR, maybe afterwards as its a behaviour change!
internal/agent/install.go
Outdated
return err | ||
} | ||
|
||
// Set our cloud-init to the file we just created |
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.
This comment belongs above line 306 below I think
internal/agent/reset.go
Outdated
bus.Manager.Response(sdk.EventBeforeReset, func(p *pluggable.Plugin, r *pluggable.EventResponse) { | ||
err := json.Unmarshal([]byte(r.Data), &options) | ||
err := json.Unmarshal([]byte(r.Data), &map[string]string{}) |
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.
We used to unmarshal to options
because we needed that variable later. What's the reason of unmarshaling now? Just to print the error if it's not "umarshable"?
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.
options was an empty map[string]string{}
before. This is just removing an extra var. No idea why it was done like this before, I guess because all install,reset,upgrade do the same? In case we add options later?
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.
oooh I see, it comes from the r.Data
.
Where the fuck does that r.Data magically appears from?
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 have no idea where that comes from or how does it get set to be honest, I'll bring it up on the meeting today.
Also good catch, this was setting reset-persistent by default in no data was coming in, I missed that!
|
||
"github.com/mudler/go-pluggable" | ||
"github.com/pterm/pterm" | ||
) | ||
|
||
func Reset(dir ...string) error { | ||
// TODO: Enable args? No args for now so no possibility of reset persistent or overriding the source for the reset | ||
// Nor the auto-reboot via cmd? |
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.
afaict --reset-persistent
flag was set through r.Data
in this code. Why can't we keep it this way?
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.
This comment relates for the cli being called. If you call kairos-agent reset there is no flags that can be passed manually to override the default config. Im just thinking that maybe we should be able to override the config via flags.
internal/agent/upgrade.go
Outdated
} | ||
|
||
// Override the default luet to pass the auth | ||
// Remember to create the temp dir! |
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.
Is this a TODO note? Who should remember it and when?
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.
Well this has history :D
Its just a note to mention that when creating a custom luet object you need to create a temp dir for it explicitely. Otherwise things go wrong very soon. I'll expand the comment a bit more!
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 there is nothing to do in this part of the code no? Maybe this reminder belongs closer to where the temp dir should be created.
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.
It should be created here, when you create the new luet. I hope to fix this in the future once the code is folder but currently if someone removes that line, unintended consequences will happen :D
internal/agent/upgrade.go
Outdated
resetConfig.Luet = l | ||
|
||
// Generate the upgrade spec | ||
resetSpec, err := elementalConfig.ReadUpgradeSpec(resetConfig) |
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.
This variable should probably be called upgradeSpec
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.
wops! good catch!
internal/agent/upgrade.go
Outdated
) | ||
|
||
// Load the upgrade Config from the system | ||
resetConfig, err := elementalConfig.ReadConfigRun("/etc/elemental") |
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.
This variable should probably be called upgradeConfig
(though it seems that we load the same config on reset so maybe a more generic name in both cases would be better)
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.
indeed. It actually should be config but there is already like 32 different config vars lol. I'll change it!
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.
Yes, we will hopefully consolidate configs here (That story is a can of worms...)
@@ -0,0 +1,287 @@ | |||
/* |
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 don't think we should bring the build parts too. There is another story to move those to osbuilder (kairos-io/kairos#711). Until we do, I guess it's ok to keep them in the old "elemental-cli" binary, what do you think? Or are we planning to replace elemental-cli with kairos-agent first and then move the build parts to osbuilder?
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.
yep yep, this is a "fast, dirty" job to bring the libs in here, there is still lot of work to clean this up and unify, but I didnt want to block this further. Removing those parts can be done afterwards in parallel with the config merge and others.
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
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'm fine to merge this as it is and improve the code in future PRs. After all, this is mainly a code migration from another repository. No need to fix everything at once.
Fixes kairos-io/kairos#1210