-
Notifications
You must be signed in to change notification settings - Fork 17
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
Return a Config.Config in MachineInventory #35
Conversation
Return a full config.Config with the Elemental key containing the usual values used for the elemental-installer and the DATA key with the raw values, so they can be interpreted by the elemental-installer to produce the cloud-config to set in the machine. Otherwise, we cant support cloud-config generic configurations like write_files without updating the Machineinventory API every time we want to add one, this way we allow setting an uncapped cloud-config in the machineinventory and that will be passed down to the elemental-installer Signed-off-by: Itxaka <igarcia@suse.com>
I'm missing documentation (resp. examples) of how a matching |
As we now use the annotations ont he data key in the Config.Config that resulted in the installer outputting wrongly cloud-config files. The fix is twofold, first when we marshal/unmarshal we add the omitempty annotation so if Data is empty we dont use it and second, on the ToBytes method we pop the data key from the values before returning the cloud-config file, as we already merged the Data into the config, so the key is useless Signed-off-by: Itxaka <igarcia@suse.com>
It makes no sense to export to env vars the whole config as only the elemental values are the ones needed by the installer/cli. Export only that with the prefix ELEMENTAL_ Signed-off-by: Itxaka <igarcia@suse.com>
Codecov Report
@@ Coverage Diff @@
## main #35 +/- ##
==========================================
- Coverage 42.55% 42.36% -0.19%
==========================================
Files 9 9
Lines 658 668 +10
==========================================
+ Hits 280 283 +3
- Misses 358 365 +7
Partials 20 20
Continue to review full report at Codecov.
|
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.
LGTM
Signed-off-by: Itxaka <igarcia@suse.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.
Looks good to me 👍
I think later on, once the basic functionality is settled, we can spend some time thinking about how to better organize all the this data structures so irrelevant parts are not included.
elemental: | ||
install: | ||
device: /dev/vda | ||
iso: https://something.example.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 understand the registration and system agent data of the config.Config.Elemental
is irrelevant here, 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.
yes, registration data at least should be generated by the server (ca-cert, registration-url, token)
The system agent data I have no idea because Is till don't know what it does or even what format it should take...
}, | ||
Data: registration.Spec.Config.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.
At this point it is unclear to me if the registration.Spec.Config.Elemental.Registration
has some valid or valuable data at this point, I guess there should not be anything in there and if so it can be simply ignored 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.
yeah, I think this could probably be ignored as at this point in time, the machine running the elemental-installer has all this data for sure, I mean, otherwise it should not have reached this point.
I still think that leaving as is, its ok thought, that data may be used to be recorded somewhere? Like in the logs and so on, os it may be good for troubleshooting somehow? I dunno to be honest
Return a full config.Config with the Elemental key containing the usual
values used for the elemental-installer and the DATA key with the raw
values, so they can be interpreted by the elemental-installer to produce
the cloud-config to set in the machine.
Otherwise, we cant support cloud-config generic configurations like
write_files without updating the Machineinventory API every time we want
to add one, this way we allow setting an uncapped cloud-config in the
machineinventory and that will be passed down to the elemental-installer
Fixes #34
Would probably require first to get #32 properly set, so we can test this deeply with an authenticated request. Currently the tests only test the registrationURL unauthenticated, which doesn't produce the full output, only a limited output with just the
elemental.registration
fields filled and drops the rest. Once the auth part is fixed (cacerts I guess?) or I understand how to do an authenticated request, I would feel safe to merge this.Signed-off-by: Itxaka igarcia@suse.com