✨ Support analysis providers.

[jortel]

Problem

Currently: Each addon defines a single container.
Currently: analysis is performed by running a task that specifies the tackle2-addon-analyzer addon. The name of the addon is hard-coded in the UI. This addon image incorporates support goland and Java providers.

The analyzer images are being refactored and the analyzer image will no longer bundle language providers. Instead, each provider will be packaged as a separate image. To support this, addons will need to be defined multiple containers. A main container for the addon and additional (sidecar) containers (one for each provider).

Future features may require runtime selection of an addon based on the kind-of task and the kind-of subject (application|platform|...) the task is executed on.
Examples:

• application technology discovery.
• platform discovery.
• platform analysis.

Questions/Assumptions:

• Do we need to support multi-language applications? Yes.
• Can the filtering of targets/rulesets and selection of providers be driven by language tags? Yes.

Solution

Support optional addon Extensions. Each extension is a (sidecar) container and most likely a service. For example: an RDBMS or LSP provider. All containers within a task pod are injected with the same items as the main addon contianer:

• Shared (EmptyDir) volume.
• Security token.
• Task (id).

Both addon and extension selection may be either:

• explicit - (specified on the task)
• determined by matched criteria.

Selection

As selector uses Label-Selector syntax and supports the following:

• tag:category=tag
• platform:(source|target)=kind

Examples:

Java
selector: tag:Language=Java

Java or XML
selector: tag:Language=Java || tag:Language=XML

No language tag.
selector: ! tag:Language=

Java and Linux
selector: tag:Language=Java && tag:OperatingSystem=Linux

Addon & Extension CRs

New Extension CR (Spec):

kind: Extension
spec:
  addon (string):
  container (core.v1.Container):
  selector (string):
  metadata (object):

Fields:

• extension - declares compatibility with addons.
• container - defines the extension container.
• selector - defines selector for inclusion in the addon task pod.
• metadata - defines unstructured information.

Changed Addon CR (Spec):

- image:
- imagePullPolicy:
- resources:

+ kind (string):
+ container  (core.v1.Container):
+ selector:
+ metadata (object):

Fields:

• kind - declares compatibility with a kind of task.
• container - defines the addon container.
• selector - defines addon selector for task (kind).
• metadata - defines unstructured information.
• schema - FUTURE defines the Task.Data schema.

For symmetry and completeness, the metadata field is added and the separate addon fields for the container are replaced with the entire k8s Container. This is mainly a general improvement while we're changing the CR.

Example:

---
kind: Addon
apiVersion: tackle.konveyor.io/v1alpha1
metadata:
  namespace: konveyor-tackle
  name: analyzer
spec:
  container:
    name: addon
    imagePullPolicy: Always
    image: quay.io/jortel/tackle2-addon-analyzer:provider

---
kind: Extension
apiVersion: tackle.konveyor.io/v1alpha1
metadata:
  namespace: konveyor-tackle
  name: java
spec:
  addon: analyzer
  selector: tag:Language=Java || !tag:Language
  container:
    name: java
    imagePullPolicy: Always
    image: quay.io/konveyor/java-external-provider
    args:
    - --port
    - $(PORT)
    env:
    - name: PORT
      value: ${seq:8000}
    resources:
      limits:
        cpu: 1
        memory: 3Gi
      requests:
        cpu: 1
        memory: 3Gi
  metadata:
    resources:
    - selector: identity:kind=maven
      fields:
      - name: settings
        path: /shared/creds/maven/settings.xml
        key: maven.settings.path
    provider:
      name: java
      address: localhost:$(PORT)
      initConfig:
      - providerSpecificConfig:
          mavenSettingsFile: $(maven.settings.path)

API

Task API resource changes:

+ Extensions []string `json: "extensions,omitempty"`.

Example:

addon: analyzer
extensions:
- java

Port Injection

The task manager will provide a set of injector (macros). Format: ${<macro}. Injector macros may be specified in the container.Spec:

• command
• args
• env

Automatic port assignment will be supported using a sequence (generator) macro.
Format: ${seq:pool}.
Example:

container:
  name: Test
  env:
  - name: PORT
    value: ${seq:8000}

Kinds of Tasks

A task (definition) defines a kind-of task which performs a specific action on a specific subject.

To prevent hard-coding tag names in the UI (anywhere), we may consider data-driven approaches.
Introducing named task (definitions) which represent a known kind-of task. Each (definition) defines the input schema and how an addon (that implements the task) may be selected. Addons (optionally) declare that they implement a kind-of task.

New Task CR:

• name
• dependencies:
• data (object)

Fields:

• name the kind-of task.
• dependencies list of task names used to define execution dependency.
• data - data object passed to the addon.
• schema - FUTURE defines the Task.Data schema.

kind=Task
name: discovery
addon:
 - name: discovery

kind=Task
name: analysis
dependencies:
- discovery

kind=Task
name: platform-analysis

kind=Task
name: platform-discovery

Add Task.Kind which can be applied by the exiting task endpoints. Either kind OR addon and extensions may be specified but not both.

+ Kind []string `json: "kind,omitempty"`.

Example:

kind: analyzer

Add a new read-only endpoints.

• /tasks/:id/attached - download (tgz) attached files.
• /k8s/addons - moved from /addons
• /k8s/addons/:name - moved from /addons/:name, includes extensions.
• /k8s/extensions - new extensions colleciton
• /k8s/extensions/:name - new extension by name

Task Priority

Tasks will be run in order of:

• priority
• id

Pods are created with the appropriate PriorityClass to ensure node scheduling matches. Task dependencies will be escalated as needed to prevent priority inversion. When (dep) tasks are already scheduled (Pending), the pod will be recreated referencing the updated priority class.

When the nodes are saturated and task pods are phase=Pending, the task manager may reschedule (delete) task with lower priority in an effort for higher priority pods to be run by the node scheduler. PriorityClass preemption should handle this.

Addon (adaptor)

Environment (variable) Injection

To injecting container environment variables into the Extension.metadata.
The format is exactly like k8s environment variable: $(variable).

Example:

container:
  name: Test
  env:
  - name: PORT
  - value: 8000
metadata:
  address: localhost:$(PORT)
    ...

---

Analyzer Addon (adaptor)

delegated to: konveyor/tackle2-addon-analyzer#83

Resource Injector

Aggregate the initConfig fragments from each Extension.metadata.

Inject information into the initConfig.

• credentials.

Considering: To support this, a set of injectors will be provided to get, store hub REST resource (fields). Fetched resources are assigned to variables that may be used in the metadata.
Resource:

• selector (format: <kind>:<key>=<value>)
• fields[]:
  • name: - name.
  • path: - (optional) value stored at the specified path.
  • key: - value stored in key referenced as $(key). Assigned to path, when specified.

Example:

metadata:
  resources:
  - kind: identity:kind=maven
    fields:
    - name: settings
      path: /shared/creds/maven/settings.xml
       key: settings.path
  - kind: identity=other
    fields:
    - name: user
       key: auth.user
    - name: password
       key: auth.password
  provider:
    initConfig:
     mavenSettingsPath: $(settings.path)
     user: $(auth.user)
     password: $(auth.password)

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.