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

Reply via email to