[openstack-dev] Failing temptest test for pending change

Álvaro López García alvaro.lopez.garcia at cern.ch
Wed Jun 12 12:21:58 UTC 2013


On Mon 10 Jun 2013 (11:45), Dolph Mathews wrote:
> On Mon, Jun 10, 2013 at 11:20 AM, Sean Dague <sean at dague.net> wrote:
> 
> > On 06/10/2013 11:26 AM, Dolph Mathews wrote:
> >
> >>
> >> On Mon, Jun 10, 2013 at 9:23 AM, Sean Dague <sean at dague.net
> >>     Typically the route is propose the tempest change, and get core
> >>     contributors from the core project (this time keystone) to +1 it
> >>     (saying that they agree with the change).
> >>
> >>     The core team for keystone would need to believe that this doesn't
> >>     represent an API change without a version bump. And that
> >>     python-keystoneclient would do the right things with a new client on
> >>     an older system. But I'll leave that up to them.

Thanks Sean for the explanation. Now the workflow is much clearer for
men. What about adding this information to [1]?

[1] https://wiki.openstack.org/wiki/GerritJenkinsGithub#Test_Failures

> >> This definitely doesn't represent an API change, and would be backwards
> >> compatible with existing clients (this validation is only performed
> >> server side, anyway).
> >>
> >> Following Chmouel's comment on the review, I'm wondering if it would be
> >> possible to preserve the existing default but make this value
> >> configurable moving forward (which would mean no changes in tempest).
> >> I'll save that discussion for the code review, but wanted to mention the
> >> possibility of not affecting tempest here.

I already submitted a new patch making it configurable (I missed these
last mails) but I am happy to revert it and get with the original
approach.

> > Making this configurable seems like a bad idea from a cross cloud
> > compatibility perspective. If your application that creates users depends
> > on a certain user name size, then can't be used on other clouds because
> > they set their default too low, then that would be an issue.
> >
> > Why not just bump it to 255, which is a reasonable db threshold, and be
> > done with it.
> 
> 
> Even better, if that works for LDAP

255 seems a quite reasonable value for me. If you are all OK with that I
can resubmit the original patch with this new increased value.

Cheers,
-- 
Álvaro López García                              aloga at ifca.unican.es



More information about the OpenStack-dev mailing list