[openstack-dev] [tripleo] add mistral to the auto-update package list for TripleO CI
Greetings, I'd like to propose that the mistral project be added to the list of projects where in CI the very latest built packages are added to each CI run [1]. This will help get patches that depend on mistral patches to more quickly be tested and merged. For example Honza's patch [2] depends on a merged mistral change. The mistral change has not yet landed in a tripleo build and mistral is not on the auto-update list, so the patch fails. Please respond if you would like to see mistral added or have any comments or concerns. Note that we are able to consider mistral for auto-updates because the mistral project has a voting tripleo job [3] and the tripleo project can be assured that the latest mistral patches will not break tripleo-ci. I would encourage other projects to consider adding tripleo jobs to their project to enable auto-updates as well [4] [1] https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70 [2] https://review.openstack.org/#/c/469608/ [3] https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665 [4] https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html __ 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
Re: [openstack-dev] [tripleo] add mistral to the auto-update package list for TripleO CI
I think I'm +0 on this. On the one hand we do have the gating job on Mistral, on the other hand our gate jobs don't exercise all of the functionality of some projects, especially Mistral. I know in the past introspection has been broken by changes in Mistral, and that wouldn't be caught by gate jobs. If we start using master all the time that becomes a blocker for TripleO since it will prevent our OVB jobs from passing. So I can understand the desire to use master of a tightly coupled project like Mistral, but it does open a hole in our promotion pipeline which I don't feel great about. If we had an OVB job running on every patch (and respected by the Mistral cores) I'd be +1 with no reservations. On 08/24/2017 04:04 PM, Wesley Hayutin wrote: Greetings, I'd like to propose that the mistral project be added to the list of projects where in CI the very latest built packages are added to each CI run [1]. This will help get patches that depend on mistral patches to more quickly be tested and merged. For example Honza's patch [2] depends on a merged mistral change. The mistral change has not yet landed in a tripleo build and mistral is not on the auto-update list, so the patch fails. Please respond if you would like to see mistral added or have any comments or concerns. Note that we are able to consider mistral for auto-updates because the mistral project has a voting tripleo job [3] and the tripleo project can be assured that the latest mistral patches will not break tripleo-ci. I would encourage other projects to consider adding tripleo jobs to their project to enable auto-updates as well [4] [1] https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70 [2] https://review.openstack.org/#/c/469608/ [3] https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665 [4] https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html __ 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
Re: [openstack-dev] [tripleo] add mistral to the auto-update package list for TripleO CI
On Thu, Aug 24, 2017 at 5:35 PM, Ben Nemec wrote: > I think I'm +0 on this. On the one hand we do have the gating job on > Mistral, on the other hand our gate jobs don't exercise all of the > functionality of some projects, especially Mistral. I know in the past > introspection has been broken by changes in Mistral, and that wouldn't be > caught by gate jobs. If we start using master all the time that becomes a > blocker for TripleO since it will prevent our OVB jobs from passing. > > So I can understand the desire to use master of a tightly coupled project > like Mistral, but it does open a hole in our promotion pipeline which I > don't feel great about. If we had an OVB job running on every patch (and > respected by the Mistral cores) I'd be +1 with no reservations. I am +1 on this. However, I do echo Ben's concerns. I will bring this up with the Mistral group at the PTG. We already have an experimental job available, but I'm guessing the major concern will be the amount of time it takes for a TripleO job to run. It would likely double the amount of time that a Mistral patch takes to get through CI. > > > On 08/24/2017 04:04 PM, Wesley Hayutin wrote: >> >> Greetings, >> >> I'd like to propose that the mistral project be added to the list of >> projects where in CI the very latest built packages are added to each CI run >> [1]. >> >> This will help get patches that depend on mistral patches to more quickly >> be tested and merged. For example Honza's patch [2] depends on a merged >> mistral change. The mistral change has not yet landed in a tripleo build >> and mistral is not on the auto-update list, so the patch fails. >> >> Please respond if you would like to see mistral added or have any comments >> or concerns. >> >> Note that we are able to consider mistral for auto-updates because the >> mistral project has a voting tripleo job [3] and the tripleo project can be >> assured that the latest mistral patches will not break tripleo-ci. >> >> I would encourage other projects to consider adding tripleo jobs to their >> project to enable auto-updates as well [4] >> >> [1] >> https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70 >> [2] https://review.openstack.org/#/c/469608/ >> [3] >> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665 >> [4] >> https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html >> >> >> __ >> 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 >> > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer __ 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
Re: [openstack-dev] [tripleo] add mistral to the auto-update package list for TripleO CI
On 25 August 2017 at 13:27, Brad P. Crochet wrote: > On Thu, Aug 24, 2017 at 5:35 PM, Ben Nemec wrote: > > I think I'm +0 on this. On the one hand we do have the gating job on > > Mistral, on the other hand our gate jobs don't exercise all of the > > functionality of some projects, especially Mistral. I know in the past > > introspection has been broken by changes in Mistral, and that wouldn't be > > caught by gate jobs. If we start using master all the time that becomes > a > > blocker for TripleO since it will prevent our OVB jobs from passing. > > > > So I can understand the desire to use master of a tightly coupled project > > like Mistral, but it does open a hole in our promotion pipeline which I > > don't feel great about. If we had an OVB job running on every patch (and > > respected by the Mistral cores) I'd be +1 with no reservations. > > I am +1 on this. However, I do echo Ben's concerns. I will bring this > up with the Mistral group at the PTG. We already have an experimental > job available, but I'm guessing the major concern will be the amount > of time it takes for a TripleO job to run. It would likely double the > amount of time that a Mistral patch takes to get through CI. > I agree with you both. So would be +1 to adding Mistral (and adding an OVB job to Mistral). I think the length of time will be a concern, but I think the overhead of Mistral contributors having to understand and debug failed tripleo gates could be a bigger problem. > > > > > > > On 08/24/2017 04:04 PM, Wesley Hayutin wrote: > >> > >> Greetings, > >> > >> I'd like to propose that the mistral project be added to the list of > >> projects where in CI the very latest built packages are added to each > CI run > >> [1]. > >> > >> This will help get patches that depend on mistral patches to more > quickly > >> be tested and merged. For example Honza's patch [2] depends on a merged > >> mistral change. The mistral change has not yet landed in a tripleo > build > >> and mistral is not on the auto-update list, so the patch fails. > >> > >> Please respond if you would like to see mistral added or have any > comments > >> or concerns. > >> > >> Note that we are able to consider mistral for auto-updates because the > >> mistral project has a voting tripleo job [3] and the tripleo project > can be > >> assured that the latest mistral patches will not break tripleo-ci. > >> > >> I would encourage other projects to consider adding tripleo jobs to > their > >> project to enable auto-updates as well [4] > >> > >> [1] > >> https://github.com/openstack/tripleo-quickstart/blob/ > master/config/release/tripleo-ci/master.yml#L54-L70 > >> [2] https://review.openstack.org/#/c/469608/ > >> [3] > >> https://github.com/openstack-infra/project-config/blob/ > master/zuul/layout.yaml#L11665 > >> [4] > >> https://docs.openstack.org/tripleo-docs/latest/ > contributor/check_gates.html > >> > >> > >> > __ > >> 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 > >> > > > > > > -- > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS > Principal Software Engineer > > __ > 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