Re: Next Steps for Taskotron
Excerpts from Tim Flink's message of 2014-07-24 06:16 +10:00: > While disposable clients may sound simple, there are many parts to > this. > - deciding whether to use something like openstack vs. libvirt Something else to consider here: if you build disposable testing that requires using virtual machines, your testing is effectively limited to x86, at least for the near future. Apparently KVM for ARMv7 and ARMv8 is in the kernel now, and it can even be used with OpenStack [1], but I'm guessing that's not a well supported configuration. KVM for Power seems to be underway but not in the kernel yet. Disposable testing on physical machines (with the option to offload work to OpenStack instances when possible) is what Beaker is built for. [1] http://www.openstack.org/blog/2012/07/trystack-org-adds-new-arm-technology-powered-zone/ -- Dan Callaghan Software Engineer, Hosted & Shared Services Red Hat, Inc. signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Next Steps for Taskotron
On Thu, 24 Jul 2014 16:14:33 -0400 Matthew Miller 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 signature.asc Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Next Steps for Taskotron
On Thu, Jul 24, 2014 at 04:14:33PM -0400, Matthew Miller wrote: > 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 "is a thing openstack does". Or maybe "is a thing in openstack". Either way. /me goes to get some calories in his brain -- Matthew Miller Fedora Project Leader ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Next Steps for Taskotron
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 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? 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? -- Matthew Miller Fedora Project Leader ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
