On 07/29/2016 09:25 AM, John Spray wrote:
Hi folks,
We're starting to look at providing NFS on top of CephFS, using NFS
daemons running in Nova instances. Looking ahead, we can see that
this is likely to run into similar issues in the openstack CI that the
generic driver did.
I got the impression that the main issue with testing the generic
driver was that bleeding edge master versions of Nova/Neutron/Cinder
were in use when running in CI, and other stuff had a habit of
breaking. Is that roughly correct?
The breakages related to using HEAD were mostly related to Tempest. For
Nova, Neutron, and Cinder, the problems are more related to running a
cloud within a cloud and having severely limited resources. Things take
a long time and sometimes don't happen at all.
If you need a service VM to do real work, you can't create many of them
and you can expect creation of each one to be quite slow. For the
generic driver, we attempt to overcome the slowness by parallelizing
tests, and sharing the VM resources between test groups, but that
creates its own set of concurrency issues.
Our current approach to these problems is to not use the generic driver
for most things, and to limit the tests we do run on the generic driver
to only what's needed to ensure that driver isn't broken. Also, there is
an effort to shrink the "service image" used by the generic driver so
it's less resource hungry. Hopefully with those changes we can avoid the
resource sharing in tempest and while still keeping test run times
within reason.
Assuming versions are the main issue, we're going to need to look at
solutions to that, which could mean either doing some careful pinning
of the versions of Nova/Neutron used by Manila CI in general, or
creating a separate CI setup for CephFS that had that version pinning.
My preference would be to see this done Manila wide, so that the
generic driver could benefit as well.
I don't think pinning versions of the other projects would help much,
for reason I outlined above.
-Ben
Thoughts?
John
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
