My two cents.


On 04/04/2017, 13:39, "Monty Taylor" <mord...@inaugust.com> wrote:

    Hey all!

    I woke up early this morning and found myself thinking "I clearly don't
    have enough work on my plate, why don't I add some more?"

    I'd love to make a gate job that:
    - Deploys a cloud with openstack-ansible
    - Runs shade's functional tests against that cloud

How do you run these functional tests? Do you expect this as a simple tox run, 
a tempest scenario, or anything else?

    Which makes me think it just needs to be an additional scenario perhaps?

I think a scenario is good, but we could consider this test as part of a basic 
end-to-end testing. If the tests aren’t too long, we could include them at the 
end of an AIO run to make sure everything “works as expected” for both tempest 
and shade. Sadly, our jobs are already long and hitting timeouts on some 

    As I started to poke, I need to figure out the best way to accomplish
    something. Namely, shade's functional tests expect a clouds.yaml that
    defines two entires - one admin and one non-admin.

    OSA already creates a clouds.yaml with admin creds, so that's done. And
    there is already tempest setup that creates a demo user, so that's done
    too. Here's where I could use some advice:

    - What's the best way to plumb through an option to also write an entry
    to clouds.yaml for the demo user? I'm thinking a boolean in
    openstack-ansible-openstack_openrc like
    "openrc_clouds_yml_add_demo_user" that can be wrapped around a second
    entry in clouds.yaml.j2?

I’d agree with Jesse definition there: have vars defined in utility_all group 
vars (or like jesse said, something in the AIO prep).
These vars would:
- override the openstack_openrc default vars (we need to adapt the tasks in 
openstack_openrc “Create openrc” to include a loop + “Create clouds.yaml” to 
generate a more complete clouds.yaml according to the users defined in the dict)
- override the tempest user creation (we need to adapt the tasks in tempest to 
be a var + at the same time we could maybe move to ansible os_ modules there, 
that would also be a win for shade)

    - Can we create the demo user and not run tempest? It's in the
    os_tempest role at the moment. Should I split out the user creation bits
    into a "test_setup" role that tempest depends on - and then also make a
    shade_test role that also depends on the test_setup role?

I like this approach.
If you want a shorter path, you can still define in the user variables 
``tempest_run: False`` for the scenario, and we could have an include 
shade_run. I guess it all depends on shade_run content and if that deserves the 
burden of a role to maintain.
If you think shade_test deserves a role, we could transfer the maintenance 
burden to you by including it in the ansible-role-requirements, but not under 
the openstack-ansible umbrella, like we do for some external roles. We could 
then adapt the plays, or use an include_role inside tempest role for laziness.

    - If we do a test_setup role, should that maybe just write a whole
    additional clouds.yaml out that has the admin and the demo user so that
    we don't have to put conditionals in places that also get used for prod

We used to need the openrc role to happen before the tempest role IIRC.
We couldn’t have one role fits all. However, I see in that model that tempest 
or shade roles could both have a meta dep on openrc, and openrc being the 
source of truth for generating openrc like files (openrc + clouds.yaml). Openrc 
could then be used for production deploys to have a more complete clouds.yaml 
Maybe it’s worth splitting the clouds.yaml with a secure.yaml in that case too. 
But that’s another topic.

    I think that's about all the questions I have for now ...


    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to