[opensuse-factory] 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 always wanted to get into AutoYast. At work we now do want to roll out our embedded linux based devices (using opensuse of course) and I considered AutoYast to do the factory setup work. Cheers, Bernd On 17.04.20 09:10, 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/
-- 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 09:27 +0200, Bernd Ritter escribió:
Hi Imo,
Hi Bernd,
I always wanted to get into AutoYast. At work we now do want to roll out our embedded linux based devices (using opensuse of course) and I considered AutoYast to do the factory setup work.
It sounds great. You could have a look at the AutoYaST guide[1] and give it a try. Of course, do not hesitate to ask if you have any doubt (you can use the yast-devel mailing list for that). Regards, Imo [1] https://doc.opensuse.org/projects/autoyast/ [2] https://lists.opensuse.org/yast-devel/
On 17.04.20 09:10, 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/
-- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Apr 17, Imobach González Sosa wrote:
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)?
If I look at something like installing a kubernetes cluster: - many similar machines - most of installation and configuration is identical - small changes in configuration, package list, partitioning, depending on the role of the node. So you have about 5-6 autoyast.xml files, which are all to about 98% identical. Keeping this files in sync is pretty hard. I would like to see that autoyast makes it much easier for the user to maintain one file with small variations which can be used for all roles. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
hi, i'm blind and currently it's impossible for me to install opensuse, could something be done for blind people? since this deels with unattended installs, why not have a gtk gui interface where in everything could be configured for auto install? partition layout package selection etc? if it could be distro agnostic that is to say if this could run on other distributions to create the file for the opensuse install media I would then be able to install with out sited assistence? since opensuse's current installer is inaccessible?? also you don't have orca the screen reader on the live iso? that's my request? Majid On 17/04/2020, Thorsten Kukuk <kukuk@suse.de> wrote:
On Fri, Apr 17, Imobach González Sosa wrote:
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)?
If I look at something like installing a kubernetes cluster: - many similar machines - most of installation and configuration is identical - small changes in configuration, package list, partitioning, depending on the role of the node.
So you have about 5-6 autoyast.xml files, which are all to about 98% identical. Keeping this files in sync is pretty hard. I would like to see that autoyast makes it much easier for the user to maintain one file with small variations which can be used for all roles.
Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- kind regards, Majid Hussain -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-04-17 at 09:31 +0200, Thorsten Kukuk wrote:
On Fri, Apr 17, Imobach González Sosa wrote:
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)?
If I look at something like installing a kubernetes cluster: - many similar machines - most of installation and configuration is identical - small changes in configuration, package list, partitioning, depending on the role of the node.
So you have about 5-6 autoyast.xml files, which are all to about 98% identical. Keeping this files in sync is pretty hard. I would like to see that autoyast makes it much easier for the user to maintain one file with small variations which can be used for all roles.
Thorsten
A partial solution to this problem already exists in the form of AutoYaST's rules & classes feature: https://documentation.suse.com/sles/12-SP4/html/SLES-all/rulesandclass.html I've had a single common autoyast.xml with the 2% differences being in 4-5 class-specific xml snippits, only containing the different bits. Then you can use either auto matching rules or dialogues to declare the class (aka role of the node) and you get the approrpiate result in the end. That said, it's certainly an area where dramatic usability improvements could be made. Needing to have a special folder structure with everything named perfectly is a bit of a clunky mess, just wanted to make the point that there's a starting point for solving that use case already. I'd certainly like to see a new AutoYaST go more in that direction of modular configuration. Richard -- 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:48 +0200, Richard Brown escribió:
A partial solution to this problem already exists in the form of AutoYaST's rules & classes feature:
+1
That said, it's certainly an area where dramatic usability improvements could be made. Needing to have a special folder structure with everything named perfectly is a bit of a clunky mess, just wanted to make the point that there's a starting point for solving that use case already.
I'd certainly like to see a new AutoYaST go more in that direction of modular configuration.
Yes, you are right. It is an relatively unknown feature that deserves more attention from our own. Given that you have been using it, we would love to hear your feedback :) Thanks! Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 17. April 2020, 09:10:52 CEST schrieb Imobach González Sosa:
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)?
I have tried several times to get into autoyast... and every time given up at some point, due to complexity. Especially compared to the other automated installation that i'm familiar with (RHEL/CentOS/fedora kickstart) AutoYAST seems unnecessarily complex to me... Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
El vie, 17-04-2020 a las 10:21 +0200, Mathias Homann escribió:
Am Freitag, 17. April 2020, 09:10:52 CEST schrieb Imobach González Sosa:
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)?
I have tried several times to get into autoyast... and every time given up at some point, due to complexity.
Especially compared to the other automated installation that i'm familiar with (RHEL/CentOS/fedora kickstart) AutoYAST seems unnecessarily complex to me...
Hi Mathias, I admit that I do not have experience with kickstart. Having said that, what do you mean by "unnecessarily complex"? Is it about having to deal with XML? Or do you mean that writing an AutoYaST profile is hard? Thanks for your feedback! Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Apr 20, 2020 at 9:11 AM Imobach González Sosa <igonzalezsosa@suse.de> wrote:
El vie, 17-04-2020 a las 10:21 +0200, Mathias Homann escribió:
Am Freitag, 17. April 2020, 09:10:52 CEST schrieb Imobach González Sosa:
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)?
I have tried several times to get into autoyast... and every time given up at some point, due to complexity.
Especially compared to the other automated installation that i'm familiar with (RHEL/CentOS/fedora kickstart) AutoYAST seems unnecessarily complex to me...
Hi Mathias,
I admit that I do not have experience with kickstart. Having said that, what do you mean by "unnecessarily complex"? Is it about having to deal with XML? Or do you mean that writing an AutoYaST profile is hard?
I can't speak for Mathias, but in my experience, writing a Kickstart is really straightforward. Not to mention there are a lot of tools that support it natively (including one I currently maintain!), which makes it a lot easier to leverage for mass provisioning of different types (live media creation, PXE and install image creation, auto-installation, etc.). And this extends beyond just RH/Fedora systems, as even Ubuntu supports it with kickseed (which I've used for provisioning Ubuntu systems). Are kickstarts perfect? No, but they are really easy to make and deploy, with support by a huge ecosystem of tools. Kickstarts are defined by the pykickstart project: https://github.com/pykickstart/pykickstart I packaged pykickstart for openSUSE a while ago for some development work I was doing: https://build.opensuse.org/package/show/home:Pharaoh_Atem:SUSE_LiveCDTools/p... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El lun, 20-04-2020 a las 09:23 -0400, Neal Gompa escribió:
On Mon, Apr 20, 2020 at 9:11 AM Imobach González Sosa <igonzalezsosa@suse.de> wrote:
El vie, 17-04-2020 a las 10:21 +0200, Mathias Homann escribió:
Am Freitag, 17. April 2020, 09:10:52 CEST schrieb Imobach González Sosa:
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)?
I have tried several times to get into autoyast... and every time given up at some point, due to complexity.
Especially compared to the other automated installation that i'm familiar with (RHEL/CentOS/fedora kickstart) AutoYAST seems unnecessarily complex to me...
Hi Mathias,
I admit that I do not have experience with kickstart. Having said that, what do you mean by "unnecessarily complex"? Is it about having to deal with XML? Or do you mean that writing an AutoYaST profile is hard?
I can't speak for Mathias, but in my experience, writing a Kickstart is really straightforward.
Not to mention there are a lot of tools that support it natively (including one I currently maintain!), which makes it a lot easier to leverage for mass provisioning of different types (live media creation, PXE and install image creation, auto-installation, etc.). And this extends beyond just RH/Fedora systems, as even Ubuntu supports it with kickseed (which I've used for provisioning Ubuntu systems).
Are kickstarts perfect? No, but they are really easy to make and deploy, with support by a huge ecosystem of tools.
Kickstarts are defined by the pykickstart project: https://github.com/pykickstart/pykickstart
I packaged pykickstart for openSUSE a while ago for some development work I was doing: https://build.opensuse.org/package/show/home:Pharaoh_Atem:SUSE_LiveCDTools/p...
Thanks Neal, Yes, you (and Mathias) have a good point. We need to provide better tools to deal with AutoYaST profiles. On the one hand, we have a UI that it is partially broken and, on the other hand, 'cloning' the current system usually generates a profile which is too big (although you can narrow to clone just a subset of modules). On the other hand, validation is another area to improve. Sure you can use 'jing' to validate a profile, but it would be nice to have some runtime validation too. Finally, although the documentation is good (as a reference), we have been considering for some time providing a set of profile examples for different use cases, so the user can take inspiration (or simply copy&paste) from there. Thanks for your feedback! Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Apr 20, 2020 at 9:58 AM Imobach González Sosa <igonzalezsosa@suse.de> wrote:
El lun, 20-04-2020 a las 09:23 -0400, Neal Gompa escribió:
On Mon, Apr 20, 2020 at 9:11 AM Imobach González Sosa <igonzalezsosa@suse.de> wrote:
El vie, 17-04-2020 a las 10:21 +0200, Mathias Homann escribió:
Am Freitag, 17. April 2020, 09:10:52 CEST schrieb Imobach González Sosa:
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)?
I have tried several times to get into autoyast... and every time given up at some point, due to complexity.
Especially compared to the other automated installation that i'm familiar with (RHEL/CentOS/fedora kickstart) AutoYAST seems unnecessarily complex to me...
Hi Mathias,
I admit that I do not have experience with kickstart. Having said that, what do you mean by "unnecessarily complex"? Is it about having to deal with XML? Or do you mean that writing an AutoYaST profile is hard?
I can't speak for Mathias, but in my experience, writing a Kickstart is really straightforward.
Not to mention there are a lot of tools that support it natively (including one I currently maintain!), which makes it a lot easier to leverage for mass provisioning of different types (live media creation, PXE and install image creation, auto-installation, etc.). And this extends beyond just RH/Fedora systems, as even Ubuntu supports it with kickseed (which I've used for provisioning Ubuntu systems).
Are kickstarts perfect? No, but they are really easy to make and deploy, with support by a huge ecosystem of tools.
Kickstarts are defined by the pykickstart project: https://github.com/pykickstart/pykickstart
I packaged pykickstart for openSUSE a while ago for some development work I was doing: https://build.opensuse.org/package/show/home:Pharaoh_Atem:SUSE_LiveCDTools/p...
Thanks Neal,
Yes, you (and Mathias) have a good point. We need to provide better tools to deal with AutoYaST profiles. On the one hand, we have a UI that it is partially broken and, on the other hand, 'cloning' the current system usually generates a profile which is too big (although you can narrow to clone just a subset of modules).
On the other hand, validation is another area to improve. Sure you can use 'jing' to validate a profile, but it would be nice to have some runtime validation too.
Finally, although the documentation is good (as a reference), we have been considering for some time providing a set of profile examples for different use cases, so the user can take inspiration (or simply copy&paste) from there.
One thing that helped massively improve the quality of kickstarts used in the RH/Fedora ecosystem is that Anaconda was retooled years ago (just a year or so before RHEL 7 was branched from Fedora) to internally generate a kickstart for user actions and use *that* to actually do the installation. That kickstart file would get written into /root/anaconda-ks.cfg, letting people see how they were set up and cloning from that. These tended to make very clean kickstarts that people can easily customize. Whether YaST gains support for Kickstart or does something interesting to AutoYaST, this would be a good path to make more usable auto-installation setups based on a manual setup. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2020-04-17 09:10, Imobach González Sosa wrote:
After rewriting our storage layer and, partially, our network stack, the YaST team is looking now to AutoYaST, which is showing its age.
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.
Never really needed it - if there was some mass deployment, I'd use the kiwi(1) installer, or do a disk replication(2). Somehow, installing rpms unfortunately takes much longer than extracting a filestream (e.g. whatever (1)kiwi uses, or (2)tar). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-04-17 09:10, 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/
Firstly, my gratitude for maintaining autoyast. Through it, you can pre-define each and every option there is during Suse installation (and actually you can even set things that are not even asked :-) I used it for installing countless HP-servers: each and everyone got installed identically (something my colleagues never were able to obtain) And it works lightning fast: HP-servers needed more time through the BIOS than the entire installation + update, by feeding the autoyast file to the TFTPboot + PXE (before that, a co-worker was assigned an entire DAY for installing and configuring ) And, not just bare metal, but also virtual-clients I do know that you can pre-configure systems with kiwi (and can even supply an autoyastfile) but that is a rather bumpy road, not stable, and KIWI had a tendency to have a mind of its own (not configurable), especially with regards to configuring disks, LVM and crypt. So, keep it all configurable, even invisible options, please. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El vie, 24-04-2020 a las 00:24 +0200, suse@a-domani.nl escribió: [..]
Firstly, my gratitude for maintaining autoyast.
You are welcome! Thanks you for using it.
Through it, you can pre-define each and every option there is during Suse installation (and actually you can even set things that are not even asked :-) I used it for installing countless HP-servers: each and everyone got installed identically (something my colleagues never were able to obtain)
It sounds great :)
And it works lightning fast: HP-servers needed more time through the BIOS than the entire installation + update, by feeding the autoyast file to the TFTPboot + PXE (before that, a co-worker was assigned an entire DAY for installing and configuring ) And, not just bare metal, but also virtual-clients
I do know that you can pre-configure systems with kiwi (and can even supply an autoyastfile) but that is a rather bumpy road, not stable, and KIWI had a tendency to have a mind of its own (not configurable), especially with regards to configuring disks, LVM and crypt.
So, keep it all configurable, even invisible options, please.
Sure. We do not plan to remove any option at this point. The plan is to fix a few things that we know are broken, make it more robust (improving the code quality and test coverage) and improve/add a few features. We will keep all of you informed! Thanks! Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pátek 17. dubna 2020 9:10:52 CEST, Imobach González Sosa napsal(a):
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/
Hello, it's probably out of purpose of AutoYaST, but I wonder if it could be usable as kind of backup and restore of configuration. E.g. if there could be some automated way to create profile describing actual configuration (what is installed and how everything is set up). Something like that. Sincerely, -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
Vojtěch Zeisek wrote:
Hello, it's probably out of purpose of AutoYaST, but I wonder if it could be usable as kind of backup and restore of configuration. E.g. if there could be some automated way to create profile describing actual configuration (what is installed and how everything is set up). Something like that.
Yes, I second that one - that would be quite useful. -- Per Jessen, Zürich (15.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5/2/20 11:14 AM, Vojtěch Zeisek wrote:
Dne pátek 17. dubna 2020 9:10:52 CEST, Imobach González Sosa napsal(a):
[...]
Hello, it's probably out of purpose of AutoYaST, but I wonder if it could be usable as kind of backup and restore of configuration. E.g. if there could be some automated way to create profile describing actual configuration (what is installed and how everything is set up). Something like that.
Isn't that one of the main use cases of Machinery? Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pondělí 4. května 2020 9:27:36 CEST, Ancor Gonzalez Sosa napsal(a):
On 5/2/20 11:14 AM, Vojtěch Zeisek wrote:
Dne pátek 17. dubna 2020 9:10:52 CEST, Imobach González Sosa napsal(a):
[...] it's probably out of purpose of AutoYaST, but I wonder if it could be usable as kind of backup and restore of configuration. E.g. if there could be some automated way to create profile describing actual configuration (what is installed and how everything is set up). Something like that.
Isn't that one of the main use cases of Machinery?
I wasn't aware of this, thank You. And after reading its homepage such use isn't obvious for me... Then I also wonder about difference/overlap among these two tools. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
From: Tim Hardeck <thardeck@suse.de> To: opensuse-factory@opensuse.org Hi everyone,
while Machinery (https://github.com/SUSE/machinery) is still working fine, the active development has stopped. We changed the focus in our team long ago and do not have the resources to maintain it any longer.
Therefore I am asking if anyone is interested in maintaining the Machinery package in the future, or even willing to take over the >
Hi Vojtěch, please be aware that as to Tim Hardecks mail from 2020-03-06 Machinery is no longer under active development while still working fine. project.
If not I will remove it from openSUSE Tumbleweed and future openSUSE Leap versions.
Kind Regards, Tim
On 04.05.20 11:56, Vojtěch Zeisek wrote:
Dne pondělí 4. května 2020 9:27:36 CEST, Ancor Gonzalez Sosa napsal(a):
On 5/2/20 11:14 AM, Vojtěch Zeisek wrote:
Dne pátek 17. dubna 2020 9:10:52 CEST, Imobach González Sosa napsal(a):
[...] it's probably out of purpose of AutoYaST, but I wonder if it could be usable as kind of backup and restore of configuration. E.g. if there could be some automated way to create profile describing actual configuration (what is installed and how everything is set up). Something like that.
Isn't that one of the main use cases of Machinery?
I wasn't aware of this, thank You. And after reading its homepage such use isn't obvious for me... Then I also wonder about difference/overlap among these two tools.
Cheers, Bernd
El lun, 04-05-2020 a las 11:56 +0200, Vojtěch Zeisek escribió:
Dne pondělí 4. května 2020 9:27:36 CEST, Ancor Gonzalez Sosa napsal(a):
On 5/2/20 11:14 AM, Vojtěch Zeisek wrote:
Dne pátek 17. dubna 2020 9:10:52 CEST, Imobach González Sosa napsal(a):
[...] it's probably out of purpose of AutoYaST, but I wonder if it could be usable as kind of backup and restore of configuration. E.g. if there could be some automated way to create profile describing actual configuration (what is installed and how everything is set up). Something like that.
Isn't that one of the main use cases of Machinery?
I wasn't aware of this, thank You. And after reading its homepage such use isn't obvious for me... Then I also wonder about difference/overlap among these two tools.
Hi, They are not related at all and, to be honest, there is some confusion about what AutoYaST really is. I like to see AutoYaST as a 'YaST driver': it takes a XML based description (an AutoYaST profile) and installs (or even configures) the system using YaST. Everything which is not supported by YaST is not supported by AutoYaST. On the other hand, the purpose of Machinery (if I got it right) is to analyze a system and build a system description (services, configuration, etc.). And that description can be used by other tools. Actually, Machinery is able export the description to an AutoYaST profile[1]. However, not all information found by Machinery would have an AutoYaST counterpart. Regards, Imo [1] http://machinery-project.org/docs/machinery-export-autoyast.1/ -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
participants (13)
-
Ancor Gonzalez Sosa -
Bernd Ritter -
Imobach Gonzalez Sosa -
Imobach González Sosa -
Jan Engelhardt -
Majid Hussain -
Mathias Homann -
Neal Gompa -
Per Jessen -
Richard Brown -
suse＠a-domani.nl -
Thorsten Kukuk -
Vojtěch Zeisek