<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I pushed an overly optimistic review [1] for updating Openstack to Liberty.</div><div class="gmail_default" style="font-family:monospace,monospace">Haven't had the time to look back at it yet.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The general idea was to defer the repository setup to openstack_extras and pull in</div><div class="gmail_default" style="font-family:monospace,monospace">the keystone setup mostly as-is directly from puppet-openstack-integration.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[1]: <a href="https://review.openstack.org/#/c/251531/">https://review.openstack.org/#/c/251531/</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><br>David Moreau Simard<br>Senior Software Engineer | Openstack RDO<br><br>dmsimard = [irc, github, twitter]</div></div>
<br><div class="gmail_quote">On Wed, Dec 2, 2015 at 5:45 AM, David Gurtner <span dir="ltr"><<a href="mailto:dgurtner@redhat.com" target="_blank">dgurtner@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So from the discussion I gather we should do the following:<br>
<br>
- Update the jobs to run Infernalis<br>
- Split the RGW jobs into smaller chunks where one tests just the RGW and another one tests Keystone integration<br>
- Use Liberty (or at least Kilo) for the Keystone integration job<br>
- Split the tests more to have a test specifically for cephx functionality<br>
- re-enable the tests for CentOS once they work again<br>
<br>
Open points from my POV are:<br>
<br>
- should we test older Ceph versions via Jenkins (this would increase the runtime again)<br>
- should we still test CentOS 6 and Ubuntu 12.04<br>
- if yes, where<br>
- should we port more of the deprecated rspec-puppet-system tests? things I can think of are: 1) the profile tests 2) the scenario_node_terminus/hiera tests<br>
<br>
I'm happy to start working on the split of tests and the Infernalis/Liberty version bump tonight.<br>
<br>
Cheers,<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
> Hey Adam,<br>
><br>
> A bit late here, sorry.<br>
> Ceph works fine with OpenStack Kilo but at the time we developed the<br>
> integration tests for puppet-ceph with Kilo, there were some issues<br>
> specific to our test implementation and we chose to settle with Juno<br>
> at the time.<br>
><br>
> On the topic of CI, I can no longer sponsor the third party CI<br>
> (through my former employer, iWeb) as I am with Red Hat now.<br>
> I see this as an opportunity to drop the custom system tests with<br>
> vagrant and instead improve the acceptance tests.<br>
><br>
> What do you think ?<br>
><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 6:45 PM, Adam Lawson <<a href="mailto:alawson@aqorn.com">alawson@aqorn.com</a>> wrote:<br>
> > I'm confused, what is the context here? We use Ceph with OpenStack Kilo<br>
> > without issue.<br>
> ><br>
> > On Nov 23, 2015 2:28 PM, "David Moreau Simard" <<a href="mailto:dms@redhat.com">dms@redhat.com</a>> wrote:<br>
> >><br>
> >> 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<br>
> >> > where<br>
> >> > using for CentOS. I think moving to Kilo will help sort this out, but at<br>
> >> > the<br>
> >> > same time I think it would be prudent to separate the Ceph v.s.<br>
> >> > OpenStack<br>
> >> > integration into separate jobs so that we have a better idea of which is<br>
> >> > 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<br>
> >> > 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<br>
> >> > OpenStack<br>
> >> > side.<br>
> >> ><br>
> >> > Lastly un-winding the integration failure seemed overly complex. Is<br>
> >> > 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<br>
> >> > 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>
> >> > __________________________________________________________________________<br>
> >> > OpenStack Development Mailing List (not for usage questions)<br>
> >> > Unsubscribe:<br>
> >> > <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>
> ><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>
</div></div></blockquote></div><br></div>