[[!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.