Already in my way back from oSC'23, so let's write some notes before I forget. I could feel a lot of interest in Agama even since before the conference itself started, in the welcome party. There was only another topic that looked more important for basically everyone there - the question I was asked 10+ times per day from Thursday to Sunday: Where is the rest of Canary gang? oSC feels incomplete without them! About the second more important topic (apparently), I can say our presentation was extremely well received. Most people looked genuinely interested, not to say excited, about Agama. And looking at the kind of questions I got before the presentation and the feedback I got afterwards, I would say the talk addressed its goal pretty well and there are more people now with a proper understanding of Agama and the installation process in general. And there are people already having ideas about how to contribute, adapt it or adopt it. I saw a lot of interest from the community for adopting Agama as default official installer in a relatively short time frame. Unless we screw things up, I would say Agama will be the official installer for Leap 16. What "Leap 16" means exactly regarding the calendar? Well, nothing is set in stone but my assumption after several conversations is that there will be a Leap 15.6 at some point in the future (still using YaST). So Leap 16 will not arrive before 2024. Gradual integration with Tumbleweed may start a bit in advance. 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. Other area in which we could get some contributions is the initialization process (everything that happens until the point in which Agama takes over). Some people was curious about that and wanted to try their own ideas. 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). But now that we have a common understanding and some foundations, we can build from there. Some people even tried to hack a bit on Agama, although not very successfully. We may need to check if our current documentation in that regard is in good shape. I'm likely forgetting several conversations and details, but I think the main topics are covered. Do not hesitate to ask for more details in any of them. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
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
On Mon, 2023-05-29 at 17:56 +0200, Ladislav Slezák wrote:
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).
Personally, I have no a clear idea how to do it yet. It's something I have thought about a few times already, but as you know... we have been busy. I wouldn't split the CSS for theme reasons. I'd use CSS Custom Properties instead. If we provide a public and stable "CSS Variables API", the consumer should be able to influence everything exposed, no matter if is an space or a color. Also, we have to bear in mind high contrast theming and friends, not only the custom one. One idea that comes to my mind if to add a "global" class name in the body and load a custom file (initially empty? initially missing?). That file could be installed by a package, as Ladislav proposed. But that file should contain only one CSS class (theme-custom?) redefining the variables it wants to change. These are just rough ideas. My apologies for not explaining it more clearly, I'm in a hurry. About the name, I'd avoid calling it "cockpit-". I know cockpit plays a important role in the Agama world, but I'd go for agama-custom-theme or so. About CSS variables, beyond the proper name for each one, I'd like to prefix all of them with "--agm" or similar. As a last thought, I would like to avoid having the same problem we had when trying to change the look & feel of the cockpit. To learn more, please visit https://github.com/cockpit-project/cockpit/pull/17437 and follow the links to learn more. That is my two cents.
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?
On 5/29/23 12:12, Ancor Gonzalez Sosa wrote:
[...]
I'm likely forgetting several conversations and details, but I think the main topics are covered. Do not hesitate to ask for more details in any of them.
I remembered two important topics. The first is kind of obvious but still worth mentioning - if the openSUSE distributions adopt Agama then there is need for a certain level of support to customize the software selection and maybe also the partitioning layout. So we would need to bring back the roles or a quite similar concept. And regarding partitioning layout, somebody also mentioned that it would be cool to share the partitioning definition with kiwi, instead of having two separate sources with different syntax (the storage section of Agama config vs the kiwi profile). Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
participants (3)
-
Ancor Gonzalez Sosa -
David Díaz González -
Ladislav Slezák