Next Steps for Taskotron

Tim Flink tflink at redhat.com
Wed Jul 23 20:16:39 UTC 2014


Now that we're pretty much feature-complete for replacing AutoQA with
Taskotron, it's time to start talking about what to work on next.

The next big feature that I want to work on is support for disposable
clients in Taskotron. We've been talking about doing this for years in
AutoQA but for various reasons, it never happened. Disposable clients
will pave the way for things like:
  - user submitted tasks
  - destructive tasks (things which could leave the client in a broken
    state)
  - tasks that require extra packages to be installed

While disposable clients may sound simple, there are many parts to this.
 - deciding whether to use something like openstack vs. libvirt
   * The limiting issue here is likely to be that clients need to be
     isolated on the network which may preclude use of the existing
     Fedora infra cloud. I'm not sure that setting up our own openstack
     instance is wise or efficient.

 - Figuring out how to store logs in a persistent way since clients
   will be destroyed on a regular basis

 - If we have different client retention policies for various tasks
   (eg keep generic clients for rpmlint, depcheck etc. around for a
   while and destroy all other clients after a single use), enhance
   trigger to support those policies.

 - Support systems for image maintenance/distribution
   * base images should be reasonably up to date
   * make sure that images are distributed to all required places

 - Explore whether buildbot's ephemeral slave support will be enough
   for our uses or if that will need enhancements.

 - Test the snot out of the disposable clients feature
   * This feature will add a decent amount of complexity and we need to
     make sure most of the kinks are worked out


Outside of this "big feature", there are several smaller features and
support artifacts that I want to see done in the reasonably near future:

 - CI for taskotron
   * I also want to see continuous deployment on taskotron-dev but that
     may need to wait for later

 - (More) build automation
   * The current process that I'm using for builds is tedious, painful
     and convoluted
   * We need to start supporting longer-lived repos than what we get
     with copr

 - Submit Taskotron packages for inclusion in the Fedora repos
   * This will make it easier for folks to install libtaskotron and for
     infra to update the Taskotron systems

If you have arguments for why something outside of what I've described
above should be a higher priority, feel free to make an argument for
that feature but please make it quick. I'm planning to start filing
tickets later today.

Also, this is for the more immediate future. As the F21 test cycle is
starting up, we have fewer human resources available to work on
Taskotron and the stuff I've listed above is likely to consume a decent
chunk of time.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20140723/9873f44d/attachment.sig>


More information about the qa-devel mailing list