On Fri, Oct 14, 2016 at 2:23 PM, Rodrigo Duarte <rodrigodso...@gmail.com>
> On Fri, Oct 14, 2016 at 1:10 PM, Clark Boylan <cboy...@sapwetik.org>
>> On Fri, Oct 14, 2016, at 08:21 AM, Rodrigo Duarte wrote:
>> > Hi all,
>> > Recently in keystone we got merged the PCI-DSS feature . Basically,
>> > have new settings that enforce password security practices. For example,
>> > if
>> > we set the password history setting to 2, a user won't be able to update
>> > its password to one of the last 2 that have been set in the past.
>> > The issue is that, this settings, can break a couple of tests in
>> > Assuming the non-admin users in this tests don't affect any other test,
>> > I've inserted a "security_compliance" feature flag and skipped the
>> > portion
>> > of the tests that can break when the PCI-DSS settings are enabled .
>> > With that, I've pushed another patch that sets these settings upon
>> > DevStack
>> > deployment  and added the actual tests for the feature at . So we
>> > have a "tempest -> devstack -> tempest" chain of patches dependencies.
>> Curious why the tests for this wouldn't go into the keystone functional
>> job  which appear to run as a tempest plugin? Testing of these
>> features shouldn't require any other service, just keystone right
>> (though this job does start and run other services)? One big reason I
>> ask is it could help constrain the testing of non default behaviors of
>> keystone to a single job rather than needing to edit a bunch of other
>> jobs or create new jobs just to toggle the non default behavior.
> That was the plan initially, but we considered two things:
> 1 - The users API is a pretty widely used API, so having it running in
> Tempest makes sense
> 2 - We need to add new settings in Tempest's config - I know that we can
> "inherit" the Tempest config's in the plugin, but looks strange having some
> stuff not actually used in Tempest but set there.
> But... If the both things above are acceptable, or even preferable, we can
> change the approach.
Turns out there were smarter ways to restore the user credentials after the
tests run, we won't need the first tempest patch after all.
Submitted the new changes at .
>> > I want your feedback regarding this, if this approach is acceptable and,
>> > if
>> > not, what are the options.
>> I don't really know which approach is more preferable but I think that
>> functional testing is an option too.
>> > Thanks!
>> >  https://blueprints.launchpad.net/keystone/+spec/pci-dss
>> >  https://review.openstack.org/#/c/382018/
>> >  https://review.openstack.org/#/c/377004/
>> >  https://review.openstack.org/#/c/378624/
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
> Rodrigo Duarte Sousa
> Senior Quality Engineer @ Red Hat
> MSc in Computer Science
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
OpenStack Development Mailing List (not for usage questions)