Attendees: 
	Local: Maarten, Miguel, Stefan
	Remote: Dirk, Manfred
	Apologies: Ulrich, Jan Just

Status of action Items:

	•	Define the structure of the features to be returned to the VO payload (e.g. json)

Done, a first draft for the data structure has been made available at https://twiki.cern.ch/twiki/bin/view/LCG/MjfDataStructureAndInterface. 

	•	Define and implement a tool which gathers the information on a bare metal batch system

Done, a tool "mjf.py" has been developed and gathers information on physical batch systems and returns the above mentioned data structure. See details on the twiki above. The tool can be used as command line or imported as a python module

	•	Deploy the system for physical batch systems on multiple grid sites and have it tested by VOs

In progress, we need to wait for the finalisation of the data structure and tool, get it deployed and have it tested by VOs. See also below for a more detailed plan in this area. 

	•	Understand the power number provided on virtualized WNs

Not started yet

	•	Test if we can provide dynamic information via "magic IPs" on IaaS systems

A test was carried out by Tim and succeeded for retrieving dynamic information for CERN/IaaS (openstack). We need to understand how this scales. Twiki with more information available at https://twiki.cern.ch/twiki/bin/view/AgileInfrastructure/SchedulingMetadata

Status and next steps for physical batch systems

A detailed plan for the next steps in this area is:
	1.	Finish up on mjf.py tool and create a rpm for easy deployment on sites
	2.	Invite sites who currently have machine features installed to also install above rpm
	3.	Finish up on a SAM probe to retrieve and test machine features and let it run through WLCG nagios (e.g. some non-critical profile)
	4.	Collect the information from SAM probes on the "test sites" and display it on a separate web page (through myEGI)
	5.	Check the gathered information and gain confidence in its validity
	6.	Invite VOs to also use the information provided on "test sites"
	7.	Ask for wider deployment of machine features on physical batch systems WLCG wide

Status and next steps for IaaS systems

	•	We need to understand which IaaS systems (openstack, opennebula, etc.) are currently being used on the grid. 
	•	"mjf.py" needs to be extended to also retrieve information on IaaS systems 
	•	Any other actions will be discussed at the next meeting with experts around the table. 

Aob

	•	A SAM probe was developed to retrieve information and test whether values make sense. This probe shall be used to gain experience / confidence in the values provided (see also plan for classical batch systems above).
	•	In general the task force will concentrate for the foreseeable future on the areas of "physical batch systems" and "private clouds (IaaS systems we "own").  
	•	Dirk: Condor is not part of the batch system types for which machine features have been implemented, we need to have an implementation especially in the OSG area. Maarten we can ask the Condor team to provide an implementation. Dirk: I will bring it up in the next CMS meeting with the Condor team and ask whether they can provide an implementation for the specification provided. 
	•	Next meeting tentatively Oct 8th, 14.00 

Action Items

	•	Plan for classical batch systems
	1.	Finish up on mjf.py tool and create a rpm for easy deployment on sites
	2.	Invite sites who currently have machine features installed to also install above rpm
	3.	Finish up on a SAM probe to retrieve and test machine features and let it run through WLCG nagios (e.g. some non-critical profile)
	4.	Collect the information from SAM probes on the "test sites" and display it on a separate web page (through myEGI)
	5.	Check the gathered information and gain confidence in its validity
	6.	Invite VOs to also use the information provided on "test sites"
	7.	Ask for wider deployment of machine features on physical batch systems WLCG wide
	•	Understand the power number provided on virtualized WNs
	•	Find out which IaaS systems are currently being tested / used within WLCG