-
Notifications
You must be signed in to change notification settings - Fork 3
/
IVOA-EP-note.tex
910 lines (738 loc) · 43.5 KB
/
IVOA-EP-note.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
\documentclass[11pt,a4paper]{ivoa}
\input tthdefs
\usepackage{courier}
\usepackage{appendix}
% Macros for referring to IVOA standards and notes.
\input{ivoa-cite.tex}
\usepackage{xspace}
% Standard terms used throughout the document,
% defined as macro commands to maintain consistency
\newcommand{\xml} {XML\xspace}
\newcommand{\json} {JSON\xspace}
\newcommand{\yaml} {YAML\xspace}
\newcommand{\webservice} {webservice\xspace}
\newcommand{\uws} {UWS\xspace}
\newcommand{\uwsce} {UWS-CE\xspace}
\newcommand{\ivoa} {IVOA\xspace}
\newcommand{\ivoep} {IVOA-EP\xspace}
\newcommand{\docker} {Docker\xspace}
\newcommand{\dockercompose} {Docker Compose\xspace}
\newcommand{\portainer} {Portainer\xspace}
\newcommand{\binderhub} {BinderHub\xspace}
\newcommand{\jupyter} {Jupyter\xspace}
\newcommand{\jupyterhub} {JupyterHub\xspace}
\newcommand{\esap} {ESAP\xspace}
\newcommand{\escape} {ESCAPE\xspace}
\newcommand{\datalake} {DataLake\xspace}
\newcommand{\rucio} {Rucio\xspace}
\newcommand{\apache} {Apache\xspace}
\newcommand{\spark} {Spark\xspace}
\newcommand{\python} {Python\xspace}
\newcommand{\pyspark} {PySpark\xspace}
\newcommand{\markdown} {Markdown\xspace}
\newcommand{\zeppelin} {Zeppelin\xspace}
\newcommand{\codeword}[1] {\texttt{#1}}
\newcommand{\footurl}[1] {\footnote{\url{#1}}}
\newcommand{\dataset} {dataset\xspace}
\usepackage{listings}
\usepackage{xcolor}
\colorlet{punct}{red!60!black}
\definecolor{html-gray}{HTML}{EEEEEE}
\definecolor{light-gray}{gray}{0.95}
\definecolor{delim}{RGB}{20,105,176}
\colorlet{numb}{magenta!60!black}
\lstset{
basicstyle=\small\ttfamily,
columns=fullflexible,
frame=none,
backgroundcolor=\color{light-gray},
stepnumber=1,
%numbers=left,
numbers=none,
numberstyle=\small,
numbersep=8pt,
%xleftmargin=\parindent,
xrightmargin=1cm,
showstringspaces=false,
keepspaces=true,
breaklines=true,
linewidth=14cm,
frame=none
}
% https://tex.stackexchange.com/questions/83085/how-to-improve-listings-display-of-json-files
% https://tex.stackexchange.com/a/83100
% https://tex.stackexchange.com/questions/10828/indent-a-code-listing-in-latex
% https://tex.stackexchange.com/a/10831
\lstdefinelanguage{json}{
literate=
*{0}{{{\color{numb}0}}}{1}
{1}{{{\color{numb}1}}}{1}
{2}{{{\color{numb}2}}}{1}
{3}{{{\color{numb}3}}}{1}
{4}{{{\color{numb}4}}}{1}
{5}{{{\color{numb}5}}}{1}
{6}{{{\color{numb}6}}}{1}
{7}{{{\color{numb}7}}}{1}
{8}{{{\color{numb}8}}}{1}
}
\lstdefinelanguage{yaml}{
literate=
*{0}{{{\color{numb}0}}}{1}
{1}{{{\color{numb}1}}}{1}
{2}{{{\color{numb}2}}}{1}
{3}{{{\color{numb}3}}}{1}
{4}{{{\color{numb}4}}}{1}
{5}{{{\color{numb}5}}}{1}
{6}{{{\color{numb}6}}}{1}
{7}{{{\color{numb}7}}}{1}
{8}{{{\color{numb}8}}}{1}
}
\hyphenation{Con-tai-ner-Node}
\title{IVOA Execution Planner - exploratory note}
\ivoagroup{Grid and Web Services Working Group}
\author[https://wiki.ivoa.net/twiki/bin/view/IVOA/DaveMorris]{Dave Morris}
\author[https://wiki.ivoa.net/twiki/bin/view/IVOA/SaraBertocco]{Sara Bertocco}
\editor[https://wiki.ivoa.net/twiki/bin/view/IVOA/DaveMorris]{Dave Morris}
\editor[https://wiki.ivoa.net/twiki/bin/view/IVOA/SaraBertocco]{Sara Bertocco}
%\previousversion[http://www.ivoa.net/documents/VOEP/????]{????}
\begin{document}
\begin{abstract}
The \ivoa Execution Planner (\ivoep) interface is a HTTP \webservice interface that provides a simple way to discover and access computing services. This document uses a series of use cases and example applications to illustrate the functionality provided by the \ivoep interface.
\end{abstract}
\section*{Acknowledgments}
\label{sec:acknowledgments}
This document derives from discussions among the Grid and Web Services working group of the IVOA.
This document has been developed with support from the UK Science and Technology Facilities Council (STFC), from the Italian National Institute for Astrophysics (INAF) and from the European Commission's Research and Innovation Program Horizon 2020 under the project ESCAPE (Grant n.824064).
\section*{Conformance-related definitions}
\label{sec:conformance-related-definitions}
The words ``MUST'', ``SHALL'', ``SHOULD'', ``MAY'', ``RECOMMENDED'', and ``OPTIONAL'' (in upper or lower case) used in this document are to be interpreted as described in IETF standard, \citep{std:RFC2119}.
The \emph{Virtual Observatory (VO)} is general term for a collection of federated resources that can be used
to conduct astronomical research, education, and outreach.
The \href{http://www.ivoa.net}{International
Virtual Observatory Alliance (IVOA)} is a global
collaboration of separately funded projects to develop standards and infrastructure that enable VO applications.
\section{Introduction}
\label{sec:introduction}
The Execution Planner (\ivoep) interface aims to provide a simple way to discover and access computing services.
The design of the \ivoep interface is based around two key classes of objects, computing Tasks and Services.
The primary question the \ivoep interface is designed to answer is \textit{"where can I run this Task ?"}, or more specifically, \textit{"which computing Services can I use to run this Task?"}
The simplest solution to this problem would be for a central agency to maintain enough metadata about all the available computing Services to be able to answer that question using a simple database query.
The simplest case is just to match the type of task with the type of Service, using a simple string match.
\begin{verbatim}
SELECT * FROM services WHERE servicetype = 'jupyter'
\end{verbatim}
This works for a small fixed set of Task types with a simple set of acceptance criteria. However as the range and complexity of Task types begins to grow a centralised solution like this becomes harder to maintain.
Different types of Tasks will have different metadata to describe them and different Service instances will have different criteria for accepting or rejecting Tasks. Each time a new type of Task or Service becomes available, the software for evaluating execution requests will need to be updated.
As the system evolves, we can see the criteria or rules for accepting a Task growing in complexity over time. If we imagine a system capable of deploying and executing a complex chain of interconnected software components, the criteria for accepting or rejecting a complex Task like this will also grow in complexity.
The design of the \ivoep interface aims to address this complexity by using the Separation of Concerns\footurl{https://en.wikipedia.org/wiki/Separation_of_concerns} pattern to delegate as much as possible to the Service instances
The \ivoep interface defines a simple stateless HTTP interface that supports \codeword{GET} and \codeword{POST} requests.
The following sections use a series of example Task types to illustrate how the \ivoep service interface works.
In all of these cases, the \ivoep service interface provides a common method to query Services about their capabilities.
For simplicity, this document will represent \ivoep query request and response messages using a simplified same \json notation.
Hopefully this makes it easier for the reader to compare the information in the request and response messages.
\SectionRef{sec:data-formats} describes more detail about how \ivoep requests and responses should be serialised in HTTP requests.
\section{Type identifiers}
\label{sec:type-identifiers}
The \ivoep service specification does not define a fixed list of Task and Service types.
The intention is that the Task and Service types will be developed organically by communities based on their science use cases.
\\
In order to support this grass-root model, the \ivoep specification recomends using resolvable Uniform Resource Identifier (URI)\footurl{https://en.wikipedia.org/wiki/Uniform_Resource_Identifier} identifiers to refer to Task and Service types.
\\
The choice of schema and format for the type URIs is left to the individual communities, the only requirement is that they be globally unique.
For readability this document will use a simplified URI scheme to represent the Task and Service type identifiers.
\begin{lstlisting}[]
tasktype = uri://jupyter-notebook
\end{lstlisting}
For a real-world deployment, the easiest way of ensuring global uniqueness is to use a HTTP URL that points to a location controlled by the community.
\begin{lstlisting}[]
tasktype = http://purl.escape.eu/types/jupyter-notebook
\end{lstlisting}
Alternatively one of the established resolvable URI registration schemes may be used, such as the DOI scheme or IVOA registry.
\begin{lstlisting}[]
tasktype = doi://########/jupyter-notebook
\end{lstlisting}
\begin{lstlisting}[]
tasktype = ivo://########/jupyter-notebook
\end{lstlisting}
There is no absolute requirement for the URI identifiers to be resolvable into a resource.
However providing a resolvable resource at the URI location is an ideal way to communicate information about the Task and Service types to others outside the local community.
\section{Notebook services}
\label{sec:notebook-services}
The following sections describe different types of notebook Task, including a generic \jupyterhub Service, a \binderhub Service and an \escape \esap notebook Service, and finally a \zeppelin notebook Service that supports multiple languages including \pyspark.
\subsection{Jupyter notebook}
\label{sec:uri://jupyter-notebook}
Replicating the simplest use case outlined above, where the name of the Task type matches the type that the Service implements, the client can call the \ivoep interface with a single parameter, \codeword{tasktype}, representing the type of Task the client is asking about.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://jupyter-notebook
\end{lstlisting}
If the service is not able to accept \codeword{uri://jupyter-notebook} Tasks, then it can simply reply with \json response containing a \codeword{reponseword} of \codeword{NO}.
\begin{lstlisting}[language=json]
{
"reponseword": "NO"
}
\end{lstlisting}
If the service can accept \codeword{uri://jupyter-notebook} Tasks then it should reply with a simple \json response containing a \codeword{reponseword} of \codeword{YES} along with details of how to execute the Task.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://jupyter-hub",
"serviceinfo": {
"endpoint": "http://jupyter.example.org/"
}
}
\end{lstlisting}
The \codeword{servicetype} value tells the client what kind of service is available, and the \codeword{serviceinfo} element provides details of how to connect to it.
In this example, \codeword{tasktype=uri://jupyter-notebook} in the request applies to a generic \jupyter notebook, as defined by the \jupyter\footurl{https://jupyter.org/} project. In the response, \codeword{servicetype=uri://jupyter-hub} refers to a \jupyterhub service, as defined by the \jupyter project.
In order to run a notebook in a \jupyterhub Service, a client would need to know the endpoint URL of the Service, which is provided in the \codeword{serviceinfo.endpoint} element of the response. The client can use this endpoint URL to pass the notebook to the \jupyterhub service and launch the Task.
\subsection{Binder notebook}
\label{sec:uri://binder-notebook}
It is also possible to run a generic \jupyter notebook in a \binderhub service provided by the Binder\footurl{https://binderhub.readthedocs.io/} project.
In which case, given the same request to run a \codeword{uri://jupyter-notebook} Task.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://jupyter-notebook
\end{lstlisting}
A \binderhub service would also reply with a positive response.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://binder-hub",
"serviceinfo": {
"endpoint": "http://binder.example.org/"
}
}
\end{lstlisting}
The response from the \binderhub Service is similar to the response from the \jupyterhub Service, but the meaning is slightly different.
Setting the \codeword{servicetype} to \codeword{uri://binder-hub} tells the client what kind of Service to expect at the endpoint URL.
It is then up to the client to decide how to send the details of the notebook to the Service based on the service type.
A \binderhub service can also handle a more complex Task than just a generic \jupyter notebook.
If the notebook comes as part of a git repository that contains additional information about the dependencies or environment the Task requires, such as \codeword{requirements.txt} or \codeword{environment.yml}, then a \binderhub service can use this information to build a new \docker container based on the requirements and deploy it in the \binderhub service.
In order to check if a Service accepts this more complex type of Task, the client would set the \codeword{tasktype} request parameter to \codeword{uri://binder-notebook}.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://binder-notebook
\end{lstlisting}
A generic \jupyterhub service would not be able to accept a \codeword{uri://binder-notebook} Task, so it would reply with a \json response containing a \codeword{reponseword} of \codeword{NO}.
\begin{lstlisting}[language=json]
{
"reponseword": "NO"
}
\end{lstlisting}
A \binderhub service that can accept a \codeword{uri://binder-notebook} Task would reply with a positive response, with the \codeword{servicetype} set to \codeword{uri://binder-hub} and the \codeword{serviceinfo.endpoint} pointing to \binderhub service endpoint.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://binder-hub",
"serviceinfo": {
"endpoint": "http://binder.example.org/"
}
}
\end{lstlisting}
Given the \codeword{servicetype} and \codeword{serviceinfo.endpoint} elements in the response, the client now has enough information to pass launch the Task by passing a reference to git repository to the \binderhub service.
\subsection{ESAP notebook}
\label{sec:uri://esap-notebook}
In terms of the \escape project, there may be additional components beyond simply adding the required software dependencies. If a notebook requires access to data in the \escape \datalake, then for the \textit{"DataLake as a Service"} to work correctly, the notebook needs to be run on a compute platform that is co-located with a Rucio Storage Element (RSE)
\footurl{https://rucio.readthedocs.io/en/latest/overview_Rucio_Storage_Element.html} that is part of the \escape \datalake, and the mechanism used to launch the Task needs to pass the appropriate authentication tokens into the notebook environment to enable it to access the \datalake.
If we define a new Task type, \codeword{uri://esap-notebook}, which refers to a notebook Task defined by the \escape ESAP project. Then an \ivoep service client can use this to check if a Service supports this environment.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://esap-notebook
\end{lstlisting}
In this case, the generic \jupyterhub and \binderhub Services would not understand the new Task type, and so would reply with a negative response.
\begin{lstlisting}[language=json]
{
"reponseword": "NO"
}
\end{lstlisting}
A Service deployment that does understand this new Task type, and can provide access to data in the \escape \datalake, would reply with a positive response.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://binder-hub",
"serviceinfo": {
"endpoint": "http://binder.example.eu/"
}
}
\end{lstlisting}
Note that the Service type in the response is still \codeword{uri://binder-hub}. This means that the \webservice interface that the client interacts with is the same as the generic \binderhub.
The difference with this Service instance is that it is deployed within the \escape network and is capable of providing access to the \escape \datalake.
Which means that in addition to being able to run generic \codeword{uri://jupyter-notebook} and \codeword{uri://binder-notebook} Tasks, this Service is also capable of understanding and executing a \codeword{uri://esap-notebook} Tasks.
\subsection{Zeppelin notebook}
\label{sec:uri://zeppelin-notebook}
\apache \zeppelin \footurl{https://zeppelin.apache.org/} is a browser based notebook platform that provides a similar user experience and functionality to the \jupyter notebook platforms.
However, the technical details of the notebook format and \webservice API are different, which means that the notebook Tasks are not equivalent.
The \ivoep API provides a common interface to enable a client to ask questions about this different type of notebook Service by setting the \codeword{tasktype} parameter to \codeword{uri://zeppelin-notebook}.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://zeppelin-notebook
\end{lstlisting}
\ivoep services that represent \jupyterhub and \binderhub Services would not understand the \codeword{tasktype} and would simply reply with a negative response.
\begin{lstlisting}[language=json]
{
"reponseword": "NO"
}
\end{lstlisting}
An \ivoep services that represented a \zeppelin Service would reply with a positive response, and include details of how to connect to the service.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://zeppelin-service",
"serviceinfo": {
"endpoint": "http://zeppelin.aglais.uk/"
}
}
\end{lstlisting}
Given the \codeword{servicetype} and \codeword{serviceinfo.endpoint} elements in the response, the client now has enough information to launch the \zeppelin notebook Task.
\subsection{PySpark notebook}
\label{sec:pyspark-notebook}
The \zeppelin platform includes interpreters for several different programming languages, and can support multiple languages within a single notebook.
An example of this is the \pyspark \footurl{http://spark.apache.org/docs/latest/api/python/} \python API that enables users to write \python code that performs data analysis using a \spark cluster.
If a \zeppelin platform has access to a \spark cluster, then it will be able to handle notebooks that contain both standard \python and \pyspark elements in the same notebook.
If we follow the same pattern as we did for the \jupyter notebooks, then we could define another Task type, \codeword{zeppelin-pyspark-notebook}, to describe \zeppelin notebooks that include \pyspark code in them.
However, as a \zeppelin notebook can include more than one language within a single notebook, the list of Task types would become overly complex if we tried to handle all the possible combinations.
A better solution would be to add a second parameter to the \codeword{accepts} request that contains a list of the required languages.
A \json representation of an \codeword{accepts} query for a \zeppelin notebook Task that includes \markdown\footurl{https://daringfireball.net/projects/markdown/}, \python and \pyspark elements would be as follows:
\begin{lstlisting}[language=json]
{
"tasktype": "uri://zeppelin-notebook",
"taskinfo": {
"languages": [
"md",
"python",
"pyspark"
]
}
}
\end{lstlisting}
The same query serialised as a HTTP GET request would be:
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://zeppelin-notebook
&taskinfo.languages={md,python,pyspark}
\end{lstlisting}
In this example, we have a \zeppelin notebook task that includes a list of three languages that are used in the notebook.
\begin{lstlisting}[language=json]
{
"tasktype": "uri://zeppelin-notebook",
"taskinfo": {
"languages": [
"md",
"python",
"pyspark"
]
}
}
\end{lstlisting}
An \ivoep service that represents a \zeppelin Service that can support all three languages would reply with a positive response.
In addition, the \codeword{servivceinfo} element for the \codeword{uri://zeppelin-service} could contain a list of the languages it supports.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://zeppelin-service",
"serviceinfo": {
"endpoint": "http://zeppelin.aglais.uk/",
"languages": [
"md",
"python",
"pyspark"
]
}
}
\end{lstlisting}
The \ivoep service specification defines the order in which the request elements are processed.
The first step is to check the \codeword{tasktype}. If the target Service does not understand the \codeword{tasktype}, then the \ivoep service should simply ignore the rest of the request and reply with a negative response.
An \ivoep service that represents a \jupyterhub or \binderhub Service would not recognise \codeword{uri://zeppelin-service} as a valid \codeword{tasktype}, and so would skip the \codeword{taskinfo} block and simply reply with \codeword{NO}.
\begin{lstlisting}[language=json]
{
"reponseword": "NO"
}
\end{lstlisting}
Defining the parsing sequence in this way means that the content of the \codeword{taskinfo} element can be specific to each Task type.
In this example, if the \ivoep service recognises and understands the \codeword{uri://zeppelin-service} \codeword{tasktype}, then it will know to expect a list of \codeword{languages} in the \codeword{taskinfo} element.
An \codeword{accepts} query for a different \codeword{tasktype} would have different, type specific, content in the \codeword{taskinfo} element.
\section{Container services}
\label{sec:container-services}
The following sections describe different types of container execution Services. Starting with the basic \docker container and \dockercompose Services described in the \ivoa \uwsce[cite] note, and an \ivoep service that represents a \portainer Service deployment.
\subsection{Docker UWS}
\label{sec:uri://docker-uws}
The \uwsce[cite] note describes a basic \docker container execution Service that uses the \ivoa \uws \webservice interface to manage container execution Tasks.
The simplest \ivoep implementation for a basic \uwsce service could just check the \codeword{tasktype} parameter to answer the question \textit{"Can I run a Docker container here?"}.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://docker-container
\end{lstlisting}
\ivoep services that represent Services that can execute \docker containers would reply with \codeword{YES}, and \ivoep services that do not support \docker containers would reply with \codeword{NO}.
However, a particular \uwsce instance may want to apply some checks on the content of the \docker container before allowing it to be executed on their platform.
For example a \uwsce Service may only accept containers from a white list of allowed images, or it may want to examine the container image to check that it is derived from a specific base image.
In this situation, the question changes from \textit{"Can I run \textbf{a} Docker container here?"} to \textit{"Can I run \textbf{this} Docker container here?"}, and in order to answer this question the \ivoep service needs to see the container image to check that it meets the acceptance criteria.
Following the pattern outlined in the previous section, the \ivoep request to ask this question would start with the \codeword{tasktype} parameter set to \codeword{uri://docker-container}, followed by the Task specific content in the \codeword{taskinfo} element, containing the fully qualified name of the container image, for example \codeword{docker.io/example:1.0}.
\begin{lstlisting}[language=json]
{
"tasktype": "uri://docker-container",
"taskinfo": {
"image": "docker.io/example:1.0"
}
}
\end{lstlisting}
The \ivoep service can then compare the image name with an internal white-list of accepted images, or it could download and inspect the image to verify that it is derived from the correct base image.
Assuming the container image meets the acceptance criteria, the \ivoep service would reply with a positive response, with the \codeword{servicetype} set to \codeword{uri://docker-uws} to indicate the type of Service, and the \codeword{serviceinfo} would contain the endpoint URL to access the service.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://docker-uws",
"serviceinfo": {
"endpoint": "http://example.org/dkuws",
}
}
\end{lstlisting}
\subsection{Docker compose}
\label{sec:uri://docker-compose}
In addition to the basic \docker container execution Service, the \uwsce[cite] note describes a \dockercompose Service that handles \dockercompose Tasks as \uws jobs.
Again, the simplest \ivoep implementation could just check the \codeword{tasktype} parameter to answer the question \textit{"Can I run a uri://docker-compose Task here?"}.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://docker-compose
\end{lstlisting}
\ivoep services can execute \dockercompose Tasks would reply with \codeword{YES}, and \ivoep services that don't would reply with \codeword{NO}.
However, a more realistic scenario would be for the \uwsce Service to apply some checks on the content of the \dockercompose Task before allowing it to be executed on the platform.
One way to enable this would be for the client to send a URL that points to the location of the \dockercompose file.
\begin{lstlisting}[language=json]
{
"tasktype": "uri://docker-compose",
"taskinfo": {
"composefile": "https://edin.ac/3jqocuV.yml"
}
}
\end{lstlisting}
However, this requires a copy of \dockercompose file to be publicly accessible on the internet, which may not always be possibly. A better alternative would be to use a HTTP \codeword{multipart/form-data POST} \footurl{https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST} request to include the content of the \dockercompose file in the request body.
\textbf{TODO} develop a better example using a containerized version of the Vollt TAP service\footurl{https://github.com/gmantele/vollt}.
\begin{lstlisting}[]
POST /accept HTTP/1.1
Host: foo.example
Content-Type: multipart/form-data;boundary="boundary"
--boundary
Content-Disposition: form-data; name="tasktype"
uri://docker-compose
--boundary
Content-Disposition: form-data; name="taskinfo.composefile"; filename="compose.yml"
Content-Type: text/yaml
version: '3.9'
networks:
external:
internal:
services:
database:
image:
"example/postgres:9.2"
networks:
- internal
environment:
POSTGRES_DB: "${database}"
POSTGRES_USER: "${usernam}"
POSTGRES_PASSWORD: "${password}"
webapp:
image:
"example/webapp:1.1"
networks:
- internal
- external
ports:
- "8080:8080"
--boundary--
\end{lstlisting}
This example sets the \codeword{tasktype} to \codeword{uri://docker-compose} in the first block of \codeword{form data}, and then includes the content of the \dockercompose file in the second block.
Note that the only part required by the \ivoep specification is the initial \codeword{tasktype} element set to \codeword{uri://docker-compose}.
After that, the rest of the content of the message is defined by the specification for the \uwsce application and the \ivoep extension for handling \dockercompose Tasks.
\subsection{Portainer service}
\label{sec:portainer-service}
\portainer\footurl{https://www.portainer.io/} is a commercial platform that \textit{"enables centralized configuration, management and security of Kubernetes and Docker environments, allowing you to deliver ‘Containers-as-a-Service’ to your users quickly, easily and securely."}
The \ivoep design pattern supports a number different of ways to integrate a \portainer service into the IVOA ecosystem.
\begin{itemize}
\item A \uwsce interface in front of a \portainer service accepting \docker container Tasks.
\item A \uwsce interface in front of a \portainer service accepting \dockercompose Tasks.
\item Exposing the \portainer service directly via an \ivoep interface
\end{itemize}
In the first two cases, the \uwsce interface acts as a proxy for the \portainer service. Initialising and running the \docker or \dockercompose Tasks on the \portainer service, and providing an IVOA compatible interface that represents the \portainer tasks as \uws jobs.
In the third case, the \ivoep service would provide a registered entrypoint to represent the \portainer service in the IVOA ecosystem.
The \ivoep service would accept Tasks with \codeword{tasktype} of \codeword{uri://docker-container}, \codeword{uri://docker-compose} and two new types of \codeword{uri://portainer-container} and \codeword{uri://portainer-compose}.
The \ivoep service would simply match the \codeword{tasktype} names and return a positive response, with \codeword{servicetype} set to \codeword{uri://portainer-service}
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://portainer-service",
"serviceinfo": {
"endpoint": "http://portainer.example.org/",
}
}
\end{lstlisting}
If a client does not understand how to drive a \portainer service, then it simply ignores this offer and moves on to try another service.
If a client does understand how to drive a \portainer service, then the \codeword{serviceinfo.endpoint} element of the response enables the \portainer client to contact the \portainer service directly.
This represents a key design pattern of the \ivoep service. Implementing just enough to provide a standard IVOA interface that can be registered in the IVOA Registry to make a 3rd party service find-able and use-able as part of the IVOA ecosystem, without having to standardise the whole of the 3rd party interface.
\subsection{Multiple interfaces}
\label{sec:multiple-interfaces}
A complex service like a full \portainer deployment may be capable of providing multiple methods for running the same Task type.
Given a basic request to execute a \docker container Task.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://docker-container
\end{lstlisting}
An \ivoep service that represents the \portainer service may return an array of service interfaces in the response, allowing the client to choose the most appropriate method to use.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"interfaces": [
{
"servicetype": "uri://portainer-service",
"serviceinfo": {
"endpoint": "http://portainer.example.org/"
},
{
"servicetype": "uri://compose-uws",
"serviceinfo": {
"endpoint": "http://uws.example.org/compose"
},
{
"servicetype": "uri://docker-uws",
"serviceinfo": {
"endpoint": "http://uws.example.org/docker"
}
]
}
\end{lstlisting}
In this example, the \ivoep service is offering three methods for executing a \codeword{uri://docker-container} Task.
\begin{itemize}
\item The full \portainer service interface.
\item A \uwsce interface that accepts can accept the \codeword{uri://docker-container} Task if it is wrapped as a \codeword{uri://docker-compose} Task.
\item A \uwsce interface that accepts \codeword{uri://docker-container} Tasks directly.
\end{itemize}
The client is free to choose which method is most appropriate to use.
\begin{itemize}
\item If the client understands how to use a \portainer service, then it can use the \codeword{serviceinfo.endpoint} to access the \portainer Service directly.
\item If the client understands how to wrap a \codeword{uri://docker-container} as a \codeword{uri://docker-compose} Task, then it may choose to use the \codeword{uri://compose-uws} Service.
\item Or the client may choose to simply use the basic \codeword{uri://docker-uws} Service.
\end{itemize}
\section{Resource requirements}
\label{sec:resource-requirements}
In order to evaluate whether a Service can execute a Task, an execution planner needs to know what level of resources the Task requires.
This is not covered by simply referring to the software to execute.
The level of resources required to execute a Task depends on several factors,
including what data sets are involved, and what the user wants to do with them.
An example of this comes from the Gaia data analysis platform\footurl{https://github.com/wfau/aglais} being developed at Edinburgh University.
The service provides a Zeppelin notebook platform together with a Spark cluster co-located with a copy of the Gaia DR2 and eDR3 datasets.
As part of the examples developed with the service, we have three types of analysis each requiring different levels of resources.
\begin{itemize}
\item A simple aggregate calculation of mean proper motions across the sky.
This uses 5 compute nodes, with a total of 70 cores and 225 Gbytes of memory
and takes less that 1 minute to complete.
\item A machine learning example that uses 5 nodes, 135 cores, 225 Gbytes of memory
and takes around 5 minutes to complete.
\item A complex analysis that uses 7 nodes, 217 cores, 360 Gbytes of memory
and takes over 9 hours to complete.
\end{itemize}
Although the complexity is related to the code in the notebooks themselves, this is not necessarily fixed.
It is possible to pass input parameters into the notebooks at runtime to select how much of which data set is used in the analysis.
This makes it possible to use a partial data set while working on a notebook interactivley during development,
and then initiate a longer run using the full data set once the analysis workflow has been finished.
There may also be cases where a science platform chooses to offer different levels of resources to different users,
depending on which groups they belong to.
A guest user may only be allowed to use a limited set of resources to run simpler analysis tasks on a smal \dataset.
A more experienced power user may be granted access to enough resources to run
the complex analysis on the full dataset.
The \ivoep interface provides a process for client and server to describe the
the level of resources required to run a task.
\subsection{Computing resources}
\label{sec:computing-resources}
In order to support this, a client may add a \codeword{resources} element to it's request to describe the minimum compute resources that are needed to execute the Task.
\begin{lstlisting}[language=json, mathescape=true]
{
"tasktype": "uri://zeppelin-notebook",
"taskinfo": {
....
}
"resources": {
$\textbf{mincores: 8}$
$\textbf{minmemory: 8G}$
}
}
\end{lstlisting}
If the resources are available, the \ivoep service should include a copy of the \codeword{resources} element in the response, updated to include the maximum resources that it is able to offer.
\begin{lstlisting}[language=json, mathescape=true]
{
"reponseword": "YES",
"servicetype": "uri://zeppelin-service",
"serviceinfo": {
....
}
"resources": {
mincores: 8
$\textbf{maxcores: 12}$
minmemory: 8G
$\textbf{maxmemory: 16G}$
}
}
\end{lstlisting}
This negotiation shows is that the client is requesting a minimum of 8 cores and 8G of memory,
and the \ivoep service is offering to extend that to 12 cores and 16G of memory.
If it receives simlar responses from other \ivoep services, the client can then decide which
service to use based on the resources they offer.
\subsection{Execution time}
\label{sec:execution-time}
This kind of negotiation can also be applied to execution time.
A client may use the \codeword{resources} element to set the maximum startup time it will accept and the minimum execution time it expects the Task will take.
\begin{lstlisting}[language=json, mathescape=true]
{
"tasktype": "uri://docker-container",
"taskinfo": {
....
}
"resources": {
$\textbf{maxstartup: 60s}$
$\textbf{minduration: 5m}$
}
}
\end{lstlisting}
This is saying the client wants the task to start within 60 seconds of sending the execution request, and it expects the task to take at least 5 minutes to execute.
If the timings are acceptable, the \ivoep service should include a copy of the \codeword{resources} element in the response, updated to include the timings that it is able to offer.
\begin{lstlisting}[language=json, mathescape=true]
{
"reponseword": "YES",
"servicetype": "uri://docker-uws",
"serviceinfo": {
....
}
"resources": {
$\textbf{minstartup: 5s}$
maxstartup: 60s
minduration: 5m
$\textbf{maxduration: 10m}$
}
}
\end{lstlisting}
This negotiation shows is that the client needs a minimum of 5 minutes to execute the task,
and the service is extending that to offer 10 minutes of time.
In addition, the client is specifying a maximum startup time of 60 seconds,
but the service is offering to be able to start the Task within 5 seconds
of receiving the execution request.
Again, given simlar responses from other \ivoep services, the client can use this information decide which service to use based on the time constraints they offer.
\subsection{Storage resources}
\label{sec:storage-resources}
TBD
Based on Kubernetes volume claims for ephemeral and persisten storage.
\section{Data access}
\label{sec:data-access}
Data access requirements ..
Data access vocabulary ..
\subsection{VOSpace}
\label{sec:data-access-vospace}
Example reference to data in VOSpace (INAF archive?).
Identity and auth ..
\subsection{Rucio}
\label{sec:data-access-rucio}
Example reference to data in Rucio (ESCAPE DataLake?).
Identity and auth ..
\subsection{Amazon S3}
\label{sec:data-access-amazons3}
Example reference to data in S3 (internal and external).
Examples, Amazon, DigitalOcean, Openstack, STFC Echo.
Identity and auth ..
\section{Authentication}
\label{sec:authentication}
Different Service instances may have different criteria for who they will allow to execute Tasks on their Service.
Some services, such as the public Service provided by the BinderHub Federation may be free and open to the public to use [1].
\\
An \ivoep service that represents a public access Service like this may accept any HTTP request, with or without authentication.
However, most computing services will be funded to provide compute resources for specific communities, and will require some level of user authentication to control access to their resources.
\\
If an authenticated identity is provided as part of the \codeword{/accepts}, then the EP service can use this identity as part of the evaluation criteria.
\begin{lstlisting}[]
HTTP GET /accepts?tasktype=uri://docker-container
Authorization: Bearer SlAV32hkKG
\end{lstlisting}
If the authenticated identity is allowed to perform the task on the target platform, the EP service replies with a positive
response as normal.
\begin{lstlisting}[language=json]
{
"reponseword": "YES",
"servicetype": "uri://portainer-service",
"serviceinfo": {
"endpoint": "http://portainer.example.org/",
}
}
\end{lstlisting}
If the authenticated identity is not allowed to perform the task on the target platform, the EP service may
reply with a simple negative response.
\begin{lstlisting}[language=json]
{
"reponseword": "NO"
}
\end{lstlisting}
Or it may provide additional information about the reason why.
\begin{lstlisting}[language=json]
{
"reponseword": "NO"
"reponseinfo": {
"reasons": [
{
"httpcode": 403,
"text": "Not authorised"
}
]
}
}
\end{lstlisting}
\section{Deployment and discovery}
\label{sec:deployment-discovery}
\subsection{Service deployment}
\label{sec:service-deployment}
The \ivoep interface is designed to work both within the context of the IVOA community, or as apart of a separate domain outside the IVOA, such as the ESCAPE ESAP community.
\\
In both situations, there would typically be one\ivoep service associated with each platform that provides computing resources to the community.
\\
In most cases the \ivoep service would normally be deployed as part of the computing platform itself.
The entity that provides the computing platform would also provide and maintain an \ivoep service that handles queries about running Tasks on that computing platform.
\\
However that is not a necessarily required.
For example, a project like ESCAPE may choose to deploy a stand-alone instance of an \ivoep service that handles queries about an external computing platform like the MyBinder service provided by the BinderHub Federation\footurl{https://mybinder.readthedocs.io/en/latest/about/federation.html}.
The \ivoep service itself would be hosted and maintained by a member of the ESCAPE community, but it can be configured to handle queries about running Tasks on the MyBinder service.
\\
This distributed micro-service architecture enables communities to build up a network of \ivoep services that describe both internal and external computing resources in an interoperable way.
\\
\subsection{Service discovery}
\label{sec:service-discovery}
The \ivoep interface is designed to be compatible with using the IVOA registry for service discovery.
The \ivoep specification defines a VOResource metadata extension for describing \ivoep services and their capabilities.
\\
\ivoep services deployed by members of the IVOA community will be registered in the IVOA registry, enabling service discovery using the existing IVOA registry tools.
\\
However, although registering services in the IVOA registry is encouraged, it is not required for the \ivoep services to function.
For example, a project like ESCAPE may choose to deploy their own service discovery mechanism, separate from the IVOA registry.
This can be as simple as a database table maintained inside the an ESAP portal that lists the \ivoep services associated with the computing platforms available to that community.
\section{Data formats}
\label{sec:data-formats}
Default data format for \ivoep services is to use
\yaml for data inputs sent via POST messages and the default response format is \json for outputs.
This pattern of using different formats for the request and response data is used by a number of \webservice interfaces, for example the Kubernetes \codeword{kubectl} control application.
The reasoning behind this pattern is that \yaml is the best format for storing human edited configurations, such as the resource requirements and metadata. Whereas \json is best format for handling and parsing \webservice responses.
\subsection{Request formats}
\label{sec:request-formats}
The \ivoep interface can accept both YAML and JSON documents in the elements of a HTTP multipart POST messages. The client should specify the format for each element in the HTTP POST message.
\begin{lstlisting}[]
POST /accept HTTP/1.1
Host: foo.example
Content-Type: multipart/form-data;boundary="boundary"
--boundary
Content-Disposition: form-data; name="tasktype"
example-task
--boundary
Content-Disposition: form-data; name="taskinfo.example.one"; filename="example-1.yml"
Content-Type: text/yaml
....
....
....
--boundary
Content-Disposition: form-data; name="taskinfo.example.two"; filename="example-2.json"
Content-Type: text/json
....
....
....
--boundary--
\end{lstlisting}
Where there is a preference for a particular format, e.g. to match the format used by a 3rd party application, it should be declared in documentation for that particular \ivoep application.
\subsection{Response formats}
\label{sec:response-formats}
The \ivoep interface can generate \json, \yaml or \xml response formats.
A client can specify the preferred format using the HTTP Accepts header.
\bibliography{ivoatex/ivoabib,ivoatex/docrepo}
\end{document}