path: root/blog/2018/09/11/planning_meeting_iteration_29.mdwn

[[!meta title="Planning meeting (iteration 29)"]]
[[!tag meeting]]
[[!meta date="2018-09-11 10:14"]]
[[!meta author="liw"]]

People
=============================================================================

* [[people/liw]]
* [[people/dsilvers]]
* Ivan

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.

[[!table data="""
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.

[Mustache]: https://mustache.github.io/mustache.5.html

  _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.