<p dir="ltr">I'm confused, what is the context here? We use Ceph with OpenStack Kilo without issue.</p>
<div class="gmail_quote">On Nov 23, 2015 2:28 PM, "David Moreau Simard" <<a href="mailto:dms@redhat.com">dms@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Last I remember, David Gurtner tried to use Kilo instead of Juno but<br>
he bumped into some problems and we settled for Juno at the time [1].<br>
At this point we should already be testing against both Liberty and<br>
Infernalis, we're overdue for an upgrade in that regard.<br>
<br>
But, yes, +1 to split acceptance tests:<br>
1) Ceph<br>
2) Ceph + Openstack<br>
<br>
Actually learning what failed is indeed challenging sometimes, I don't<br>
have enough experience with the acceptance testing to suggest anything<br>
better.<br>
We have the flexibility of creating different logfiles, maybe we can<br>
find a way to split out the relevant bits into another file.<br>
<br>
[1]: <a href="https://review.openstack.org/#/c/153783/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/153783/</a><br>
<br>
David Moreau Simard<br>
Senior Software Engineer | Openstack RDO<br>
<br>
dmsimard = [irc, github, twitter]<br>
<br>
<br>
On Mon, Nov 23, 2015 at 2:45 PM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
> I think I have a good lead on the recent failures in openstack / swift /<br>
> radosgw integration component that we have since disabled. It looks like<br>
> there is a oslo.config version upgrade conflict in the Juno repo we where<br>
> using for CentOS. I think moving to Kilo will help sort this out, but at the<br>
> same time I think it would be prudent to separate the Ceph v.s. OpenStack<br>
> integration into separate jobs so that we have a better idea of which is a<br>
> problem. If there is census for this, I'd need some direction / help, as<br>
> well as set them up as non-voting for now.<br>
><br>
> Looking into this I also found that the only place that we do integration<br>
> any of the cephx logic was in the same test so we will need to create a<br>
> component for it in the ceph integration as well as use it in the OpenStack<br>
> side.<br>
><br>
> Lastly un-winding the integration failure seemed overly complex. Is there a<br>
> way that we can correlate the test status inside the job at a high level<br>
> besides the entire job passed / failed without breaking them into separate<br>
> jobs?<br>
> --<br>
><br>
> --<br>
><br>
> Andrew Woodward<br>
><br>
> Mirantis<br>
><br>
> Fuel Community Ambassador<br>
><br>
> Ceph Community<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>