-
Notifications
You must be signed in to change notification settings - Fork 426
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
SE: CLI setup experience changes #22956
Conversation
4f893df
to
25f48b2
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## feat-setup-experience #22956 +/- ##
========================================================
Coverage ? 63.13%
========================================================
Files ? 1546
Lines ? 146433
Branches ? 3644
========================================================
Hits ? 92451
Misses ? 46655
Partials ? 7327
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Note that there are no automated gitops tests for the new feature in this PR, I'll add those in a subsequent PR tomorrow (it has been manually tested). Also, setting the VPP apps to install during setup is not implemented for "No team" because VPP apps are not supported for "No team" at the moment - this ticket will track this (released AFAIK) bug: #22970 |
Automated tests added in #23125 |
@@ -11724,19 +11741,19 @@ func (s *integrationMDMTestSuite) TestSetupExperience() { | |||
"GET", "/api/latest/fleet/software/titles", | |||
listSoftwareTitlesRequest{}, | |||
http.StatusOK, &respListTitles, | |||
"team_id", strconv.Itoa(int(team1.ID)), | |||
"team_id", fmt.Sprint(team1.ID), |
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.
🔥
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.
Left some comments and questions, but can be merged as is.
MacOSSetupAssistant optjson.String `json:"macos_setup_assistant"` | ||
EnableReleaseDeviceManually optjson.Bool `json:"enable_release_device_manually"` | ||
Script optjson.String `json:"script"` | ||
Software optjson.Slice[*MacOSSetupSoftware] `json:"software"` |
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.
Just curious, why does this need to be a pointer: *MacOSSetupSoftware
?
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.
Not strictly needed, but makes it easier to avoid issues as we need to change its field value here:
fleet/server/service/client.go
Line 858 in c11420b
sw.PackagePath = resolveApplyRelativePath(baseDir, sw.PackagePath) |
A non-pointer would only change the local copy and would turn this into a potentially tricky bug to find.
SelfService bool `json:"self_service"` | ||
FleetMaintained bool `json:"-"` | ||
Filename string `json:"-"` | ||
InstallDuringSetup *bool `json:"install_during_setup"` // if nil, do not change saved value, otherwise set 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.
Why not use optjson.Bool
here, and similar places?
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.
In this case we don't need the extra features of optjson
(i.e. no need to know if the key was explicitly set or not when it's null). optjson
is mostly useful for PATCH-like processing where the key being absent is different than the key present but null.
// this is a set of software packages or VPP apps that are configured as | ||
// install_during_setup, by team. This is a gitops-only setting, so it will | ||
// only be filled when called via this command. | ||
tmSoftwareMacOSSetup := make(map[string]map[fleet.MacOSSetupSoftware]struct{}, len(tmMacSetup)) |
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.
Nit. if tmMacSetup
is empty, we shouldn't even need to call make
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.
True, but I think it's minor enough not to matter here and makes the code a bit less verbose (and less error-prone if the conditions were to change).
server/service/client.go
Outdated
softwareInstallers, err = c.ApplyNoTeamSoftwareInstallers(payload, fleet.ApplySpecOptions{DryRun: dryRun}) | ||
} | ||
|
||
// marshaling dance to get the macos_setup data |
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.
Nit: Needs better comment here. This is to get additional validation and get optjson functionality, right?
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's because we have it as a map[string]interface{}
stored in a interface{}
here, and hand-unwrapping all this is not super robust or easy to maintain. I'll update the comment to make that clearer.
// planned, so to avoid delaying the feature I'm doing DELETE then SET, but | ||
// that's not ideal (will always re-create the script when apply/gitops is | ||
// run with the same yaml). Note though that we also redo software installers | ||
// downloads on each run, so the churn of this one is minor in comparison. |
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.
Wouldn't get existing script and compare be better?
Please file a bug for this. This will cause setup experience to malfunction in some rare cases, right?
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.
Wouldn't get existing script and compare be better?
Not necessarily, we'd be getting from the reader and loading/comparing a potentially large string to check for differences. I agree that it's worth creating a ticket, as gitops is all about "replace whatever's there" so we don't need to pay the price of a check. I'll file this bug.
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 will cause setup experience to malfunction in some rare cases
I don't think so? I mean, there's a slight race between the delete and the insert if something else re-inserts first, but then it would fail applying it. I don't think it can really malfunction because of this, but it's still not ideal IMO.
#22385
Checklist for submitter
changes/
,orbit/changes/
oree/fleetd-chrome/changes
.See Changes files for more information.
SELECT *
is avoided, SQL injection is prevented (using placeholders for values in statements)