Re: Proposal: No Cloud Disposable Clients
On 12/06/2014 11:32 AM, Tim Flink wrote: On Fri, 05 Dec 2014 15:34:38 +1000 Nick Coghlan ncogh...@redhat.com wrote: On 12/05/2014 10:00 AM, Tim Flink wrote: Any thoughts on whether this is worth pursuing as an alternative to openstack et. al? If there's anything that isn't clear, please ask for clarification. If you're going down this path, it's almost literally Beaker's image based provisioning for guest recipes: https://beaker-project.org/docs/user-guide/beaker-provided-tasks.html#distribution-virt-image-install :) You could either use restraint to run that directly, or else we could likely find a way to pull the core components of that task out into something independently reusable. Thanks for the pointer, I didn't know that had been added to Beaker. I'll take a look at it next week. Re-inventing the wheel is usually not my first choice :) It only landed a couple of weeks ago (as part of the Beaker 19 release), and it took even me a moment to remember the reason I couldn't find the RFE was because it had been released :) We also plan to have the RFE for making log files accessible via a HTTP proxy for non-public lab controllers [1] implemented for Beaker 20. Cheers, Nick. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1149944 -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane HSS Provisioning Architect ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Proposal: No Cloud Disposable Clients
On Fri, 05 Dec 2014 15:34:38 +1000 Nick Coghlan ncogh...@redhat.com wrote: On 12/05/2014 10:00 AM, Tim Flink wrote: Any thoughts on whether this is worth pursuing as an alternative to openstack et. al? If there's anything that isn't clear, please ask for clarification. If you're going down this path, it's almost literally Beaker's image based provisioning for guest recipes: https://beaker-project.org/docs/user-guide/beaker-provided-tasks.html#distribution-virt-image-install :) You could either use restraint to run that directly, or else we could likely find a way to pull the core components of that task out into something independently reusable. Thanks for the pointer, I didn't know that had been added to Beaker. I'll take a look at it next week. Re-inventing the wheel is usually not my first choice :) Tim pgpJAYFyq6ZaU.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Proposal: No Cloud Disposable Clients
On Thu, Dec 04, 2014 at 05:00:31PM -0700, Tim Flink wrote: What if we turned that on it's head a bit and put VM spawning into the task itself - spawn a vm local to the buildslave that is then responsible for the actual work in the task instead of doing all the work inside the buildslave process? This would allow for image and vm requirements to be described in the task without weird multiple parsings and could avoid most if not all of the problems/complexity that we've started seeing in getting buildbot to work with latent buildslaves. This seems both sane and useful to me, but we _will_ want to run at least some tests in the actual cloud environments. Should that stuff go _back_ to fedimg? (Also random other note: if you're using cloud-init to expand image root, ssh keys can be part of that too, right?) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Proposal: No Cloud Disposable Clients
On Thu, 4 Dec 2014 19:29:08 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Thu, Dec 04, 2014 at 05:00:31PM -0700, Tim Flink wrote: What if we turned that on it's head a bit and put VM spawning into the task itself - spawn a vm local to the buildslave that is then responsible for the actual work in the task instead of doing all the work inside the buildslave process? This would allow for image and vm requirements to be described in the task without weird multiple parsings and could avoid most if not all of the problems/complexity that we've started seeing in getting buildbot to work with latent buildslaves. This seems both sane and useful to me, but we _will_ want to run at least some tests in the actual cloud environments. Should that stuff go _back_ to fedimg? As I understand it, most of the stuff that the cloud folks want to test can be done on the cloud image in any virt environment. There are a couple of things I can think of that would require the full cloud system (does the image boot and have ssh connectivity in Open Stack, AWS etc.) but I think that stuff is somewhat orthogonal to how the client is booted. With either method, the task would have to connect to a cloud system using a set of credentials, create an instance with the specified image and connect to that image after it boots. Either way, we're still faced with the problem of securely distributing credentials and spawning instances in the task. It's probably worth asking the question of whether some tests should be in fedimg. If I'm right and the only credential-requiring tests are whether or not the image boots in service and we can ssh into it, it might make more sense to put that into fedimg and not deal with the credential issue in Taskotron. (Also random other note: if you're using cloud-init to expand image root, ssh keys can be part of that too, right?) I'm not sure if we'd be using cloud-init for all tasks but I think it would be involved in many client setups. AFAIK, cloud-init can handle ssh key insertion but we'd still have a potential security issue, depending on what keys we stuck in the image on boot. Tim pgpi65VD858NZ.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Proposal: No Cloud Disposable Clients
On Thu, Dec 04, 2014 at 06:56:08PM -0700, Tim Flink wrote: This seems both sane and useful to me, but we _will_ want to run at least some tests in the actual cloud environments. Should that stuff go _back_ to fedimg? As I understand it, most of the stuff that the cloud folks want to test can be done on the cloud image in any virt environment. Most, yes. But... There are a couple of things I can think of that would require the full cloud system (does the image boot and have ssh connectivity in Open Stack, AWS etc.) but I think that stuff is somewhat orthogonal to how the client is booted. Does it boot? is definitely key, but there's also other metadata-service related things to test. (Is the userdata read correctly? Is the hostname set? ...) And then there are some environment-specific tests we might want, too. (Can we retrieve the system logs via an API call?) But... It's probably worth asking the question of whether some tests should be in fedimg. If I'm right and the only credential-requiring tests are whether or not the image boots in service and we can ssh into it, it might make more sense to put that into fedimg and not deal with the credential issue in Taskotron. Maybe we start with just the basic test there and not worry about the above until we're _way_ further along on having any automated tests at all. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Proposal: No Cloud Disposable Clients
On 12/05/2014 10:00 AM, Tim Flink wrote: Any thoughts on whether this is worth pursuing as an alternative to openstack et. al? If there's anything that isn't clear, please ask for clarification. If you're going down this path, it's almost literally Beaker's image based provisioning for guest recipes: https://beaker-project.org/docs/user-guide/beaker-provided-tasks.html#distribution-virt-image-install :) You could either use restraint to run that directly, or else we could likely find a way to pull the core components of that task out into something independently reusable. Cheers, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane HSS Provisioning Architect ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Proposal: No Cloud Disposable Clients
On 12/05/2014 03:34 PM, Nick Coghlan wrote: On 12/05/2014 10:00 AM, Tim Flink wrote: Any thoughts on whether this is worth pursuing as an alternative to openstack et. al? If there's anything that isn't clear, please ask for clarification. If you're going down this path, it's almost literally Beaker's image based provisioning for guest recipes: https://beaker-project.org/docs/user-guide/beaker-provided-tasks.html#distribution-virt-image-install :) Oh, and in case I wasn't clear: +1 on the general idea behind this approach. We added the image-install task to Beaker 19 because it's a whole lot simpler than the OpenStack based dynamic provisioning feature (https://beaker-project.org/docs/admin-guide/openstack.html) Cheers, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane HSS Provisioning Architect ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
