Minutes from generated-jobs-in-UIs discussion

Zygmunt Krynicki zygmunt.krynicki at canonical.com
Thu Jul 2 15:45:24 UTC 2015

NOTE: cross-posting to checkbox-devel for posterity and googlability.

Thanks for sending this Maciek.

For some background, I think the root issue is that plainbox doesn't
model enough to let applications have useful UI in face of dynamic job
generation. We've discussed some ideas on how to address that that has
expanded into several other fields.

On Thu, Jul 2, 2015 at 5:17 PM, Maciej Kisielewski
<maciej.kisielewski at canonical.com> wrote:
> Greetings!
> We had a discussion about how to handle generated jobs in UIs (CBT in
> particular). Those are the takeaways I was able to catch:
> - We cannot predict when those jobs will be generated

They are always generated when we run a local job or when we run a
resource job with an associated template job. (the interesting case of
generating a template that already has a resource is not supported in
plainbox today). This is not really a problem, the problem is that we
cannot do anything sensible today to display a list of jobs for the
user to select.

> Let's introduce "bootstrapping-include" field to TP:
>   - run those jobs first
>   - validate that all 'generators' are included there (and are not in the
> ordinary "include")
>   - this will organize the UI (so we can show jobs after bootstrapping)

Yes, and we can be consistent in how this behaves across applications.
The field could be perhaps be named somewhat differently
(bootstrap-sequence?) so that it's more explicit that we're not using
patterns but simple job identifiers here (so that patterns cannot
future-match anything generated). Also having this list we could do
stronger constraints and validation on what is allowed in the
bootstrapping phase. Lastly we can expand analysis tools to let us see
what would really run _before_ we see the job selection screen (we can
be creative here and restrict jobs that run as root, or jobs that are
marked as unsafe, etc).

> - We need support for local jobs in CBT in order for it to become
> Checkbox-GUI replacement

Tee hee hee ;-) We cannot get away from legacy features without
addressing hard problems that keep them around.

> - There are $reasons why we do local jobs while having templates in the
> arsenal (GUI shows them?)

Bootstrapping issue prevents us form using them in checkbox-gui
(hardcoded sequence based on local jobs) and checkbox-cli. Apart from
that we don't (I think) have any other issues here.

> Instead of doing 'data' field for qml-jobs and use templates, let's do foo1
> and foo2 jobs that depend on resources: bar.has_foo1 and bar.has_foo2
> respectively

This is a stage 0 that we can implement in a few moments. As we
implement bootstrapping across the stack (core and checkbox-touch) we
can do stage 1 where we convert foo{1,2} to a nice template that does
use the data filed (which will be a json object that gets passed to
the job). In stage 2 we can also include a json-schema for the object
to let us validate it better but this would need some re-thinking of
template expansion to allow non-textual expansions (structural
templates) -- for some back story look up C preprocessor macros and
lisp macros, this is the same problem.

> Don't do hangouts when zyga just overdosed coffee :)

Just call me to ask first!

On top I'd like to add some other interesting bits we've discussed:

- templates are annoying if you are going to work with JSON (in fact,
all jobs are) due to quoting and extensive use of { } in both places.
- templates are expanded textually, not structurally so all kinds of
quoting issues are going to plague us (see above)
- we could implement a template-style field that lets us use jinja for
expansion while having some default that doesn't break the current
providers that use format-style expansion. This would let us keep
textual expansion but let us have better control over quoting and the
format in general.


More information about the Checkbox-devel mailing list