On Thu, 23 Apr 2015 10:23:35 +0200 Stefan Schubert 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 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

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 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