Open Stack

On 22 February 2016 at 08:52, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Armando M. <armamig at gmail.com> wrote:
>
>
>>
>> On 22 February 2016 at 04:56, Ihar Hrachyshka <ihrachys at redhat.com>
>> wrote:
>> Sean M. Collins <sean at coreitpro.com> wrote:
>>
>> Armando M. wrote:
>> Now that the blocking issue has been identified, I filed project-config
>> change [1] to enable us to test the Neutron Grenade multinode more
>> thoroughly.
>>
>> [1] https://review.openstack.org/#/c/282428/
>>
>>
>> Indeed - I want to profusely thank everyone that I reached out to during
>> these past months when I got stuck on this. Ihar, Matt K, Kevin B,
>> Armando - this is a huge win.
>>
>> --
>> Sean M. Collins
>>
>> Thanks everyone to make that latest push. We are almost there!..
>>
>> I guess the next steps are:
>> - monitoring the job for a week, making sure it’s stable enough
>> (comparing failure rate to non-partial grenade job?);
>>
>> Btw, the job trend is here:
>>
>>
>> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=6&fullscreen
>>
>> I'd prefer to wait a little longer. Depending on how things go we may
>> want to make it not until N opens up.
>>
>
> Agreed.
>
>
>> - if everything goes fine, propose project-config change to make it
>> voting;
>> - propose governance patch to enable rolling-upgrade tag for neutron repo
>> (I believe not for *aas repos though?).
>>
>> I guess with that we would be able to claim victory for the basic 'server
>> vs. agent’ part of rolling scenario. Right?
>>
>> Follow up steps would probably be:
>> - look at enabling partial job for DVR flavour;
>>
>> That should be only instrumental to see how sane DVR during upgrades is,
>> and proceed in tweaking the existing grenade-multi job in the check queue
>> to be dvr-aware. In other words: I personally wouldn't want to see two
>> grenade jobs in the gate.
>>
>
> Ack, that would be the end goal. There still may be some short time when
> both are in gate.
>
>
>> - proceed on objectification of neutron db layer to open doors for later
>> mixed server versions in the same cluster.
>>
>> Anything I missed?
>>
>> Also, what do we do with non-partial flavour of the job? Is it staying?
>>
>> What job are you talking about exactly?
>>
>
> gate-grenade-dsvm-neutron
>
> It’s not ‘partial’ in that we don’t run mixed versions of components
> during tempest run. It only covers that new code can run using old
> configuration files, and that alembic migrations apply correctly for some
> limited number of so called ‘long standing’ resources like instances
> created on the ‘old’ side of grenade.


Yes, that is staying. Especially considering that's part of the integrate
gate on a bunch of other projects. We'll reconsider what to do, once we
strengthen our rolling upgrade story.


>
>
> Ihar
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160222/a90066ae/attachment.html>