Skip to content
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

Merged
merged 13 commits into from
May 5, 2023
Merged

Bring elemental-cli code into the agent #13

merged 13 commits into from
May 5, 2023

Conversation

Itxaka
Copy link
Member

@Itxaka Itxaka commented May 1, 2023

@codecov-commenter
Copy link

codecov-commenter commented May 1, 2023

Codecov Report

Merging #13 (a749f66) into main (e3c52e5) will increase coverage by 39.25%.
The diff coverage is 71.52%.

📣 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     
Impacted Files Coverage Δ
internal/agent/install.go 4.91% <0.00%> (-0.20%) ⬇️
internal/agent/reset.go 0.00% <0.00%> (ø)
internal/agent/upgrade.go 0.00% <0.00%> (ø)
pkg/live/common.go 0.00% <0.00%> (ø)
pkg/types/v1/errors.go 0.00% <0.00%> (ø)
pkg/cloudinit/console.go 40.62% <40.62%> (ø)
pkg/utils/getpartitions.go 44.44% <44.44%> (ø)
pkg/types/v1/syscall.go 50.00% <50.00%> (ø)
pkg/types/v1/logger.go 51.47% <51.47%> (ø)
pkg/partitioner/disk.go 56.52% <56.52%> (ø)
... and 26 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

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 <[email protected]>
@Itxaka
Copy link
Member Author

Itxaka commented May 1, 2023

only install for now uses elemental libs directly integrated, seems to work as expected.
upgrade and reset will come later.

config merge will be a pita! elemental does a lot of stuff...

And still missing dropping all unneeded stuff for build...

@Itxaka
Copy link
Member Author

Itxaka commented May 2, 2023

upgrade+reset done

reset fails with a panic so not ready yet :D

@Itxaka
Copy link
Member Author

Itxaka commented May 3, 2023

Reset Works! Upgrade Works!

@Itxaka Itxaka requested a review from a team May 3, 2023 11:50
@@ -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
Copy link
Contributor

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?

Copy link
Member Author

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

Comment on lines +296 to +297
_, reboot := options["reboot"]
_, poweroff := options["poweroff"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
_, reboot := options["reboot"]
_, poweroff := options["poweroff"]
reboot := options["reboot"]
poweroff := options["poweroff"]

Copy link
Member Author

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 :)

Copy link
Contributor

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"

Copy link
Member Author

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!

Copy link
Member Author

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!

return err
}

// Set our cloud-init to the file we just created
Copy link
Contributor

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

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{})
Copy link
Contributor

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"?

Copy link
Member Author

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?

Copy link
Member Author

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?

Copy link
Member Author

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?
Copy link
Contributor

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?

Copy link
Member Author

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.

}

// Override the default luet to pass the auth
// Remember to create the temp dir!
Copy link
Contributor

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?

Copy link
Member Author

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!

Copy link
Contributor

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.

Copy link
Member Author

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

resetConfig.Luet = l

// Generate the upgrade spec
resetSpec, err := elementalConfig.ReadUpgradeSpec(resetConfig)
Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wops! good catch!

)

// Load the upgrade Config from the system
resetConfig, err := elementalConfig.ReadConfigRun("/etc/elemental")
Copy link
Contributor

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)

Copy link
Member Author

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!

Copy link
Contributor

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 @@
/*
Copy link
Contributor

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?

Copy link
Member Author

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.

Itxaka added 2 commits May 4, 2023 09:22
Signed-off-by: Itxaka <[email protected]>
@Itxaka Itxaka requested review from jimmykarily and a team May 5, 2023 11:54
Copy link
Contributor

@jimmykarily jimmykarily left a 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.

@Itxaka Itxaka merged commit 002b8ba into main May 5, 2023
@Itxaka Itxaka deleted the ele branch May 5, 2023 16:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Move elemental-cli to kairos as a pkg and archive the repo
3 participants