On Tue, 11 Mar 2014 07:52:06 -0400 (EDT) Kamil Paral <kpa...@redhat.com> wrote:
> > > Well, are we sure now how exactly the client setup process will be > > > hooked into taskotron or its underlying tools? > > > > I'm not exactly sure how this will work, either. It's going to > > depend on what we end up using for graphical testing, what > > openstack is capable of, what cloud resources we have access to and > > what the cloud SIG ends up needing for their testing. > > > > > Are we committed to using buildbot, or might it change? > > > > I don't really see how this is relevant. Can you elaborate on how > > using buildbot or not would factor in here? > > Hmm. In AutoQA, we used Autotest for managing test clients. Any > disposable client support would most probably needed some support in > Autotest. I assumed it's the same for Buildbot. Instead of using a > pre-defined machine, it will need to be able to say "you there, > create me a machine matching these requirements; zzz; thank you". There are several ways that we could go about implementing disposable clients. Buildbot already has some support for ephemeral slaves using OpenStack but I've not spent any time with it yet so I can't speak to how well it would work for our needs. The only potential problem I see with openstack is that I'm not sure we can do graphical testing with openstack instances (ie, direct access to the VNC interface or through libvirt). We'd have to investigate that to be sure, though. > > > So, two different systems (i.e. two different databases) > > > displayed in a single web frontend, right? I guess it makes sense. > > > > Yeah, that's what I had in mind, anyways. > > > > Since student registration has started, I'd like to get our proposed > > ideas in the wiki soon. The question of whether any of these > > projects would be worth distracting folks from other dev/testing > > work remains - any thoughts on that front? > > So far it seems you're the only candidate for mentoring, you it's > probably up to your decision and past experience. Of course any of us > will help the student when needed, but I assume most of the > communication will be between the mentor and the student. Josef says > that he recommend picking a project for which we don't need to spend > weeks to introduce and explain to the student the whole project, our > needs, etc. Something that is simple to explain, and can be > implemented without being blocked on us. Yeah, that's one of my concerns - the time that at least one of us would need to invest. I concur with Josef's suggestion of something that doesn't require too much background but I also think that having multiple mentors and involved folks is also important so it's not just 1 person interacting with a student. > > It sounds like the results middleware project, the graphical > > installation project, the gnome-continuous project and _maybe_ the > > disposable client project are the best candidates. Any thoughts on > > the value for those? > > I don't know much about gnome-continuous, but the rest of the > projects you mentioned really seems to be the best picks. Results > middleware is probably closest to Josef, graphical testing is closest > to me and disposable clients is closest to you. When it comes to > importance, disposable clients have probably the highest priority, > then results middleware, and then comes the rest. But that's just my > guesses. I think that gnome-continuous would be a good way to start getting some graphical testing done without needing disposable clients but I'm not clear on how much setup, integration and hw overhead there would be for the support infrastructure (rpm-ostree, at least AFAIK). I think that either disposable clients or the results middleware are going to be the highest priorities of the projects I listed. They're both things that have been (at least indirectly) asked for several times over the last couple years and I think that getting them implemented would help restore some confidence that we're going in the right direction. At this point, there are 3 or so days left in the application process and since we all seem to be on the fence on this a bit, I'm thinking it would be wise to skip GSoC for this year. I might put the ideas up on the wiki page tomorrow in case someone sees them and gets inspired for next year, though. Tim
signature.asc
Description: PGP signature
_______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
