[yast-devel] Correct solution for AutoYast: Report Unknown/Unsupported Sections
Hi, I'm a little bit stuck between added-value and implementation details for the $SUBJECT bug. Long story short, we have dropped yast2-sshd package that used to implement configuration for sshd in AutoYast. Someone has tried an old AutoYast profile with <sshd/> settings and was surprised not to have sshd configured accordingly. They have asked for getting a warning / error report about it. There are several possibilities how to solve it with different level of benefit for the customer, maintenance effort in the future and cleanness of the solution. 1. Handle only sections known to be dropped Benefit: Inform about dropped support of <sshd/>, ...? Solution: Hard-coded list of dropped sections Effort: Low Maintenance: List of dropped modules Disadvantage: Doesn't report unknown sections 2. Compare the profile with what the currently installed system can configure Benefit: Inform about all unknown sections and also known sections that cannot be handled because of some missing Yast packages Solution: Using the current AutoYast functionality for parsing desktop files that maps "X-SuSE-YaST-AutoInstResource" entries to the profile (Y2ModuleConfig.ModuleMap.keys - Profile.current.keys - ["globals", "language", "networking", "user_defaults" ...]) Effort: Medium Maintenance: Hard-coded list of false-positives Disadvantage: The current implementation doesn't seem to recognize some entries, such as ["globals", "language", "networking", "user_defaults" ...], for instance, "language"/"keyboard" is hard-coded in clients/inst_autosetup.rb 3. Compare the profile with currently installed schema Benefit: Handle only unknown sections Solution: Parse /usr/share/YaST2/schema/autoyast/rng/profile.rng that should already contain all known sections Effort: Hard(er) Maintenance: Either hard-coded list of false-positives or schema Disadvantage: XML parser to read and understand profile.rng, but profile us not up to date anyway, e.g., <globals/> is missing there. I like the #2 the most, but fixing Yast to correctly evaluate some entries could lead into change of the current behaviour. There is too much hard-coded information now. So, what do you think? I don't want to over-engineer a simple thing but I'd like to bring some value too. And I don't want to cause a few new bugs ;) Thx Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 17.4.2015 v 16:16 Lukas Ocilka napsal(a):
Hi,
I'm a little bit stuck between added-value and implementation details for the $SUBJECT bug. Long story short, we have dropped yast2-sshd package that used to implement configuration for sshd in AutoYast.
[...]
1. Handle only sections known to be dropped
I'd prefer this solution because it is simple to implement. How many bug reports of this kind we have got? And how often we drop a module with AutoYast support so would need to update the list? IMHO this has the best effort/value ratio. Also this is the least intrusive change as we really know which modules have been dropped (no need to maintain false positives which could get outdated). I know that our customers are very creative when using Autoyast, I'd be really careful with checking the used profile.
2. Compare the profile with what the currently installed system can configure
Too complicated IMHO and finding and keeping false positives might be difficult.
3. Compare the profile with currently installed schema
Here I'd be afraid of outdated schema...
So, what do you think? I don't want to over-engineer a simple thing but I'd like to bring some value too. And I don't want to cause a few new bugs ;)
I'd start with solution 1. (the simpler the less bugs ;-)) and if it won't be enough we could improve it later either using 2. or 3. depending on the missing use case for 1. Just keep it simple. -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/21/2015 02:32 PM, Ladislav Slezak wrote:
I'd start with solution 1. (the simpler the less bugs ;-)) and if it won't be enough we could improve it later either using 2. or 3. depending on the missing use case for 1.
Just keep it simple.
I agree with Ladislav. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/17/2015 04:16 PM, Lukas Ocilka wrote:
Hi,
I'm a little bit stuck between added-value and implementation details for the $SUBJECT bug. Long story short, we have dropped yast2-sshd package that used to implement configuration for sshd in AutoYast.
Someone has tried an old AutoYast profile with <sshd/> settings and was surprised not to have sshd configured accordingly. They have asked for getting a warning / error report about it.
There are several possibilities how to solve it with different level of benefit for the customer, maintenance effort in the future and cleanness of the solution.
1. Handle only sections known to be dropped Benefit: Inform about dropped support of <sshd/>, ...? Solution: Hard-coded list of dropped sections Effort: Low Maintenance: List of dropped modules Disadvantage: Doesn't report unknown sections
I don't really like this section because different products (even SLES vs. SLED) may have different YaST modules. Then you would need to maintain such list for each product separately. Short-term solution / quick hack OK if necessary, but I'd avoid it.
2. Compare the profile with what the currently installed system can configure Benefit: Inform about all unknown sections and also known sections that cannot be handled because of some missing Yast packages Solution: Using the current AutoYast functionality for parsing desktop files that maps "X-SuSE-YaST-AutoInstResource" entries to the profile (Y2ModuleConfig.ModuleMap.keys - Profile.current.keys - ["globals", "language", "networking", "user_defaults" ...]) Effort: Medium Maintenance: Hard-coded list of false-positives Disadvantage: The current implementation doesn't seem to recognize some entries, such as ["globals", "language", "networking", "user_defaults" ...], for instance, "language"/"keyboard" is hard-coded in clients/inst_autosetup.rb
I think that this option looks best to me, since it honors also "what is currently installed" and reports an error in such case. I don't think that any of the other options inform you when the package selection is the reason why something cannot be configured.
3. Compare the profile with currently installed schema Benefit: Handle only unknown sections Solution: Parse /usr/share/YaST2/schema/autoyast/rng/profile.rng that should already contain all known sections Effort: Hard(er) Maintenance: Either hard-coded list of false-positives or schema Disadvantage: XML parser to read and understand profile.rng, but profile us not up to date anyway, e.g., <globals/> is missing there.
One thing I like on this approach is that it will force us to keep the profile up-to-date, I don't think that we are doing a good job here. OTOH, we have a single profile per code stream, not per product (which will fail in case of module being part of some products only). HTH, Jiri
I like the #2 the most, but fixing Yast to correctly evaluate some entries could lead into change of the current behaviour. There is too much hard-coded information now.
So, what do you think? I don't want to over-engineer a simple thing but I'd like to bring some value too. And I don't want to cause a few new bugs ;)
Thx Lukas
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
From my point of view an error message like: "AutoYaST section <section_name> cannot be handled because <absolute path to section_name_auto.rb> cannot be found. It seems that
Hm, I would be more pragmatically here. Please keep in mind that the autoinst.xml file will be generated just one time by a very experienced person. the needed package has not been installed" Then the admin will have a look which package supports that file and why the package has not been installed. (May be there could be a package conflict too :-)) Greetings Stefan Am 23.04.2015 um 10:05 schrieb Jiri Srain:
On 04/17/2015 04:16 PM, Lukas Ocilka wrote:
Hi,
I'm a little bit stuck between added-value and implementation details for the $SUBJECT bug. Long story short, we have dropped yast2-sshd package that used to implement configuration for sshd in AutoYast.
Someone has tried an old AutoYast profile with <sshd/> settings and was surprised not to have sshd configured accordingly. They have asked for getting a warning / error report about it.
There are several possibilities how to solve it with different level of benefit for the customer, maintenance effort in the future and cleanness of the solution.
1. Handle only sections known to be dropped Benefit: Inform about dropped support of <sshd/>, ...? Solution: Hard-coded list of dropped sections Effort: Low Maintenance: List of dropped modules Disadvantage: Doesn't report unknown sections
I don't really like this section because different products (even SLES vs. SLED) may have different YaST modules. Then you would need to maintain such list for each product separately. Short-term solution / quick hack OK if necessary, but I'd avoid it.
2. Compare the profile with what the currently installed system can configure Benefit: Inform about all unknown sections and also known sections that cannot be handled because of some missing Yast packages Solution: Using the current AutoYast functionality for parsing desktop files that maps "X-SuSE-YaST-AutoInstResource" entries to the profile (Y2ModuleConfig.ModuleMap.keys - Profile.current.keys - ["globals", "language", "networking", "user_defaults" ...]) Effort: Medium Maintenance: Hard-coded list of false-positives Disadvantage: The current implementation doesn't seem to recognize some entries, such as ["globals", "language", "networking", "user_defaults" ...], for instance, "language"/"keyboard" is hard-coded in clients/inst_autosetup.rb
I think that this option looks best to me, since it honors also "what is currently installed" and reports an error in such case. I don't think that any of the other options inform you when the package selection is the reason why something cannot be configured.
3. Compare the profile with currently installed schema Benefit: Handle only unknown sections Solution: Parse /usr/share/YaST2/schema/autoyast/rng/profile.rng that should already contain all known sections Effort: Hard(er) Maintenance: Either hard-coded list of false-positives or schema Disadvantage: XML parser to read and understand profile.rng, but profile us not up to date anyway, e.g., <globals/> is missing there.
One thing I like on this approach is that it will force us to keep the profile up-to-date, I don't think that we are doing a good job here. OTOH, we have a single profile per code stream, not per product (which will fail in case of module being part of some products only).
HTH, Jiri
I like the #2 the most, but fixing Yast to correctly evaluate some entries could lead into change of the current behaviour. There is too much hard-coded information now.
So, what do you think? I don't want to over-engineer a simple thing but I'd like to bring some value too. And I don't want to cause a few new bugs ;)
Thx Lukas
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 23 Apr 2015 10:23:35 +0200 Stefan Schubert <schubi@novell.com> wrote:
Hm, I would be more pragmatically here. Please keep in mind that the autoinst.xml file will be generated just one time by a very experienced person. From my point of view an error message like: "AutoYaST section <section_name> cannot be handled because <absolute path to section_name_auto.rb> cannot be found. It seems that the needed package has not been installed"
Well, it is more confusing message, as autoyast install yast packages that they need, so we should report that section is no longer supported and won't be configured.
Then the admin will have a look which package supports that file and why the package has not been installed. (May be there could be a package conflict too :-))
I hope in case of conflict we report it to user anyway, not? Josef
Greetings Stefan
Am 23.04.2015 um 10:05 schrieb Jiri Srain:
On 04/17/2015 04:16 PM, Lukas Ocilka wrote:
Hi,
I'm a little bit stuck between added-value and implementation details for the $SUBJECT bug. Long story short, we have dropped yast2-sshd package that used to implement configuration for sshd in AutoYast.
Someone has tried an old AutoYast profile with <sshd/> settings and was surprised not to have sshd configured accordingly. They have asked for getting a warning / error report about it.
There are several possibilities how to solve it with different level of benefit for the customer, maintenance effort in the future and cleanness of the solution.
1. Handle only sections known to be dropped Benefit: Inform about dropped support of <sshd/>, ...? Solution: Hard-coded list of dropped sections Effort: Low Maintenance: List of dropped modules Disadvantage: Doesn't report unknown sections
I don't really like this section because different products (even SLES vs. SLED) may have different YaST modules. Then you would need to maintain such list for each product separately. Short-term solution / quick hack OK if necessary, but I'd avoid it.
2. Compare the profile with what the currently installed system can configure Benefit: Inform about all unknown sections and also known sections that cannot be handled because of some missing Yast packages Solution: Using the current AutoYast functionality for parsing desktop files that maps "X-SuSE-YaST-AutoInstResource" entries to the profile (Y2ModuleConfig.ModuleMap.keys - Profile.current.keys - ["globals", "language", "networking", "user_defaults" ...]) Effort: Medium Maintenance: Hard-coded list of false-positives Disadvantage: The current implementation doesn't seem to recognize some entries, such as ["globals", "language", "networking", "user_defaults" ...], for instance, "language"/"keyboard" is hard-coded in clients/inst_autosetup.rb
I think that this option looks best to me, since it honors also "what is currently installed" and reports an error in such case. I don't think that any of the other options inform you when the package selection is the reason why something cannot be configured.
3. Compare the profile with currently installed schema Benefit: Handle only unknown sections Solution: Parse /usr/share/YaST2/schema/autoyast/rng/profile.rng that should already contain all known sections Effort: Hard(er) Maintenance: Either hard-coded list of false-positives or schema Disadvantage: XML parser to read and understand profile.rng, but profile us not up to date anyway, e.g., <globals/> is missing there.
One thing I like on this approach is that it will force us to keep the profile up-to-date, I don't think that we are doing a good job here. OTOH, we have a single profile per code stream, not per product (which will fail in case of module being part of some products only).
HTH, Jiri
I like the #2 the most, but fixing Yast to correctly evaluate some entries could lead into change of the current behaviour. There is too much hard-coded information now.
So, what do you think? I don't want to over-engineer a simple thing but I'd like to bring some value too. And I don't want to cause a few new bugs ;)
Thx Lukas
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Am 23.04.2015 um 11:04 schrieb Josef Reidinger:
On Thu, 23 Apr 2015 10:23:35 +0200 Stefan Schubert <schubi@novell.com> wrote:
Hm, I would be more pragmatically here. Please keep in mind that the autoinst.xml file will be generated just one time by a very experienced person. From my point of view an error message like: "AutoYaST section <section_name> cannot be handled because <absolute path to section_name_auto.rb> cannot be found. It seems that the needed package has not been installed" Well, it is more confusing message, as autoyast install yast packages that they need, so we should report that section is no longer supported and won't be configured. OK, that would be more generic. I am fine with this message.
Then the admin will have a look which package supports that file and why the package has not been installed. (May be there could be a package conflict too :-)) I hope in case of conflict we report it to user anyway, not? It should, yes indeed. But I have never tried it :-)
Greetings Stefan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 23.4.2015 v 10:05 Jiri Srain napsal(a):
1. Handle only sections known to be dropped [...] I don't really like this section because different products (even SLES vs. SLED) may have different YaST modules.
I do not think this is a problem, if we want to support just dropped modules than it's OK (if we drop a module it's dropped from both SLES and SLED). IIRC the profiles should be created on a machine with the same product, do we really support creating profile on SLES and using it for SLED installations? The validation cannot be 100% perfect, e.g. some packages are SLES or SLED only, but the software section structure is the same for both...
2. Compare the profile with what the currently installed system can configure
I think that this option looks best to me, since it honors also "what is currently installed" and reports an error in such case. I don't think that any of the other options inform you when the package selection is the reason why something cannot be configured.
I agree it's better than 1., but it's more complicated for implementation...
3. Compare the profile with currently installed schema
One thing I like on this approach is that it will force us to keep the profile up-to-date, I don't think that we are doing a good job here.
That's true. On the other hand I know that some customers use AutoYast in many crazy situations... BTW what about the possible 3rd party AY modules? AFAIK the schema is generated only for our modules... IMHO we are a bit over engineering here, the initial issue was dropped yast2-ssh module, solution 1. should be enough for this case... -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/23/2015 10:45 AM, Ladislav Slezak wrote:
Dne 23.4.2015 v 10:05 Jiri Srain napsal(a):
1. Handle only sections known to be dropped [...] I don't really like this section because different products (even SLES vs. SLED) may have different YaST modules.
I do not think this is a problem, if we want to support just dropped modules than it's OK (if we drop a module it's dropped from both SLES and SLED).
IIRC the profiles should be created on a machine with the same product, do we really support creating profile on SLES and using it for SLED installations?
yes, OTOH the modules can also be written manually :-)
The validation cannot be 100% perfect, e.g. some packages are SLES or SLED only, but the software section structure is the same for both...
2. Compare the profile with what the currently installed system can configure
I think that this option looks best to me, since it honors also "what is currently installed" and reports an error in such case. I don't think that any of the other options inform you when the package selection is the reason why something cannot be configured.
I agree it's better than 1., but it's more complicated for implementation...
That's right.
3. Compare the profile with currently installed schema
One thing I like on this approach is that it will force us to keep the profile up-to-date, I don't think that we are doing a good job here.
That's true. On the other hand I know that some customers use AutoYast in many crazy situations... BTW what about the possible 3rd party AY modules? AFAIK the schema is generated only for our modules...
Good point :-)
IMHO we are a bit over engineering here, the initial issue was dropped yast2-ssh module, solution 1. should be enough for this case...
The question is if we want to focus on the initial issue or find a more useful solution. If we have manually-written profiles, the later options will also catch typos. I to some extent like doing the checks against the real system than just against a hardcoded list, however, if the amount of work is too different, I will not push that. Jiri
--
Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 23.4.2015 10:45, Ladislav Slezak wrote:
Dne 23.4.2015 v 10:05 Jiri Srain napsal(a):
1. Handle only sections known to be dropped [...] I don't really like this section because different products (even SLES vs. SLED) may have different YaST modules.
I do not think this is a problem, if we want to support just dropped modules than it's OK (if we drop a module it's dropped from both SLES and SLED).
IIRC the profiles should be created on a machine with the same product, do we really support creating profile on SLES and using it for SLED installations?
The validation cannot be 100% perfect, e.g. some packages are SLES or SLED only, but the software section structure is the same for both...
You're right that the bugreport is about module that has been dropped, but the user did not know. On the other hand, I'm looking for additional value to the customer. AutoYast is a big beast with a lot of "grey behaviour". When I'm touching some part, I want it to be better than before. Reporting that <sshd> has been dropped solves the current problem, but only that one. The question is: How much do we care? I myself would like to save some development/debugging time in the future.
2. Compare the profile with what the currently installed system can configure
I think that this option looks best to me, since it honors also "what is currently installed" and reports an error in such case. I don't think that any of the other options inform you when the package selection is the reason why something cannot be configured.
I agree it's better than 1., but it's more complicated for implementation...
As I said in the original e-mail, this is a preferred solution for me, but it has pros and cons. The biggest advantage is that it provides dynamic information based on the current installation/profile. For instance, if some package is missing in the profile, then user will find out easily without reporting an L3.
3. Compare the profile with currently installed schema
One thing I like on this approach is that it will force us to keep the profile up-to-date, I don't think that we are doing a good job here.
That's true. On the other hand I know that some customers use AutoYast in many crazy situations... BTW what about the possible 3rd party AY modules? AFAIK the schema is generated only for our modules...
Good point with 3rd party modules.
IMHO we are a bit over engineering here, the initial issue was dropped yast2-ssh module, solution 1. should be enough for this case...
My intention is to provide a generic solution without need to touch the code every time we change something. Hard coding some non-generic information is IMO a way to hell. AutoYast should behave similarly to Installation - just a framework. The current code often doesn't look like that. Would it pay off? That's the question. Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (6)
-
Ancor Gonzalez Sosa -
Jiri Srain -
Josef Reidinger -
Ladislav Slezak -
Lukas Ocilka -
Stefan Schubert