Hi Steve, On Wed, Jan 16, 2013 at 12:06 PM, Steve Fisher <dr.s.m.fisher@gmail.com> wrote:
On 16 January 2013 09:14, Andre Merzky <andre@merzky.net> wrote:
Hi Steve,
Either way, thanks for the comments. This will likely mean that we'll trim down the resource API to simply perform
- describe resource - acquire resource - release resurce - get job/data service for resource
Best, Andre.
Andre,
I am happy with the first three operations - the last is less nice as not all resources will be able to support, for example, getJobService(). Better perhaps would be getService() where the Service is the same Service class that SD provides. This would support services of any type.
Steve
Well, we do have different resource types (*), and so far I don't see a reason nor argument to change that. So, for a compute resource, I would expect to always be able to retrieve a job service endpoint, for a StorageResource, I would expect to get a filesystem or replica endpoint. Also please consider that the main use case for the resource package is basically: - create a vm - run a couple of jobs on the VM Originally, that was supposed to look like: vm = resource_manager.aquire_resource (resource_description) vm.create_job (job_description) As we now want to decouple the resource and job parts, this will likely look like: vm = resource_manager.aquire_resource (resource_description) js = vm.get_job_service () js.create_job (job_description) Yes, adding a generic service inspection / retrieval to the resource makes the package more generic, obviously -- but it will make the main use cases more complex, too (error checks left out): vm = resource_manager.aquire_resource (resource_description) sds = vm.get_service_descriptions () js = None for sd in sds : if sd.type == 'saga.job.service' : js = saga.job.service (sd.url) break js.create_job (job_description) or, if you allow the filters on the sd retrieval: vm = resource_manager.aquire_resource (resource_description) sds = vm.get_service_descriptions (service_filter='Capabilities="org.ogf.saga.service.job"') js = saga.job.service (sds[0].url) js.create_job (job_description) I rather see the role for SD/ISN to be used for inspection purposes, to understand / inform the application about the properties of the resources (number or CPUs, load, lifetime, ...) -- we do have dynamic scheduling use cases which would need that kind of information about the resources, and I'd rather expose those data via the existing SD/ISN packages that getting them out-of-band... My $0.02, Andre. (*) although in the reduced resource package scope, we don't have any use for network resources anymore. -- There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton