> > > Just FYI, we called our prior solution constraints based scheduling > > (as in HW and SW constraints being options) and had support for > > constraints being both hard and soft. The idea was that a hard > > constraint was similar to the autotest "only if needed" labels in that > > if a job didn't request a hard constraint explicitly it wouldn't be > > considered to match the host. I think I like your terminology (only > > if needed) better, and think it could equally be applied to HW > > attribute scheduling as for label based scheduling. That said, this > > would need to be a per-host & per-attribute setting, and not applied > > to every host that has the attribute (as opposed to how "only if > > needed" is currently a label specific attribute that would apply to > > every host that uses that label). Does that makes sense? > > Just to be clear, "only if needed" is the setting you mean?
Yes, I'm referring to the afe_labels.only_if_needed column in the DB which in turn maps to the discussion of "Only if needed" here: https://github.com/autotest/autotest/wiki/AdvancedJobScheduling > I've not actually > played much with labels. I'll need to look at the code and think over what you > wrote more. FYI. I think of labels as being the values of a HW attributes that just aren't in key=value form. For example I would think a host with the label "BOBS-BOX" is the same as having a HW attribute hash entry of: label = "BOBS_BOX" If we re-envision labels as admin provided hw attrib add-in values then when you get the scheduler piece you could have the same scheduler logic be used for both label and hw attribute based scheduling. In fact I think that is a requirement. Users need to be able to schedule using criteria that includes both labels and hw attribs: label = "FAVORITE" AND memory_mb > 4096 AND memory_mb < 8192 AND cpu_cores = 4 > > So I'm thinking of starting small, getting an RFC out there and then building > up from there: > > 1) Basic hardware inventory (using the first list from above), stored in > database columns per-host > * using standardized units (which will probably be part of the > column name for clarity > * statically display the information in host details > 2) Add ability to extend the inventory by the admin > * define fields and collection mechanism > 3) Add ability search for a host by hardware information > * but not handle the scheduling side of things, so there is > still manual work needing to be done by the user to get the > machines they want > 4) Hardware-aware scheduling, essentially meta-host scheduling but with > hardwrae constraints > I think this is a good list and I agree with starting small. When you get to both 3) and 4) we will need to decide how users will do the search. Will they just provide a SQL snippet? Use some sort of query builder to create the snippet? Or ?? My vote for what it is worth is to just have them provide the SQL (the entire where clause). That minimizes effort from an implementation perspective greatly. On the job creation page, below where they add the SQL snippet there could be buttons to preview which hosts would currently match. Also, if they are giving an SQL snippet they can be allowed to provide an ORDER BY statement so that of the matching systems, they can give nuanced preference to one end of the scale or the other: memory_mb >= 4096 AND cpu_cores >= 4 ORDER BY cpu_cores ASC, memory_mb ASC Would be equivalent of being able to say, any system > 4 GB memory and > 4 cores is ok, but there is more than 1 available, use the smaller one. > Thanks, > Nish > > -- > Nishanth Aravamudan <n...@us.ibm.com> > IBM Linux Technology Center _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
