3 p.m.
(Some of you may know me from my previous work at Red Hat - good to see some familiar
faces!)
I'm working on testing a Cinder driver for OpenStack - IceHouse, Havana, and Juno
(regretfully, in that order).
I've quickly found out Tempest is not really testing much for real (example: if I
don't configure iSCSI, I still pass all tests but 5 of them!), so I'm doing some
'manual' tests.
I've discovered few issues, not sure where to file them upstream
(Glance/Cinder/libvirt/etc.), I'll send them over the mailing list (or upstream, but I
was hoping for a low-volume mailing list).
1. Is there any test actually booting or running the VMs from the block storage? I have it
configured correctly (I think), but none of the relevant tempest.api.volume* tests
actually do much with it. Volumes are created, mapped, snapshotted, removed, etc, but
nothing is really written to it...
2. Is there a way to test multi-backend for real? Looks like in Tempest there's a
single 'storage_protocol' entry?
3. Is there a way to configure Nova and friends to use as much as possible the block
storage?
- Can I somehow get rid of the 'base' ? Don't need it if I can have a base as
volumes on the block storage.
- I've found out that Glance does not really support Cinder (the 'raise
NotImplementedError' under add() gave it away). Unless I misunderstood something, not
sure why it's documented everywhere.
(I've 'hacked' around it by creating /var/lib/glance/image_block, referring
Glance to use it. That in turn is a mount on a multipathed LUN. It works, but Glance is
regretfully copying files in 4K chunks for some reason. This is horrible
performance-wise).
- Conversion to raw is using only the first path in multipath (again, horrible
performance-wise. By default Nova is regretfully configured this way too - unless
use_multipath_for_image_xfer is set to True)
I'm using the forked Tempest from https://github.com/redhat-openstack/tempest , on
CentOS 6.5 (could not installed IceHouse on CentOS 7, known issue I believe), with
IceHouse (hoping to see RDO Juno packages soon!).
TIA,
Y.
11:47 a.m.
On Mon, Aug 11, 2014 at 04:00:08PM -0400, Kaul, Yaniv wrote:
[Can you convince your mailer to wrap very long lines?]
(Some of you may know me from my previous work at Red Hat - good to
see some familiar faces!)
Hi Yaniv,
(No direct answers to the Cinder/Tempest woes you present below, that I
snipped.)
[. . .]
(hoping to see RDO Juno packages soon!).
If you have any test environments based on Fedora, it already has Juno
Milestone-2 packages, for testing only.
$ yum update openstack-$component --enablerepo=
You should see package versions like that, which indicate Juno M-2
packages:
openstack-nova-2014.2-0.1.b2.fc22
openstack-cinder-2014.2-0.1.b2.fc22
(Most likely you're looking for CentOS-7 packages, which are in the
works from what I hear.)
--
/kashyap
12:02 p.m.
On Tue, Aug 12, 2014 at 10:17:19PM +0530, Kashyap Chamarthy wrote:
On Mon, Aug 11, 2014 at 04:00:08PM -0400, Kaul, Yaniv wrote:
[. . .]
If you have any test environments based on Fedora, it already has
Juno
Milestone-2 packages, for testing only.
$ yum update openstack-$component --enablerepo=
Sorry, typo, that was supposed to read:
$ yum update openstack-$component --enablerepo=rawhide
You should see package versions like that, which indicate Juno M-2
packages:
openstack-nova-2014.2-0.1.b2.fc22
openstack-cinder-2014.2-0.1.b2.fc22
(Most likely you're looking for CentOS-7 packages, which are in the
works from what I hear.)
--
/kashyap
9:12 a.m.
-----Original Message-----
From: Kashyap Chamarthy [mailto:kchamart@redhat.com]
Sent: Tuesday, August 12, 2014 7:47 PM
To: Kaul, Yaniv
Cc: rdo-list(a)redhat.com
Subject: Re: [Rdo-list] [QA] Tempest - is volume testing actually testing anything
with block storage?
On Mon, Aug 11, 2014 at 04:00:08PM -0400, Kaul, Yaniv wrote:
[Can you convince your mailer to wrap very long lines?]
It's not the mailer, it's me.
> (Some of you may know me from my previous work at Red Hat - good to
> see some familiar faces!)
Hi Yaniv,
(No direct answers to the Cinder/Tempest woes you present below, that I
snipped.)
[. . .]
> (hoping to see RDO Juno packages soon!).
If you have any test environments based on Fedora, it already has Juno
Milestone-2 packages, for testing only.
I really don't like to mix running targets (Fedora and OpenStack) while testing.
- On my F19, I could not find anything that was not 2013.1.
- I failed to upgrade it to F20. 'fedup' failed after reboot to upgrade it.
I'm quite fed up with it.
- I could not find packstack @
https://repos.fedorapeople.org/repos/openstack/openstack-trunk/fedora/ - perhaps it's
not the right location.
So, no go.
I'll wait. Patience is a virtue. Or I'll move to other distributions, we'll
see.
Thanks,
Y.
$ yum update openstack-$component --enablerepo=
You should see package versions like that, which indicate Juno M-2
packages:
openstack-nova-2014.2-0.1.b2.fc22
openstack-cinder-2014.2-0.1.b2.fc22
(Most likely you're looking for CentOS-7 packages, which are in the works from
what I hear.)
--
/kashyap
1:59 p.m.
On Mon, Aug 18, 2014 at 10:12:45AM -0400, Kaul, Yaniv wrote:
[. . .]
I really don't like to mix running targets (Fedora and
OpenStack)
while testing.
Fair enough.
- On my F19, I could not find anything that was not 2013.1.
- I failed to upgrade it to F20. 'fedup' failed after reboot
to
upgrade it. I'm quite fed up with it.
Hmm, as an alternative to fedup, I used the below method. FWIW, as I
write this, I just updated 3 machines successfully from f19 -> f20 with
these instructions:
$ yum update yum -y; yum clean all; \
yum --releasever=20 distro-sync --nogpgcheck -y
Followed by:
$ package-cleanup --problems ; package-cleanup --orphans \
package-cleanup --dupes ; package-cleanup --leaves
$ reboot
- I could not find packstack @
https://repos.fedorapeople.org/repos/openstack/openstack-trunk/fedora/
- perhaps it's not the right location.
From the above URL, seems like you're looking for latest packstack
for
Fedora. If so, they're always built first in Koji, so a consistent way
to check (that's what I've been doing):
For f20:
$ koji latest-build f20 openstack-packstack
Or, for the very latest packstack:
$ koji latest-build openstack-packstack
To download it (the package N-V-R is obtained from the above step) from
CLI:
$ koji download-build --arch=noarch \
openstack-packstack-2014.1.1-0.28.dev1238.fc22
And, to find latest builds for a specific package *across* current
releases:
$ bodhi -L openstack-packstack
Not sure if you're aware, RDO packages for Fedora follows Fedora distro
release schedule, i.e. once N+2 is released (Icehouse), we EOL N
(Grizzly). So, to map Fedora and OpenStack releases:
- Fedora-19 == Grizzly (2013.1) -- is now EOL
- Fedora-20 == Havana (2013.2) -- is currently "supported"
- Fedora-21 == IceHouse (2014.1) -- is currently "supported"
If you hit any issues, please post here, we'll see what we can do.
--
/kashyap
4:20 a.m.
On 08/11/2014 10:00 PM, Kaul, Yaniv wrote:
(Some of you may know me from my previous work at Red Hat - good to
see some familiar faces!)
yep, hi there :)
I'm working on testing a Cinder driver for OpenStack - IceHouse,
Havana, and Juno (regretfully, in that order).
I've quickly found out Tempest is not really testing much for real (example: if I
don't configure iSCSI, I still pass all tests but 5 of them!), so I'm doing some
'manual' tests.
Indeed, only Nova nodes connect to the volumes via iSCSI (and only for
certain Cinder backends), not the Cinder nodes so a majority of the
tests for Cinder succeed regardless of the iSCSI setup
1. Is there any test actually booting or running the VMs from the
block storage? I have it configured correctly (I think), but none of the relevant
tempest.api.volume* tests actually do much with it. Volumes are created, mapped,
snapshotted, removed, etc, but nothing is really written to it...
tempest.api.volume tests are testing Cinder API only
there are tests stressing the Nova Volume API (eg. attach) in:
tempest.api.compute.volumes
Some of these would require proper iSCSI setup for instance.
There are tests doing actual writes into the volumes too (eg. boot from
volume, snapshot, clone, reboot) in:
tempest/scenario/test_stamp_pattern.py
and
tempest/scenario/test_volume_boot_pattern.py
and
tempest/scenario/test_snapshot_pattern.py
lastly, with Tempest you can also run any of the API test (eg
tempest.api.*) in a loop with some parallelization and this is handful
to test a driver as operations may hang if the backend is not behaving
as expected
2. Is there a way to test multi-backend for real? Looks like in
Tempest there's a single 'storage_protocol' entry?
not that I know of
--
Giulio Fidente
GPG KEY: 08D733BA
3547
days inactive
3557
days old
5 comments
3 participants
participants (3)
-
Giulio Fidente -
Kashyap Chamarthy -
Kaul, Yaniv