Last I remember, David Gurtner tried to use Kilo instead of Juno but he bumped into some problems and we settled for Juno at the time [1]. At this point we should already be testing against both Liberty and Infernalis, we're overdue for an upgrade in that regard.
But, yes, +1 to split acceptance tests: 1) Ceph 2) Ceph + Openstack Actually learning what failed is indeed challenging sometimes, I don't have enough experience with the acceptance testing to suggest anything better. We have the flexibility of creating different logfiles, maybe we can find a way to split out the relevant bits into another file. [1]: https://review.openstack.org/#/c/153783/ David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward <xar...@gmail.com> wrote: > I think I have a good lead on the recent failures in openstack / swift / > radosgw integration component that we have since disabled. It looks like > there is a oslo.config version upgrade conflict in the Juno repo we where > using for CentOS. I think moving to Kilo will help sort this out, but at the > same time I think it would be prudent to separate the Ceph v.s. OpenStack > integration into separate jobs so that we have a better idea of which is a > problem. If there is census for this, I'd need some direction / help, as > well as set them up as non-voting for now. > > Looking into this I also found that the only place that we do integration > any of the cephx logic was in the same test so we will need to create a > component for it in the ceph integration as well as use it in the OpenStack > side. > > Lastly un-winding the integration failure seemed overly complex. Is there a > way that we can correlate the test status inside the job at a high level > besides the entire job passed / failed without breaking them into separate > jobs? > -- > > -- > > Andrew Woodward > > Mirantis > > Fuel Community Ambassador > > Ceph Community > > > __________________________________________________________________________ > 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