Next Steps for Taskotron

[Tim Flink]

On Thu, 24 Jul 2014 16:14:33 -0400
Matthew Miller <mattdm at fedoraproject.org> wrote:

> On Wed, Jul 23, 2014 at 02:16:39PM -0600, Tim Flink wrote:
> > 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.
> 
> I don't think a separate openstack instance should be necessary...
> I'm not sure how ours is currently configured -- and I certainly
> haven't kept up with the state of the art in openstack networking --
> but having a separate vlan for a tenant is a thing openstack....

I'll make sure to talk to Kevin and Miroslav about the new openstack
instance at flock but the current instance cannot be used with
Taskotron due to how everything is networked.

The openstack instance is, by design, isolated from the rest of the
network and all traffic has to be public. The other taskotron machines
are not public and even if they were, buildbot isn't designed to have
master/slave communication on public networks.

The public master/slave traffic issue could be solved by putting the
masters in openstack with the clients but then you run into another
issue. The taskotron masters can't be in openstack due to a fun
networking issue with openstack where the IP address used for the
master changes depending on which node the instance is on and AFAIK,
that can't be controlled when the instance is requested.

> But, also while, clearly, keeping systems secure is important, I
> don't want to overthink this. For example, even without greater
> isolation, we could let users who already have access to launch their
> own instances create and submit tests, can't we? Or am I missing
> something?

Yeah, we've had this conversation before and I completely forgot about
it. I just have it in my head that the qa clients need to be locked
down tight before we start accepting tasks from outside the Taskotron
devs.

> Overall, supporting "run these tests on a cloud image" is definitely
> something I want to do. However, that doesn't mean that the cloud
> image has to be within taskotron -- the client itself could just have
> the command line tools and credentials for accessing the cloud,
> launching the image, connecting to it, and so on, right?

The checks that you guys want to run on cloud images are in a different
boat. The taskotron clients don't have to be disposable since they'd
just be poking at an openstack instance over ssh, which isn't a problem
to route through the gateways.

So, long story short - the biggest problem with using the fedora
openstack instance is due to technical limitations of the version of
openstack being used and how everything's wired up. They probably
aren't insurmountable but it'll definitely require more discussion with
infra before it can be considered as an option.

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/20140724/1a775cd3/attachment.sig>