<html><body>Dear Markus,<BR>
<BR>
Yes, you are right about the complexity. We are gathering information of the different techniques and software stacks used by different institutions to execute remote workflows and, obviously, we need to take them into consideration. There are two clear options; use one of them for the IVOA (what looks complicated as we are not imposing software stacks in the IVOA) or define an abstraction/simple layer. In any case, the first option is also a possibility (although we already know that our technologies do not look to be compatible).<BR>
<BR>
Although knowing that this effort is quite complex, there is a need for some of our astronomical projects to provide a global solution for this problem (including new astronomical missions that provide a huge amount of data) so it is something we need to address.<BR>
<BR>
Being optimistic, I think we could follow a similar approach that the one we used for TAP. Obviously, the complexity of execution of a query is high and make use of complex database technology but we are not facing this complexity but just creating an abstract layer on top that could be mapped.<BR>
<BR>
Best Regards,<BR>
Jesús Salgado <BR>
SKA Regional Centre Architect <BR>
<a href="mailto:jesus.salgado@skao.int">jesus.salgado@skao.int</a> <mailto:jesus.salgado@skao.int><BR>
<a href="http://www.skao.int" target="_blank">www.skao.int</a> <<a href="https://www.skao.int/" target="_blank">https://www.skao.int/</a>><BR>
SKA Observatory<BR>
Jodrell Bank, Lower Withington,<BR>
Macclesfield, SK11 9FT, UK <BR>
<BR>
<BR>
<BR>
<BR>
On 23/10/2023, 08:25, "grid on behalf of Markus Demleitner" <grid-bounces@ivoa.net <mailto:grid-bounces@ivoa.net> on behalf of <a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a> <mailto:msdemlei@ari.uni-heidelberg.de>> wrote:<BR>
<BR>
<BR>
Dear GWS,<BR>
<BR>
<BR>
On Thu, Oct 19, 2023 at 06:45:18AM +0100, Dave Morris wrote:<BR>
> Vicente was concerned that this may be too complex to implement in<BR>
> fast-moving digital scenario depicted by Cloud and Container players. It<BR>
> might be better to concentrate on what we already have and see if we can<BR>
> define some common patterns for accessing platforms based on a minimum<BR>
> compatibility at technology stack level (Kubernetes, S3 etc.). Based on this<BR>
> assessment we could measure the gap across organisations in order to<BR>
> implement PoCs for those that are close to each other.<BR>
><BR>
> I'm following up on this in a mailing list thread because I have also heard<BR>
> similar concerns and suggestions from other people too.<BR>
><BR>
> This thread is somewhere for us to discuss the pros and cons of the two<BR>
> directions, the abstract ExecutionPlanner interface, and the more pragmatic<BR>
> approach looking for common patterns in how we use the technologies.<BR>
<BR>
<BR>
Disclaimer: I'm not actually running any compute services and don't<BR>
intend to. I'm an outsider in this business, and I'd have kept my<BR>
mouth shut if others had chimed in. Since they haven't, and since I<BR>
think we need to discuss this, let me throw in some probably fairly<BR>
incompetent words.<BR>
<BR>
<BR>
As a general stance, I am very much in favour of giving users a<BR>
chance to avoid lock-ins, which (with network services) means<BR>
creating facilities to discover services -- e.g., Dave's<BR>
ExecutionPlanner -- and to have *somewhat* common interfaces to using<BR>
them -- e.g., Dave's ExecutionWorker.<BR>
<BR>
<BR>
I am hence very much in favour of attempting to adopt or develop<BR>
abstraction mechanisms where reasonable. What scares me a bit in<BR>
that context is that we try and develop our own standard for<BR>
compute service discovery and job submission when my impression is<BR>
everyone around us is doing that, too.<BR>
<BR>
<BR>
For instance, in the context of a national federation effort I've<BR>
been asked to participate in, there is<BR>
<a href="https://cobald-tardis.readthedocs.io/" target="_blank">https://cobald-tardis.readthedocs.io/</a>. Many <<a href="https://cobald-tardis.readthedocs.io/. Many" target="_blank">https://cobald-tardis.readthedocs.io/. Many</a>> other things are going<BR>
on that seem at least related, such as CERN's reana or -- this one<BR>
I'm planning to have a closer look at -- the common workflow language<BR>
CWL.<BR>
<BR>
<BR>
In comparison to many of these other efforts, the Execution Planner<BR>
in its iWD form seems simple and pragmatic to me. On the other hand,<BR>
these people solve lots of hard problems that we are probably<BR>
glossing over; I was fairly impressed by a talk about a complex<BR>
machinery that enables *a particular* submission service to feed<BR>
containers access tokens to *a particular* storage service so that<BR>
long-running jobs can keep writing when the storage access tokens<BR>
expire rapidly. The thought of having to write an interoperable<BR>
standard catering to this kind of thing makes we want to end this<BR>
mail.<BR>
<BR>
<BR>
-- Markus<BR>
<BR>
<BR>
(who's still dreaming that some advanced array manipulation scheme<BR>
like the one I talked about in Santiago --<BR>
<a href="http://wiki.ivoa.net/internal/IVOA/InterOpOct2017DAL/arraysql.pdf" target="_blank">http://wiki.ivoa.net/internal/IVOA/InterOpOct2017DAL/arraysql.pdf</a> <<a href="http://wiki.ivoa.net/internal/IVOA/InterOpOct2017DAL/arraysql.pdf" target="_blank">http://wiki.ivoa.net/internal/IVOA/InterOpOct2017DAL/arraysql.pdf</a>> --<BR>
accessible over plain old TAP would cover a substantial portion of<BR>
our code-to-data requirement beyond ADQL).<BR>
<br>
<br>
<font size="1.5px">
The SKA Observatory is an inter-governmental organisation and the successor of SKA Organisation, a private limited company by guarantee registered in England and Wales with registered number 07881918, with a registered office of Jodrell Bank, Lower Withington, Macclesfield, Cheshire, England, SK11 9FT.
<br><br>
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please inform the sender, and immediately and permanently delete the email. Do not use, copy or disclose the information contained in this message or in any attachment.
<br><br>
This email has been scanned for viruses and malware, and may have been automatically archived, by Mimecast Ltd. Although SKA Observatory and SKA Organisation have taken reasonable precautions to ensure no viruses are present in this email, neither SKA Observatory nor SKA Organisation accept responsibility for any loss or damage sustained as a result of computer viruses and the recipient must ensure that the email (and attachments) are virus free.
</font>
</body></html>