People

Agenda

  • Discuss and decide goals for this iteration.

Notes

  • This iteration is about moving ick towards being hostable. The current roadmap for that is reproduced below, and is on the roadmap page as well.

  • There are currently to major aspects that need work: isolating users from each other, and having a friendly web user interface.

  • For isolation, we will make each “resource” in the ick API be owned by a user, and for that we will need to change API use to rely on access tokens that identify the user. This means moving form the OAuth2 client credential authentication to OpenID Connect, extended with “API tokens”.

  • For the web user interface, Ivan and Daniel have agreed to collaborate. Lars will stay out of it, since he’s not a front-end developer. The current plan is to use React, and to build the static JS files in a container, using npm, and deploying the generated files to a server.

Roadmap for hostable ick

@startroadmap
hosted_demo:
  label: |
    Lars run a hosted
    demo service for
    himself and users
  depends:
    - user_friendly
    - secure_from_users
    - secure_for_users
    - on_demand_workers
    - trigger_service
    - multiarch

user_friendly:
  label: |
    Ick is reasonably
    user friendly to
    techies.
  depends:
    - webui
    - self_registration

multiarch:
  label: |
    Ick supports building
    for multiple
    architecturs.
  depends:
    - worker_tags
    - concurrency

secure_from_users:
  label: |
    Ick is safe and
    secure from users
    doing silly things.
  depends:
    - networkless_containers

secure_for_users:
  label: |
    Ick is secure for
    users to use.
  depends:
    - isolation
    - secrets

secrets:
  label: |
    Ick provides a way to
    securely use secrets:
    ssh keys, pgp keys,
    Qvisqve access
    tokens.
  depends:
    - owned_resources

networkless_containers:
  label: |
    Containers have, by
    default, no network
    access. Trusted users
    can allow specific
    builds to have
    network access in
    containers.
  depends:
    - owned_resources

concurrency:
  label: |
    Ick can execute
    several actions in
    the same build
    concurrently.
  depends:
    - worker_tags

worker_tags:
  label: |
    Ick allows projects
    and workers to have
    tags, and can choose
    which worker to give
    an action to, based
    on tags

on_demand_workers:
  label: |
    Ick can create
    and destroy
    workers on demand
  depends:
    - worker_tags

trigger_service:
  label: |
    Ick can trigger
    multiple builds when
    a git repo changes,
    or when an ick build
    finishes, or after
    some time has psssed

isolation:
  label: |
    Users can only see,
    manipulate their own
    data
  depends:
    - owned_resources

owned_resources:
  label: |
    Each resource is
    owned by its creator

self_registration:
  label: |
    Users can create
    an account by themselves
    via a web browser
  depends:
    - webui

webui:
  label: |
    Ick has a web UI
    that allows creation,
    updating, triggering
    of projects, builds,
    viewing status, logs
@endroadmap

Roadmap for this iteration

@startroadmap
owned_resources:
  label: |
    Each resource is
    owned by its creator
  depends:
  - API_token_spec

API_token_spec:
  label: |
    Have a spec for how
    API tokens work.

webui:
  label: |
    Ick has a web UI
    that allows creation,
    updating, triggering
    of projects, builds,
    viewing status, logs
  depends:
    - ui_hello
    - ui_cd

ui_hello:
  label: |
    Write a React 'hello, world'
    application.

ui_server:
  label: |
    Set up server where
    the web UI is hosted.

ui_cd:
  label: |
    Set up ick job to build
    web UI and deploy it to
    a server.
  depends:
    - ui_server
@endroadmap

Tasks for this week

Tasks may be part of a project or be random small ones (max an hour) that just need doing.

what Who estimate(h)
Draft spec for API tokens in Qvisqve Lars 1
Draft spec for variable expansion in .ick files Lars 1
Set up a server to host ick web UI Lars 1
Prepare React App framework repository and populate with Hello World app Ivan 4
Verify independent ability to build and run webapp Daniel 2
Total Lars 3
Total Daniel 2
Total Ivan 4

Task descriptions

  • Draft spec for API tokens in Qvisqve: Draft a specification for how API tokens would work in Qvisqve, and how they would be used by icktool. Offer draft for review.

    Acceptance criteria: At least one person says +1 and nobody has serious objections.

  • Draft spec for variable expansion in .ick files: To let users reduce repetition in .ick files, and to shorten them, it would be nice to be able to use variables. Draft a specification for how that would work, with examples. Probably based on the Mustache specification.

Acceptance criteria: At least one person says +1 and nobody has serious objections.

  • Set up a server to host ick web UI: Set up a VM, domain name, and TLS certificate to serve the static files generated from the ick web UI. Later on, this will also host the ick UI facade application (which will be necessary to do logins securely). The demo ick workers, and Daniel, and Ivan, should have ssh logins and passwordless sudo access on the host.

    Acceptance criteria: Daniel and Ivan accept the server setup and confirm they can log in and become root with sudo.

  • Prepare React App framework repository and populate with Hello World app: The application should say “hello, world” (or some similar greeting), and use the React machinery to do so: npm to install dependencies, whatever the React build command is chosen to do the build.

    Acceptance criteria: Ivan says OK.

  • Verify independent ability to build and run webapp: Review the work by Ivan to make sure the application can be built and run by someone else than Ivan. This is a necessary step to automate build and deployment.

    Acceptance criteria: Daniel says OK.