[Libosinfo] Resources inheritance for OSes, I need some help/feedback!
Daniel P. Berrangé
berrange at redhat.com
Tue Nov 13 09:58:02 UTC 2018
On Tue, Nov 13, 2018 at 10:10:17AM +0100, Fabiano Fidêncio wrote:
> People,
>
> I'm working on making OsinfoResources inherited for OSes that derives-
> from/clones another OSes. The inheritance, IMO, should work like:
> - os1 has:
> <resources arch="all">
> <minimum>
> <cpu>1000000000</cpu>
> <ram>1073741824</ram>
> </minimum>
> </resources>
>
> - os2, which inherits the values from os1, has:
> <resources arch="all">
> <minimum>
> <n-cpus>2</n-cpus>
> </minimum>
> </resources>
I wonder about making inheritance explicit, eg for os2, have
<resources arch="all" inherit="yes">
<minimum>
<n-cpus>2</n-cpus>
</minimum>
</resources>
the benefit of this is that.... [1]
> - When calling osinfo_resources_get_cpu(os2), I'd expect to get:
> 1000000000.
>
>
> In order to achieve so, we'll need a few more changes in the way
> resources are added to OSes:
> - Do *not* have duplicated resources for the same OS;
> - This can be easily done in osinfo_os_add_*_resources() + tests to
> catch this situation;
> - Do *not* have more than one resources with the same arch for the same
> OS;
> - Although this can be easily done in osinfo_os_add_*_resources() as
> well, I'd go only for tests to catch this situation;
These points look tangential to inheritance to me. Or to put it another
way, shouldn't we ensure uniqueness regardless of whether we have
inheritance or not.
> - Have a way to specify that a resource field shouldn't be inherited;
> - Here I can basically see two different approaches, and my personal
> preference would be the former:
> - A specific value to be set to the field that will just be checked
> when merging the resources' content when doing the inheritance
> (suggestions are welcome and remember we can't use -1);
> - Add an extra attribute to the elements and have a new structure
> (similar to DeviceLinks) and play with it in the same way I proposed
> for removed devices*.
[1]...you solve this problem more attractively IMHO.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the Libosinfo
mailing list