Thanks!
Renat Akhmerov @Nokia On 8 Aug 2017, 23:23 +0700, Matthew Thode <prometheanf...@gentoo.org>, wrote: > On 17-08-08 08:03:42, Matthew Thode wrote: > > On 17-08-08 16:11:53, Renat Akhmerov wrote: > > > Hi, > > > > > > We recently sent a patch [1] to release the version 3.1.2 of > > > python-mistralclient out of Pike branch. It was done after the date of > > > final client library releases so we’d like to discuss if we can allow > > > such an exception. All the projects mentioned in the subject may be > > > affected so please share if the change is acceptable for you or not. > > > Details are below. > > > > > > When using Mistral CLI in real deployments we found that some of the list > > > commands may be extremely heavy (mostly memory footprint) when called w/o > > > the “limit” parameter that constrains the result set by the specified > > > value. For example, “mistral execution-list”, “mistral task-list” and > > > “mistral action-execution-list”. We saw a number of times that machines > > > went out of memory after running such a command, sometimes it was done by > > > mistake by operators. So we decided to set a default value for this > > > parameter, which is currently 100, to prevent from unintentional > > > execution of such heavy commands. The corresponding patch [2] was sent on > > > July 11 and was included in the release 3.1.1. For > > > “action-execution-list”, before this patch “limit" parameter didn’t exist > > > at all so we added it too. However, the change wasn’t made properly so > > > that “limit” parameter was just ignored at all times. We fixed that in > > > [3] and decided to release 3.1.2. > > > > > > So long story short, this change will affect your project only if you use > > > “mistral action-execution-list” CLI command because now this command will > > > be returning by default only 100 entries (to return all “--limit=-1” > > > needs to be passed). > > > > > > We at Nokia need this fix released in Pike because we need to trigger > > > updates of RDO packages used in our system. > > > > > > > > > The question: can we afford to make this release now? > > > > > > More details on requirements updates etc. you can see in the discussion > > > in [1]. > > > > > > [1] https://review.openstack.org/#/c/491269 > > > [2] https://review.openstack.org/#/c/476110/ > > > [3] https://review.openstack.org/#/c/489217/ > > > > > > Thanks > > > > > > Renat Akhmerov > > > @Nokia > > > > > __________________________________________________________________________ > > > 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 > > > > It sounds like you will need a requirements update as well, both UC and > > maybe GR. GR would suck at this VERY late point. The current minimum > > is 3.1.0 will that not work just like 3.1.1 doesn't work? > > > > -- > > Matthew Thode (prometheanfire) > > ok, after discussing in irc... > > 3.1.2 has a user interface only change fixing a regression in 3.1.1 that > doesn't > not exist in 3.1.0, so no GR bump is needed. > > I'm fine with requirements doing a UC only bump here. > > FFE allowed for requirements for UC only (my vote) > > -- > Matthew Thode (prometheanfire) > > __________________________________________________________________________ > 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
