Re: [yast-devel] Meeting about changes to xml schema
On 4/30/20 12:40 PM, josef Reidinger wrote:
[1] https://github.com/yast/yast-installation-control/pull/96
Checking the PR, I saw a diff from "disksize" to "string". That's right as there's no "disksize" data-type. We have also discussed that we should then modify our control.xml stored on disk during RPM-post-script (which is the right way as `zypper dup` is supported too). But I have a question: what happens in customers' AY profiles actually contain these "disksize" types? Are they going to be invalid? Should we replace/remove them when loading the profile first? I'd like to be careful here, because what used to be valid for ages now turns into invalid because of our internal change. That doesn't sound right even if our intentions were crystal clear. What do you think? Thx Lukas -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data ⚠ IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof. -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Thu, 30 Apr 2020 13:25:04 +0200
Lukas Ocilka
On 4/30/20 12:40 PM, josef Reidinger wrote:
[1] https://github.com/yast/yast-installation-control/pull/96
Checking the PR, I saw a diff from "disksize" to "string". That's right as there's no "disksize" data-type. We have also discussed that we should then modify our control.xml stored on disk during RPM-post-script (which is the right way as `zypper dup` is supported too).
But I have a question: what happens in customers' AY profiles actually contain these "disksize" types? Are they going to be invalid? Should we replace/remove them when loading the profile first? I'd like to be careful here, because what used to be valid for ages now turns into invalid because of our internal change. That doesn't sound right even if our intentions were crystal clear.
What do you think?
Thx Lukas
Yes, it is good point. Question to imo how it is exported by autoyast clone, as it is string and not disksize element. So unless storage use some kind of hack, I think it is not possible to get such type automatic. Of course user written partitioning can be problem if we mention this type in documentation. For that case we can accept it same as string. So it really depends if we write it during clone or mention it in documentation (btw not for ages as it is for storage-ng). In such cases we should mark this type as deprecated for SLE16 and remove it in SLE17? Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
El jue, 30-04-2020 a las 13:39 +0200, josef Reidinger escribió:
Yes, it is good point. Question to imo how it is exported by autoyast clone, as it is string and not disksize element. So unless storage use some kind of hack, I think it is not possible to get such type automatic. Of course user written partitioning can be problem if we mention this type in documentation. For that case we can accept it same as string. So it really depends if we write it during clone or mention it in documentation (btw not for ages as it is for storage-ng). In such cases we should mark this type as deprecated for SLE16 and remove it in SLE17?
Regarding AutoYaST, we are on the safe side. We do not consider or export that type. We simply use a regular string. Bear in mind that when dealing with the size, AutoYaST can receive a disk size, or "auto" or "max". Regards, Imo [1] https://github.com/yast/yast-storage-ng/blob/master/src/lib/y2storage/autoin... [2] https://github.com/yast/yast-storage-ng/blob/master/src/lib/y2storage/propos... -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
participants (3)
-
Imobach Gonzalez Sosa -
josef Reidinger -
Lukas Ocilka