Open Stack

On 14/01/16 12:01, Davanum Srinivas wrote:
> Neil,
>
> The global requirements upper-constraints.txt do not cover neutron
> unit test targets. So the unit tests pick up latest from pypi.

I'm afraid I don't understand how that's related to my question below. 
Could you explain further?

It seems you might be saying that upper-constraints.txt should have no
effect on Neutron UTs.  But my understanding from Carl's message is that
an upper-constraints.txt change caused a Neutron UT (running as part of
a gate job) to fail.  So I'm not sure how to understand your statement.

Thanks,
    Neil


>
> -- Dims
>
>
>
> On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
>> On 13/01/16 19:27, Carl Baldwin wrote:
>>> Hi,
>>>
>>> I was looking at the most recent gate breakage in Neutron [1], fixed
>>> by [2].  This gate breakage was held off for some time by the
>>> upper-constraints.txt file.   This is great progress and I applaud it.
>>> I'll continue to cheer on this effort.
>>>
>>> Now to the next problem.   If my assessment of this gate failure is
>>> correct, the update to the upper-constraints file [3] was merged
>>> without running all of the tests across all of the projects that would
>>> be broken by bringing in this new constraint.  So, we still get
>>> breakage and it is still (IMO) too often.
>>>
>>> As I see it, there are a couple of options.
>>>
>>> 1) We run all tests under the upper-constraints control on all updates
>>> to the upper constraints file like [2].  This would probably mean each
>>> update has a very long list of tests and we would require that they
>>> all be fixed before the upper constraint update can be merged.  This
>>> seems like a difficult thing to coordinate all at once.
>>> 2) We handle upper-constraints much like we do the global requirements
>>> updates.  We have the master and a bot that proposes updates to it out
>>> to the individual projects.  This would create a situation where
>>> projects are out of sync with the master but I think if we froze the
>>> master early enough, we could have time to reconcile before release.
>>> 3) We continue to allow changes in the upper constraints to break
>>> individual projects.
>>>
>>> Are there options that I missed?  What is your opinion?  In my
>>> opinion, gate breakage happens a bit too often and the effect on the
>>> community is widespread.  I'd like to contain it even a little bit
>>> more.
>>>
>>> Carl
>>>
>>> [1] https://bugs.launchpad.net/neutron/+bug/1533638
>>> [2] https://review.openstack.org/#/c/266885/
>>> [3] https://review.openstack.org/#/c/266042/
>> I've only just started to learn about requirements and constraints, so I
>> may be misunderstanding.  However,
>> https://github.com/openstack/requirements/blob/master/README.rst says:
>>
>>> For upper-constraints.txt changes
>>>
>>> If the change was proposed by the OpenStack CI bot, then if the
>>> change has passed CI, only one reviewer is needed and they should +2
>>> +A without thinking about things.
>>>
>>> If the change was not proposed by the OpenStack CI bot, and does not
>>> include a global-requirements.txt change, then it should be rejected:
>>> the CI bot will generate an appropriate change itself. Ask in
>>> #openstack-infra if the bot needs to be run more quickly.
>> Doesn't that mean that [3] should have been rejected, and hence already
>> cover the recent situation?
>>
>>     Neil
>>
>>
>> __________________________________________________________________________
>> 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
>
>