Open Stack

Well, even though it's an experimental job, the TLS-everywhere job
(fakeha-caserver) is quite stable at the moment; I still need to add the
novajoin service to it, to reflect what people will hopefully be using, but
other than that it's been running and doing fine. I would like to bring up
that currently, the oooq OVB jobs are incompatible with what we do with
that job.

Basically, from what I've understood, oooq OVB jobs use the undercloud
provided by the quintupleo stack, while currently in CI we rely on the node
provided by nodepool and install the undercloud there. For the
TLS-everywhere job, we use that undercloud as well, and spin up a very low
memory node to deploy FreeIPA in there, but this wouldn't be possible in
the oooq solution. I would like to discuss alternatives for this.

Any thoughts?

BR

On Wed, Feb 1, 2017 at 1:47 AM, Gabriele Cerami <gcerami at redhat.com> wrote:

> Hi,
>
> despite CI freeze for substantial change is in order, I recognize
> there's always the need to add or modify slightly the jobs for
> important fixes or to improve debugging.
>
> Unfortunately in these days we are wrapping up the gap in feature
> coverage between tripleo-ci and quickstart, and any of those change is
> increasing the list of features to be added to the implementation,
> making the wrap a moving target.
> Also, I'm seen some more-than-minor changes merged in these days, and
> that is making this job even more difficult.
>
> For those reason, we're going to ask everybody, from this moment on, for
> every change proposed to tripleo-ci, to propose an equivalent change to
> quickstart, or, if it seems too difficult, to open a bug in quickstart,
> pointing at the change in tripleo-ci, with some explanation on why it's
> needed, if it's not already clear in the commit message.
>
> At the end of this week we're going to make the final cut to the list
> of features we're going to transition to quickstart. If a feature, a
> test, an improvement, a small fix is added in tripleo-ci without
> signaling quickstart in any way, the risk is that the change will go
> unnoticed, and will be lost in transition.
>
> thanks for your collaboration.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170201/5cc5c5a9/attachment.html>