Request Entrypoint be an attribute supported in Core Workload Specs

[BBialeckiACR]

The request is to allow the concept of a workload having access to data somehow, whether this be opening a port for an API or network service, or an input or output directory.

Entrypoints describe how data is accepted and results are emitted.

An Example:

apiVersion: standard.oam.dev/v2
kind: Component
metadata:
    name: dimseserver
spec:
    type: DicomServerWorkload
    settings:
        livenessProbe:
            httpGet:
                port: 8080
                path: /live
        readinessProbe:
            httpGet:
                port: 8080
                path: /ready        
        logAccess:
            httpGet:
                port: 8080
                path: /log
                httpHeaders:
                    - name: systemToken
                      value: sampleheadertoken
        env:
        - name: inputHost
          value: samplehost.domain.com
        - name: ip
          value: 10.20.30.40
        entrypoints:
            - type: dimseIn
              properties:
                - name: inputAet
                  value: AET_INPUT
                - name: inputPort
                  value: 104
                - name: inputHost
                  value: samplehost.domain.com
 	       security:
                   - type: tls
                     properties:
                        - name: clientCertCn
                          value: client.hospital.org
                        - name: serverCertCn
                          value: server.app.com
                        - name: cipherSuite
                          value: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
            - type: dismeOut
              properties:
                - name: outputAet
                  toParam: outputAet
                  value: AET_OUTPUT
                - name: outputPort
                  toParam: outputPort
                  value: 104
                - name: outputHost
                  toParam: outputHost
                  value: 192.1.1.10
    parameters:
        - name: outputAet
          description: Output AET
          fieldPaths:
          - "spec.settings.entrypoints[1].properties[0].value"
          required: true
        - name: outputPort
          description: Output Port
          fieldPaths:
          - "spec.settings.entrypoints[1].properties[1].value"            
          required: true
        - name: outputHost
          description: Output Host
          fieldPaths:
          - "spec.settings.entrypoints[1].properties[2].value"
          required: true

[resouer]

@BBialeckiACR The existing data input/output design in oam runtime seems closely related to your request, could you please take a look at this doc: https://github.com/crossplane/oam-kubernetes-runtime/blob/master/design/resource-dependency.md? It's already implemented in this runtime repo (yet not part of the spec since it's still experimental).

Another request is could you please format a bit the yaml sample above? :-)

[BBialeckiACR]

I had dropped it in formatted but forgot to mark it. Anyway, I did look at the runtime but the issue I have there is specified in the App config I cannot have mutable and immutable items in a component and I cannot specify defaults and allow for parameterization.

[BBialeckiACR]

Our workloads would be something like:

DicomContainerizedWorkload

• osType
• arch
• containers
• entrypoints

DicomServerWorkload

• livelinessProbe
• readinessProbe
• logAccess
• env
• entrypoints

DicomTaskWorkload

• exec # The path or uri to the executable, has a type [ ] command which is a command to be executed. Each command will be # executed sequentially. Commands exiting 0 are considered successful
• logAccess
• env
• entrypoints

Entrypoints are defined by

• type # types are defined in the spec and each have required properties i.e. Must be dimseIn, dimseOut, wadoRsIn, stowRsIn, # stowRsOut, operatorIn, operatorOut or dicomRestApi
• properties
• security

Entrypoint Properties

• name # Each entrypoint has a set of required properties that needs to be specified whether mutable or not
• toParameter # To make an entrypoint property value mutable, the parameter name used for this purpose
• value # The default or coded system value

Entrypoint Security -type # Must be tls, userIdentity, digitalSignature, mediaStorageSecurity, apiKey, basicAuth, formAuth, cleintCertAuth, oAuth, #token -properties

Entrypoint Security Properties

• name # Each entrypoint has a set of required security properties that needs to be specified whether mutable or not
• toParameter # To make an entrypoint security property value mutable, the parameter name used for this purpose
• value # The default or coded system value

Example Info: For dimseIn the following properties are required: • inputAet • inputPort • inputHost For dimseOut the following properties are required: • outputAet • outputPort • outputHost For wadoRsIn the following properties are required: • resourceUri • acceptHeaders For stowRsIn the following properties are required: • resourceUri • contentTypeHeaders For stowRsOut the following properties are required: • resourceUri • contentTypeHeaders For operatorIn • directory • operations • supportedDataTypes For operatorOut the following properties are required: • directory • operations • supportedDataTypes For dicomRestApi the following properties are required: • type – ACR Model API, DICOM WSDL (extensible) • version • requestUri • port

[resouer]

@BBialeckiACR Per today's discussion, this is a valid use case and we should think how to support it. Would you mind to list the change needed in OAM spec in your evision? This could help a lot.

[BBialeckiACR]

Here is a general idea of the thought. The entrypoint is defined as part of the workload type and has properties and security. Security for the entrypoint has properties as well. OAM request for Entrypoint.docx

[resouer]

@BBialeckiACR As we discussed on the community meeting, the next step is to formalize the idea into a design proposal to change the spec. One example is: https://github.com/oam-dev/spec/pull/304

As long as the proposal is merged, the spec change is good to go. That being said, it's also fine for you to introduce a custom workload type as well.

[rynowak]

I would love to see this be generalized/combined with some of the ideas we have around input/outputs/dependencies that are part of the runtime but not part of the spec.

In general it's really valuable if we could express connection points between components in a way that's typed - in your example that would be something like a directory but it could also be a protocol like HTTP or gRPC.

[BBialeckiACR]

I have resubmitted this as Spec #422. I think I need to possible demo how medical imaging transfers data because maybe that will help with the understanding.

Brian J Bialecki American College of Radiology

From: Ryan Nowak [email protected] Sent: Monday, January 11, 2021 1:40 PM To: crossplane/oam-kubernetes-runtime [email protected] Cc: Bialecki, Brian [email protected]; Mention [email protected] Subject: Re: [crossplane/oam-kubernetes-runtime] Request Entrypoint be an attribute supported in Core Workload Specs (#259)

I would love to see this be generalized/combined with some of the ideas we have around input/outputs/dependencies that are part of the runtime but not part of the spec.

In general it's really valuable if we could express connection points between components in a way that's typed - in your example that would be something like a directory but it could also be a protocol like HTTP or gRPC.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/crossplane/oam-kubernetes-runtime/issues/259#issuecomment-758144358, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB3SVXX5LYZGCC5ITL3OMP3SZNAXJANCNFSM4SYL5JTQ.

---

This email has been scanned by the Symantec Email Security.cloud service.

---

This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed. It may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law and/or may constitute attorney work product. If you are not the intended recipient, do not use, disseminate, distribute, or copy this communication. If you have received this communication in error, please notify us immediately by telephone and destroy this message if this is a facsimile or (ii) delete this message immediately if this is an electronic communication.

---

This email has been scanned by the Symantec Email Security.cloud service.

---