Dne 29. 05. 23 v 12:12 Ancor Gonzalez Sosa napsal(a):
Where is the rest of Canary gang? oSC feels incomplete without them!
Yay! :-)
Based on those same conversations, I would also expect openSUSE use Agama as a
multi-product installer.
As LCP pointed to me, that implies we need to resurrect at some point the theming and
branding topic.
Good point! I think as the first step we should split the CSS into two parts,
basic theme independent styling (layout, spacing, ...) and a custom part
(colors,
images, fonts, ...). And package the custom part to
cockpit-agama-branding-default
package (or something like that).
I guess the very important part will be the documentation: what can be branded and
how, how to build and package the custom branding. That should be easier with
our own default branding package, it could serve as a template.
A bit related topic: As Agama gets more official we should be prepared for
a request to display a product license before installation. I'm pretty sure
at some point we will be asked for this. And we should be prepared for that,
like how
to solve that in automatic installation, etc...
> I also had some conversations with Uyuni/SUSE Manager developers. They like
the part
about being able to track the installation process, but they are not so sure our
current solution based on D-Bus would suffice to them. Some extra work is still
needed to close the gap (hopefully without blowing up the memory consumption).
The question is which API would they prefer. There are several possibilities:
- Command line interface
- we already have it, should be easy to extend
- machine output (JSON?) is easy to support
- but needs SSH access and you need to know the login credentials
(currently they are fixed, but that's not nice from security POV...)
- REST API
- unfortunately Cockpit does not allow to add a simple REST API
for querying the current progress, Cockpit is more or less just a static
webserver (providing static HTML + JS + other files)
- ugly hack: re-write the progress at /usr/share/cockpit/agama/progress.json
file whenever it changes, then it would be available as
https://<server>:9090/cockpit/@localhost/agama/progress.json,
a bit less ugly would be writing to ~/.local/share/cockpit/agama-progress
(or whatever different name) with some special manifest.json
- the correct solution would be to implement a simple dedicated web server
running on a different port and watching the D-Bus service
- Webhooks
- the backend service would send a POST request with the progress data
payload (JSON) to the configured URL whenever the status changes
- the question is how to pass the URL (boot parameter?, via command line?,...)
- this should be more efficient, instead of regular polling you would
have callbacks, also sending a simple HTTP request does not need
many resources (compared to a dedicated webserver)
Ideas? Comments?
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
