On Tue, Nov 13, 2018 at 11:27:47AM +0100, Fabiano Fidêncio wrote: > On Tue, 2018-11-13 at 09:58 +0000, Daniel P. Berrangé wrote: > > 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] > > Okay, this idea makes things easier, I like it. > > > > > > - 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. > > What would be the use case of having different resources set for the > very same architecture in an OS? I don't see any need for it - I'm saying that we should ensure uniqueness regardless. It is just a separate (bug fix) work item from inheritance > > > > > > > - 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 > > Best Regards, > -- > Fabiano Fidêncio > 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 :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
