[yast-devel] The (near) future of AutoYaST
Hi all, After rewriting our storage layer and, partially, our network stack, the YaST team is looking now to AutoYaST, which is showing its age. Just in case someone does not know, AutoYaST is a software component that, using an XML based description, orchestrates YaST modules to install/upgrade and configure the system in an unattended way. You might want to check the docs[1][2] for more information. We have started started to analyze and build a list of the things we would like to address, but we would love to hear your opinion. Do you have some use case you would like to see supported? Which problems have you faced when using AutoYaST? Which features do you miss? Do you have a different vision of what AutoYaST should be (we can learn from those opinions too)? Any idea/comment is welcome. Thanks a lot in advance! Regards, Imo [1] https://documentation.suse.com/sles/15-SP1/html/SLES-all/book-autoyast.html [2] https://doc.opensuse.org/projects/autoyast/ -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
Hi Imo, 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. 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. 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. 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. 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. 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. Hope it helps, let me know if you have any questions. Thanks! On 4/17/20 9:10 AM, Imobach González Sosa wrote:
Hi all,
After rewriting our storage layer and, partially, our network stack, the YaST team is looking now to AutoYaST, which is showing its age.
Just in case someone does not know, AutoYaST is a software component that, using an XML based description, orchestrates YaST modules to install/upgrade and configure the system in an unattended way. You might want to check the docs[1][2] for more information.
We have started started to analyze and build a list of the things we would like to address, but we would love to hear your opinion. Do you have some use case you would like to see supported? Which problems have you faced when using AutoYaST? Which features do you miss? Do you have a different vision of what AutoYaST should be (we can learn from those opinions too)?
Any idea/comment is welcome. Thanks a lot in advance!
Regards, Imo
[1] https://documentation.suse.com/sles/15-SP1/html/SLES-all/book-autoyast.html [2] https://doc.opensuse.org/projects/autoyast/
--
Kind regards,
Rodion Iafarov
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/
Hi there, thanks something I can second. I've had some runs to get to use AutoYaST but if I remember correctly I was overwhelmed but the amount of XML that is necessary to make a plain install. It would be perfect to have a default installation that represents about the experience when installation through the graphical installer. Yet the GUI has always been faster than to get into AutoYaST and make a working config file. Cheers, Bernd On 17.04.20 09:28, Rodion Iafarov wrote:
Hi Imo,
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.
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Bernd Ritter -
Imobach González Sosa -
Rodion Iafarov