[Rdo-list] Blueprint: Delorean & Khaleesi

[John Trowbridge]

Removed internal list from CC.

On 11/07/2015 12:35 PM, Arie Bregman wrote:
> On Sat, Nov 7, 2015 at 12:07 AM, David Moreau Simard <dms at redhat.com> wrote:
> 
>> Can we extend this to rdo-list ? Sounds relevant to the community.
>>
> 
> Sure, good idea. Adding rdo-list.
> 
> 
>>
>> David Moreau Simard
>> Senior Software Engineer | Openstack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>>
>> On Fri, Nov 6, 2015 at 4:36 PM, Wesley Hayutin <whayutin at redhat.com>
>> wrote:
>>> Arie,
>>> This looks good.
>>> Who is going to maintain the delorean ci job?
>>
> 
> Who maintains it today? we'll have to discuss it. It might be good idea to
> add 'job owner/maintainer' info as we have in rhos CI.
> 
>> Have you reached out to Derek Higgins about writing a replacement for the
>>> current delorean ci?
>>
> 
> No. The work on this has just begun. Adding Derek to this mail.
> 
>>
>>> Thanks
>>>
>>> On Fri, Nov 6, 2015 at 11:21 AM, Steve Linabery <slinaber at redhat.com>
>> wrote:
>>>>
>>>> On Fri, Nov 06, 2015 at 05:49:05PM +0200, Arie Bregman wrote:
>>>>> Hi everyone,
>>>>>
>>>>> Not sure if you all familiar with Delorean project[1]. Quick
>>>>> introduction
>>>>> (CI related) for those who are not:
>>>>>
>>>>> Delorean is an upstream project that builds and maintains yum
>>>>> repositories.
>>>>> It builds repository every time patch submitted to one of the upstream
>>>>> openstack-packages projects.
>>>>> The delorean job is located here:
>>>>> https://prod-rdojenkins.rhcloud.com/job/delorean-ci
>>>>>
>>>>> How the job works at the moment:
>>>>> It runs delorean directly on the slave and if the build process
>>>>> succeeded,
>>>>> it votes with +1
>>>>>
>>>>> What I suggest:
>>>>> - Move delorean installation and run to khaleesi by creating
>> 'delorean'
>>>>> role
>>>>> - Extend the job to run tests using the rpms delorean built
>>>>>
>>>>> Why:
>>>>> - Main reason: It's important for developers to get immediate feedback
>>>>> on
>>>>> whether the new packages are good or not. simply run delorean and see

My main contention is that this actually would lower the "immediateness"
of the feedback. The fastest rdo-manager job we have using tempest smoke
is the non-ha job, and it currently takes 90 minutes. So instead of a
6min job to check the general sanity of the package we would have a
90min job running against every packaging change.

I am not really convinced that packaging changes break us often enough
to warrant that. Maybe that happens more on the core service side than
on the RDO-Manager side, but on the RDO-Manager side I do not think I
have seen a bad package change break everything in the year I have been
working on it. (and there have been plenty of total breakages in that
time to constitute a decent sample size)

>> if
>>>>> build is ok, is not enough. We need to extend the current job.
>>>>>
>>>>> - Users can use khaleesi to test specs they wrote. This is actually
>>>>> pretty
>>>>> amazing. users write specs and run khaleesi. khaleesi then handles
>>>>> everything - it building the rpms using delorean and run the tests.
>>>>>

I am not opposed to adding this functionality to khaleesi, as it seems
generally useful from a developer perspective. I am opposed to using it
to gate packaging changes, unless there is some evidence that we are
breaking everything with our packaging changes often enough to warrant a
15x or higher increase in the gate job.

>>>>> - We can use delorean to replace our current way to build rpms and
>>>>> creating
>>>>> repos. delorean doing it in a smart way, using docker and by that it
>>>>> creates rpms for several distributions in isolated environment.
>>>>
>>>> Delorean no longer uses docker.
>>>>
>>>>
>>>>
>> https://github.com/openstack-packages/delorean/commit/66571fce45a007bcf49fd54ad7db622fd737874f
>>
> 
> Interesting. any idea why this change? adding Alan.
> 

We essentially rewrote mock in a docker container. Just using mock made
more sense from a maintainability standpoint.

> 
>>
>>>>
>>>>>
>>>>> - Khaleesi awesomeness will increase
>>>>>
>>>>> There is also no need to add/maintain settings in khaleesi for that.
>>>>> delorean properties (version, url, etc) will be provided by extra-vars
>>>>> (unless you are in favor of maintaining general settings for delorean
>> in
>>>>> khaleesi)
>>>>>
>>>>> The new job work flow:
>>>>> 1. Run delorean on slave and save rpms from delorean build process.
>>>>> 2. Run provision playbook
>>>>> 3. Copy delorean rpms to provisioned nodes and create repo for them on
>>>>> each
>>>>> node
>>>>> 4. run installer playbooks (installer will use delorean rpms)
>>>>> 5. Run Tests =D
>>>>> 6. Vote +1/-1 according to build process + tests.
>>>>>
>>>>> step 3 can be replaced. Since delorean creates repository, we can
>> simply
>>>>> reference each node to the new repository on the slave.
>>>>>
>>>>> Would love to hear your opinion on that.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Arie
>>>>>
>>>>> P.S
>>>>> started to work on that: https://review.gerrithub.io/#/c/251464
>>>>>
>>>>> [1] https://github.com/openstack-packages/delorean
>>>>
>>>
>>
> 
> 
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscribe at redhat.com
>