Project specification

From PKC
Jump to navigation Jump to search


TO BE DEPRECATED: When you see this, please consider moving the logic model below from Template:Logic Model to Template:LogicModel

1. Context

After defining the scope, the project should be specified so that it is precise enough for implementation.

2. Goal

To specify the system using a formal/semi-formal specification and Logic model.

3. Success Criteria
  1. The specification completely covers the system
  2. The specification can be compiled correctly
  3. The goal is reached before end time
4. Outputs 5. Process 6. Inputs

Project specification

Understand and specifying the workflows in PKC.

  1. The knowledge of resources.
  2. The knowledge of integrating resource in PKC
7. Boundary Conditions




All kinds of workflows

The workflows are managed in Manual namespaces.

CICD

Automation workflow

By Jenkins Remote Access API :

  • Jenkins:retrieve information from Jenkins for programmatic consumption
  • Jenkins:trigger a new build
  • Jenkins:create/copy jobs

Docker workflow

Resource:Docker Image Repository

  • Download the Docker Image and build the PKC instance by up.sh. Then a docker container instance is built.
  • For any updates, save the new image file in docker registry with a named TAG.
  • Push the registered local image on the docker hub.
  • The image should be tested and then deployed for use.

Backup and Restore Workflow

{{#lst:PKC Workflow|TLA Logic Model}}


Discussion

  • For each workflow, do we need to track whether users follow the workflow and succeeds in order to verify the event? --KevinTung (talk) 17:55, 18 July 2021 (UTC)
  • Should we discern the automated workflow with the manual one? Or are we supposed to specify all necessary parts of workflow? --KevinTung (talk) 17:55, 18 July 2021 (UTC)
  • Project needs to be accountable. --Benkoo (talk) 07:46, 30 July 2021 (UTC)

Formal Methods

  • TLA workflow