[Automated-testing] Farming together - areas of collobration

[Kieran Bingham]

On 15/11/17 22:55, Andrew MURRAY wrote:
>> -----Original Message----- From: Bird, Timothy [mailto:Tim.Bird at sony.com]
> 
> Thanks for the feedback.
> 

<lots of snipping>

>>> 
>>> My vision of a farm is that it would consist of three distinct layers...
>> 
>> I think defining the layering is good.  It will be good to figure out, if 
>> something breaks the layering or has different layering, why it has done 
>> so, and why.  Is it something architectural that ties things together? Or 
>> just convenience and not considering other use cases that could benefit 
>> from more modular approaches?
> 
> Indeed, I guess we need to understand the use cases and model them.
> 
>> 
>>> The Grass - This is the bottom layer which provides the bare minimum 
>>> software abstraction to the fundamental capabilities of the farm. This 
>>> consists of physical devices and suitable drivers for them. The interface
>>> to higher layers is of the language of turn power port 2 on, bridge relay
>>> 5 on, etc. The goal here is for us to be able pick up some hardware off
>>> the shelf (e.g. a APC power switch) and to have a 'driver' already
>>> available from this community that fits into this view of the world. In
>>> order to achieve this it would be necessary to define categories of
>>> devices (power, relay, serial), the verbs (power cycle, power off, etc)
>>> and a way of addressing physical devices.
>> 
>> Agreed.  I have thought it would be good to do some kind of survey to see 
>> what people are already doing here.  The tools I know of in this space
>> are: - labgrid - ttc - libvirt/virsh  (I only just learned about this one
>> at ELCE) - pduclient
> 
> In an effort to understand the existing market, you're right we should survey
> what is already available. I think it would be helpful to construct a grid
> like table on elinux to understand the capabilities and reach of these 
> utilities. For example some of these (labgrid) go beyond just the 'Grass' 
> layer. I can start this.


If we can follow libvirt API's in some fashion or at least provide an
abstraction layer for libvirt - then that will open up a whole range of existing
tooling that could work directly for us.

There is already a lot of infrastructure for dealing with virtual devices [0],
and a virtual machine does by definition share quite a lot in common with an
embedded board in a farm. It has an interface to get a serial console, it knows
how to power on / off, provide a kernel and rootfs ....

When I've started looking into this I came across the Kimchi [1] project which
provides an implementation somewhat like DigitalOcean/AmazonLightsail for
providing access and control over virtual server instances.

I suspect there may be quite a lot of usable code there to use that as a high
level web interface for controlling a farm, or at least some early design
suggestions.

[0] http://www.linux-kvm.org/page/Management_Tools
[1] https://github.com/kimchi-project/kimchi


>> Finally, who is leading this thing?  I'm happy to participate, but can't 
>> spare the time to actually lead.  And how will decisions about a standard 
>> get made?  Who has "approval" authority, or are we just trying to come up 
>> with software and solutions that are so good they will get adopted as 
>> de-facto standards?
> 
> This is something I'm passionate about - I'm happy to take lead but concerned
> I may be overcommitting my time.
> 
> Also quite frankly, I don't know by what methods these decisions are normally
> made. I don't know the processes in which standards bodies come up with new
> standards or how to start a community. This is all new.
> 
> But we have a collection of people building possibly with a common goal. 
> Perhaps we should wait and see what happens next.
> 
>> 
>> Will there be a committee organized?  Do we have regular meetings at ELCE?

I think that would make sense, I'm sure many of us are regular attendees.

>> 
>> I'd love to see this move forward, and will help where I can.

Like all of us, I don't have many spare cycles, but I too can offer some along
the way.

-- 
Regards

Kieran Bingham

-- 
--
Kieran