<font size=2 face="sans-serif"><br>
</font>
<br>
<br>
<br><tt><font size=2>Dan Smith <dms@danplanet.com> wrote on 10/10/2013
08:26:14 PM:<br>
<br>
> From: Dan Smith <dms@danplanet.com></font></tt>
<br><tt><font size=2>> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
</font></tt>
<br><tt><font size=2>> Date: 10/10/2013 08:31 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [nova][powervm]
my notes from the <br>
> meeting on powervm CI</font></tt>
<br><tt><font size=2>> <br>
> > 4. What is the max amount of time for us to report test results?
 Dan<br>
> > didn't seem to think 48 hours would fly. :)<br>
> <br>
> Honestly, I think that 12 hours during peak times is the upper limit
of<br>
> what could be considered useful. If it's longer than that, many patches<br>
> could go into the tree without a vote, which defeats the point.</font></tt>
<br>
<br><tt><font size=2>Yeah, I was just joking about the 48 hour thing, 12
hours seems excessive</font></tt>
<br><tt><font size=2>but I guess that has happened when things are super
backed up with gate</font></tt>
<br><tt><font size=2>issues and rechecks.</font></tt>
<br>
<br><tt><font size=2>Right now things take about 4 hours, with Tempest
being around 1.5 hours</font></tt>
<br><tt><font size=2>of that. The rest of the time is setup and install,
which includes heat</font></tt>
<br><tt><font size=2>and ceilometer. So I guess that raises another question,
if we're really</font></tt>
<br><tt><font size=2>setting this up right now because of nova, do we need
to have heat and</font></tt>
<br><tt><font size=2>ceilometer installed and configured in the initial
delivery of this if</font></tt>
<br><tt><font size=2>we're not going to run tempest tests against them
(we don't right now)?</font></tt>
<br>
<br><tt><font size=2>I think some aspect of the slow setup time is related
to DB2 and how</font></tt>
<br><tt><font size=2>the migrations perform with some of that, but the
overall time is not</font></tt>
<br><tt><font size=2>considerably different from when we were running this
with MySQL so</font></tt>
<br><tt><font size=2>I'm reluctant to blame it all on DB2.  I think
some of our topology</font></tt>
<br><tt><font size=2>could have something to do with it too since the IVM
hypervisor is running</font></tt>
<br><tt><font size=2>on a separate system and we are gated on how it's
performing at any</font></tt>
<br><tt><font size=2>given time.  I think that will be our biggest
challenge for the scale</font></tt>
<br><tt><font size=2>issues with community CI.</font></tt>
<br><tt><font size=2><br>
> <br>
> > 5. What are the minimum tests that need to run (excluding APIs
that the<br>
> > powervm driver doesn't currently support)?<br>
> >         - smoke/gate/negative/whitebox/scenario/cli?
 Right now we have<br>
> > 1152 tempest tests running, those are only within api/scenario/cli
and<br>
> > we don't run everything.<br>
> <br>
> I think that "a full run of tempest" should be required.
That said, if<br>
> there are things that the driver legitimately doesn't support, it
makes<br>
> sense to exclude those from the tempest run, otherwise it's not useful.<br>
> <br>
> I think you should publish the tempest config (or config script, or<br>
> patch, or whatever) that you're using so that we can see what it means<br>
> in terms of the coverage you're providing.</font></tt>
<br>
<br><tt><font size=2>Just to clarify, do you mean publish what we are using
now or publish</font></tt>
<br><tt><font size=2>once it's all working?  I can certainly attach
our nose.cfg and</font></tt>
<br><tt><font size=2>latest x-unit results xml file.</font></tt>
<br><tt><font size=2><br>
> <br>
> > 6. Network service? We're running with openvswitch 1.10 today
so we<br>
> > probably want to continue with that if possible.<br>
> <br>
> Hmm, so that means neutron? AFAIK, not much of tempest runs with<br>
> Nova/Neutron.<br>
> <br>
> I kinda think that since nova-network is our default right now (for<br>
> better or worse) that the run should include that mode, especially
if<br>
> using neutron excludes a large portion of the tests.<br>
> <br>
> I think you said you're actually running a bunch of tempest right
now,<br>
> which conflicts with my understanding of neutron workiness. Can you
clarify?</font></tt>
<br>
<br><tt><font size=2>Correct, we're running with neutron using the ovs
plugin. We basically have</font></tt>
<br><tt><font size=2>the same issues that the neutron gate jobs have, which
is related to concurrency</font></tt>
<br><tt><font size=2>issues and tenant isolation (we're doing the same
as devstack with neutron</font></tt>
<br><tt><font size=2>in that we don't run tempest with tenant isolation).
 We are running most</font></tt>
<br><tt><font size=2>of the nova and most of the neutron API tests though
(we don't have all</font></tt>
<br><tt><font size=2>of the neutron-dependent scenario tests working though,
probably more due</font></tt>
<br><tt><font size=2>to incompetence in setting up neutron than anything
else).</font></tt>
<br><tt><font size=2><br>
> <br>
> > 7. Cinder backend? We're running with the storwize driver but
we do we<br>
> > do about the remote v7000?<br>
> <br>
> Is there any reason not to just run with a local LVM setup like we
do in<br>
> the real gate? I mean, additional coverage for the v7000 driver is<br>
> great, but if it breaks and causes you to not have any coverage at
all,<br>
> that seems, like, bad to me :)</font></tt>
<br>
<br><tt><font size=2>Yeah, I think we'd just run with a local LVM setup,
that's what we do for</font></tt>
<br><tt><font size=2>x86_64 and s390x tempest runs. For whatever reason
we thought we'd do</font></tt>
<br><tt><font size=2>storwize for our ppc64 runs, probably just to have
a matrix of coverage.</font></tt>
<br><tt><font size=2><br>
> <br>
> > Again, just getting some thoughts out there to help us figure
out our<br>
> > goals for this, especially around 4 and 5.<br>
> <br>
> Yeah, thanks for starting this discussion!<br>
> <br>
> --Dan<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>