[yast-devel] Automatic AutoYaST Schema Validation
Hi all, As you may know, we introduced automatic profile validation in AutoYaST for SLE 15 SP3 and Tumbleweed. When the profile is not correct, AutoYaST complains at the beginning of the autoinstallation. So, as expected, we are getting regular bug reports from openQA. In some cases, the profile is just wrong. However, we have detected several problems in yast2-schema. Although you can disable this feature at boot time (setting YAST_SKIP_XML_VALIDATION to 1), I fear that we are going to get a ton of errors from our users and customers. So I was considering whether we should disable this feature by default, although in that case I would ask openQA to enable it so we can improve yast2- schema quality. What is your point of view? Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
Hi Imo, Thanks for raising this point, as I'm looking into the failures right now. I also made the point clear to other teams, that it can be issue with the profile or a bug and official documentation should be used as a source of truth. I believe that skipping validation by default is not a bad idea, at least until we address all the current failures. One thing, which I didn't not understood yet, is that if I run jing locally, I don't get the errors which are reported by the installer. Is it a sign that it's a bug in schema? Looking forward to hearing from you. On 9/25/20 11:29 AM, Imobach González Sosa wrote:
Hi all,
As you may know, we introduced automatic profile validation in AutoYaST for SLE 15 SP3 and Tumbleweed. When the profile is not correct, AutoYaST complains at the beginning of the autoinstallation. So, as expected, we are getting regular bug reports from openQA.
In some cases, the profile is just wrong. However, we have detected several problems in yast2-schema.
Although you can disable this feature at boot time (setting YAST_SKIP_XML_VALIDATION to 1), I fear that we are going to get a ton of errors from our users and customers.
So I was considering whether we should disable this feature by default, although in that case I would ask openQA to enable it so we can improve yast2- schema quality.
What is your point of view?
Regards, Imo
-- Kind regards, Rodion Iafarov <riafarov@suse.com> QA Engineer Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
El viernes, 25 de septiembre de 2020 10:37:01 (WEST) Rodion Iafarov escribió:
Hi Imo,
Hi Rodion,
Thanks for raising this point, as I'm looking into the failures right now. I also made the point clear to other teams, that it can be issue with the profile or a bug and official documentation should be used as a source of truth.
Thanks for addressing it. Yes, the official documentation should be the source of truth. And if something is not documented, we need to fix it. Thanks to openQA tests we have already fixed a bunch of issues in the schema and in the documentation.
I believe that skipping validation by default is not a bad idea, at least until we address all the current failures.
Yes, I think it makes sense to introduce it in two steps. First, we can announce this feature (and even recommend the users to enable it). And then we can think about enabling it by default. In QA it would be nice to keep it enable, as it allows as to catch those problems.
One thing, which I didn't not understood yet, is that if I run jing locally, I don't get the errors which are reported by the installer. Is it a sign that it's a bug in schema?
Usually yes. In that situation, most likely the problem has been fixed already but the yast2-schema included in the installation media might be too old. So it works in your system (with the updated yast2-schema package) but it does not work during installation.
Looking forward to hearing from you.
Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
Hi Imo, Thanks for the prompt reply! On 9/25/20 12:08 PM, Imobach González Sosa wrote:
El viernes, 25 de septiembre de 2020 10:37:01 (WEST) Rodion Iafarov escribió:
Hi Imo, Hi Rodion,
Thanks for raising this point, as I'm looking into the failures right now. I also made the point clear to other teams, that it can be issue with the profile or a bug and official documentation should be used as a source of truth. Thanks for addressing it. Yes, the official documentation should be the source of truth. And if something is not documented, we need to fix it. Thanks to openQA tests we have already fixed a bunch of issues in the schema and in the documentation.
I believe that skipping validation by default is not a bad idea, at least until we address all the current failures. Yes, I think it makes sense to introduce it in two steps. First, we can announce this feature (and even recommend the users to enable it). And then we can think about enabling it by default.
In QA it would be nice to keep it enable, as it allows as to catch those problems.
One thing, which I didn't not understood yet, is that if I run jing locally, I don't get the errors which are reported by the installer. Is it a sign that it's a bug in schema? Usually yes. In that situation, most likely the problem has been fixed already but the yast2-schema included in the installation media might be too old. So it works in your system (with the updated yast2-schema package) but it does not work during installation.
This is confusing, as I take schema files from the system, so I'm surprised that installer shows different errors. We use one located at "/usr/share/YaST2/schema/autoyast/rng"> I have a feeling that it might be also reporting issue, as in one of the cases I got jing complaining about `partition_alignment` node, but installer complains about parent node, which is `general`. After I've removed this node, installer started to complain about `bootloader` section, but jing check passes. Anyway, we can discuss it case by case in the reported bugs. Thanks again!
Looking forward to hearing from you. Regards, Imo
-- Kind regards, Rodion Iafarov <riafarov@suse.com> QA Engineer Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
El viernes, 25 de septiembre de 2020 11:23:17 (WEST) usted escribió:
Hi Imo,
Thanks for the prompt reply!
On 9/25/20 12:08 PM, Imobach González Sosa wrote:
El viernes, 25 de septiembre de 2020 10:37:01 (WEST) Rodion Iafarov escribió:
Hi Imo,
Hi Rodion,
Thanks for raising this point, as I'm looking into the failures right now. I also made the point clear to other teams, that it can be issue with the profile or a bug and official documentation should be used as a source of truth.
Thanks for addressing it. Yes, the official documentation should be the source of truth. And if something is not documented, we need to fix it. Thanks to openQA tests we have already fixed a bunch of issues in the schema and in the documentation.
I believe that skipping validation by default is not a bad idea, at least until we address all the current failures.
Yes, I think it makes sense to introduce it in two steps. First, we can announce this feature (and even recommend the users to enable it). And then we can think about enabling it by default.
In QA it would be nice to keep it enable, as it allows as to catch those problems.
One thing, which I didn't not understood yet, is that if I run jing locally, I don't get the errors which are reported by the installer. Is it a sign that it's a bug in schema?
Usually yes. In that situation, most likely the problem has been fixed already but the yast2-schema included in the installation media might be too old. So it works in your system (with the updated yast2-schema package) but it does not work during installation.
This is confusing, as I take schema files from the system, so I'm surprised that installer shows different errors. We use one located at "/usr/share/YaST2/schema/autoyast/rng"> I have a feeling that it might be also reporting issue, as in one of the cases I got jing complaining about `partition_alignment` node, but installer complains about parent node, which is `general`. After I've removed this node, installer started to complain about `bootloader` section, but jing check passes. Anyway, we can discuss it case by case in the reported bugs.
Well, the problem with jing and libxml2 is that do not report the same error. Usually jing is much better at reporting where the problem is. Unfortunately, it is implemented in Java, so we cannot ship it on the installation media. As you have said, let's discuss case by case. If you find the same situation again, let me know and we can try to dig deeper. Maybe I am missing something.
Thanks again!
You are welcome! Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
Hey Imo, Am 25.09.20 um 12:51 schrieb Imobach González Sosa:
Well, the problem with jing and libxml2 is that do not report the same error. Usually jing is much better at reporting where the problem is. Unfortunately, it is implemented in Java, so we cannot ship it on the installation media.
can you hint me on what would be the technical issue with Java on the installation media? Cheers, Bernd -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Fri, 25 Sep 2020 12:58:23 +0200 Bernd Ritter <commel@gmail.com> wrote:
Hey Imo,
Am 25.09.20 um 12:51 schrieb Imobach González Sosa:
Well, the problem with jing and libxml2 is that do not report the same error. Usually jing is much better at reporting where the problem is. Unfortunately, it is implemented in Java, so we cannot ship it on the installation media.
can you hint me on what would be the technical issue with Java on the installation media?
Cheers, Bernd
Issue is size and memory restrictions. Installation system is limited and we still have minimal system requirements around 512MiB of RAM ( not sure if it include graphical installation or not ). But even with 1 GiB java is too much memory demanding and its disk footprint is too big. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 25. 09. 20 v 12:08 Imobach González Sosa napsal(a):
Yes, I think it makes sense to introduce it in two steps. First, we can announce this feature (and even recommend the users to enable it). And then we can think about enabling it by default.
I'd prefer it the other way round (i.e. keep the current enabled status). If we disable it by default many users will not know this new feature and they will not run the validation at all. We would just postpone the problems for later. So far I have seen just few bugs regarding validation, I believe until SP3 GM we fix most of them and therefore we should keep it enabled. If we find a specific bug later we can always tell the customers to manually disable the validation. Of course, if we get a lot of bug reports in Beta phase we can change the default, I do not want to have that feature enabled at any cost. -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
El lunes, 5 de octubre de 2020 15:53:58 (WEST) Ladislav Slezak escribió:
Dne 25. 09. 20 v 12:08 Imobach González Sosa napsal(a):
Yes, I think it makes sense to introduce it in two steps. First, we can announce this feature (and even recommend the users to enable it). And then we can think about enabling it by default.
I'd prefer it the other way round (i.e. keep the current enabled status).
If we disable it by default many users will not know this new feature and they will not run the validation at all. We would just postpone the problems for later.
That's true.
So far I have seen just few bugs regarding validation, I believe until SP3 GM we fix most of them and therefore we should keep it enabled. If we find a specific bug later we can always tell the customers to manually disable the validation.
Of course, if we get a lot of bug reports in Beta phase we can change the default, I do not want to have that feature enabled at any cost.
Yes, you are right. We are still in time to make the decision later if needed. We have fixed several problems, including a P1[1]. And I expect the amount of validation reports to decrease over time. We will keep an eye on them anyway. Regards, Imo [1] https://github.com/yast/yast-schema/pull/90 -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
Hi Imo, my first stance here was not to annoy the user. But autoyast is used by not ordinary users but mostly technical personal. They should know when there is a problem with the autoyast-xml. Can this just be just a warning? And why does autoyast accept wrong xml schemata? Your suggestion sounds like a good middle way between keeping things working as they are now and being able to improve quality. Cheers, Bernd Am 25.09.20 um 11:29 schrieb Imobach González Sosa:
Hi all,
As you may know, we introduced automatic profile validation in AutoYaST for SLE 15 SP3 and Tumbleweed. When the profile is not correct, AutoYaST complains at the beginning of the autoinstallation. So, as expected, we are getting regular bug reports from openQA.
In some cases, the profile is just wrong. However, we have detected several problems in yast2-schema.
Although you can disable this feature at boot time (setting YAST_SKIP_XML_VALIDATION to 1), I fear that we are going to get a ton of errors from our users and customers.
So I was considering whether we should disable this feature by default, although in that case I would ask openQA to enable it so we can improve yast2- schema quality.
What is your point of view?
Regards, Imo
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On 2020-09-25 11:42, Bernd Ritter wrote (excerpts):
... autoyast is used ... by ... mostly technical personal. ... Can this just be just a warning?
Cf. "WARNING is a waste of my time" at https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html where he explains his admin's piont of view about WARNING messages and also see his "DevOpsDays 2015 Presentation" therein. For our (i.e. his and my) reasoning behind see https://github.com/rear/rear/issues/564 there starting at https://github.com/rear/rear/issues/564#issuecomment-86188528 and then the subsequent comments terein. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (6)
-
Bernd Ritter -
Imobach González Sosa -
Johannes Meixner -
josef Reidinger -
Ladislav Slezak -
Rodion Iafarov