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)
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
