[opensuse-factory] Re: [yast-devel] The (near) future of AutoYaST
El vie, 17-04-2020 a las 09:28 +0200, Rodion Iafarov escribió:
Hi Imo,
Hi Rodion, First of all, I appreciate a lot your feedback. Thanks!
I believe I can provide some feedback on that. As we work with autoyast ourselves and I've supported many colleagues in creating profiles, I can tell that creating new profile is complex.
Strategy of cloning existing system and modifying it, but that's also a lot of work as profile contains everything. Maybe fixing module for the profile generation can help here.
Yes, you are right, it is pretty complex. Actually, we have even a UI, but it is far from ideal (especially when it comes to partitioning). Just in case, when cloning the system you can decide which modules you want to run (so you do not get a giant profile with lots of useless settings). But you need to check the *.desktop files in order to find out the interesing modules. An example: yast clone_system modules clone=software To be honest, it includes too much information (like networking) and I miss a simple way to just clone the "minimal" config.
In order to make profile work with other disk names, customers use shell script to modify xml in the runtime. Instead we could support multiple names so that same profile could be reused.
Good point. I have faced that problem when working with real and virtual machines (/dev/sd* vs /de/vd*). If you only have one disk you can omit the device, but for complex systems is not that easy.
Packages, patterns and modules get renamed. It's almost never the case that profile from one SP will work in the next one. This one is tricky to act on.
Yes, this one is somehow out of AutoYaST control, but we can study if YaST itself can do it easier.
As for the future, I have 2 ideas in mind. As yomi is out there (https://github.com/openSUSE/yomi), maybe we should look into developing that solution further to replace autoyast.
Sure, that's what I would expect to happen in the future. But as AutoYaST relies in YaST (and its proposals during installation), there might be some valid uses cases for AutoYaST even in the future.
Second thing I had in mind was actually to significantly simplify supported features and just provide interface to shell in order to reduce costs for the maintenance. So in case customers need creating users, they can run useradd command.
Specially the users module is rather complex. And when you clone a system, it exports all the users in the /etc/passwd database (which is not ideal as most of that information is already elsewhere). On the other hand, we have support for running scripts during installation, although there are a few things to improve in that regard.
I would also suggest to gather some feedback from enterprise customers too, as I believe they have different use-cases, like using AY with SUSE Manager to provision machines.
Yes, we will try to get information from them too.
Hope it helps, let me know if you have any questions.
Thanks!
Thanks a lot! Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
On 2020-04-17 09:51, Imobach González Sosa wrote:
El vie, 17-04-2020 a las 09:28 +0200, Rodion Iafarov escribió:
Hi Imo,
As for the future, I have 2 ideas in mind. As yomi is out there (https://github.com/openSUSE/yomi), maybe we should look into developing that solution further to replace autoyast.
Sure, that's what I would expect to happen in the future. But as AutoYaST relies in YaST (and its proposals during installation), there might be some valid uses cases for AutoYaST even in the future.
That is true. I want to comment random ideas here. Most of the complains about AutoYaST in relation with the management of the XML profile. Those are resolved in Yomi indirectly by having a template engine. This engine is part of Salt (sort of), and can be used for the states but also for the pillars (that is the equivalent of the XML profile). So I wonder if adding ERB templates in the profile and a way to access to the public API of YaST can help here. Another comment is that Yomi have a very early prototype that translate the XML profile into the YAML pillar (https://github.com/openSUSE/yomi/blob/master/autoyast2yomi). There are clear limitations, basically because YaST is doing a *lot* more things. One last comment, and call me crazy : D, is that lately I am thinking more about the ownership of Yomi as an openSUSE project. With YaST supporting Salt formulas and AutoYaST integration with Salt, I am wondering if the natural living place of Yomi is as a YaST subproject. Like a SaltYaST, or AutoYaST-Salt or something. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El vie, 17-04-2020 a las 10:34 +0200, aplanas escribió:
On 2020-04-17 09:51, Imobach González Sosa wrote:
El vie, 17-04-2020 a las 09:28 +0200, Rodion Iafarov escribió:
Hi Imo, As for the future, I have 2 ideas in mind. As yomi is out there (https://github.com/openSUSE/yomi), maybe we should look into developing that solution further to replace autoyast.
Sure, that's what I would expect to happen in the future. But as AutoYaST relies in YaST (and its proposals during installation), there might be some valid uses cases for AutoYaST even in the future.
That is true. I want to comment random ideas here.
Most of the complains about AutoYaST in relation with the management of the XML profile. Those are resolved in Yomi indirectly by having a template engine. This engine is part of Salt (sort of), and can be used for the states but also for the pillars (that is the equivalent of the XML profile). So I wonder if adding ERB templates in the profile and a way to access to the public API of YaST can help here.
That's interesting. Actually, there is an ongoing discussion about our XML parser[1][2]. I have been thinking even about some features that our documentation team uses (like conditional rendering depending on the attribute values).
Another comment is that Yomi have a very early prototype that translate the XML profile into the YAML pillar (https://github.com/openSUSE/yomi/blob/master/autoyast2yomi). There are clear limitations, basically because YaST is doing a *lot* more things.
I sounds interesting, I will have a look.
One last comment, and call me crazy : D, is that lately I am thinking more about the ownership of Yomi as an openSUSE project. With YaST supporting Salt formulas and AutoYaST integration with Salt, I am wondering if the natural living place of Yomi is as a YaST subproject. Like a SaltYaST, or AutoYaST-Salt or something.
Well, I am not sure. At this point, I consider them as separate projects (using different approaches, constraints, etc.) but I see a lot of space for collaborating and sharing ideas. Thanks a lot for your feedback, Alberto! Regards, Imo [1] https://lists.opensuse.org/yast-devel/2020-03/msg00036.html [2] https://lists.opensuse.org/yast-devel/2020-04/msg00002.html -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
participants (2)
-
aplanas -
Imobach González Sosa