Hi Dan, On 31.05.2012 [23:34:18 +0000], DeFolo, Daniel wrote: > > > > > 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
Ok, great, thanks for the pointer, I'll read up. > > 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" Yep, I think what you're saying (and I agree with) is that there are "host" attributes and there are host HW attributes. > 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. Yeah, that sounds like a clean transition and makes sense to me. > 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 Agreed. > > 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. I think we could also do this for the basic features (CPU type, # CPUs, amount of memory, I'd say) with a simple sub-form. Translate it to SQL syntax. So it would look a lot like the control file generating logic in the UI. But the core search path would be SQL. 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