Open Stack

On 4/4/17, 1:39 PM, "Monty Taylor" <mordred at inaugust.com> wrote:

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

Fantastic. Let’s see how we can help.

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

Maybe. Our scenario’s, right now, are focused more around what Infrastructure/OpenStack services are deployed. If you want/need a larger set than our default ‘aio’ scenario, then yes a different scenario would need to be setup. The alternative, of course, is to override the confd_overrides var in your test setup with an ‘aio’ scenario of your own – but I think it’d be nice to rather bake whatever you need in so that we can help maintain it.
https://github.com/openstack/openstack-ansible/blob/master/tests/bootstrap-aio.yml#L28-L46

>    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?

Well, an option could be that an arbitrary dict could be looped through to add any content for additional entries in clouds.yml – we could then have the tempest demo account settings pulled out of the tempest role (they’re hard coded there now, and probably should not be), then have the role loop through the same dict if it’s defined. The dict can then be defined in the utility_all group vars or are perhaps best only set in the AIO prep config (so that they don’t end up being used in production deployments).

>    - 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?

Well, creating a user and a different clouds.yaml file could also be done with a few tasks in a playbook. Unless there’s an opportunity for re-use I don’t really see the point of creating a role for it.

>    - 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
>    deploys?

The existing tempest role creation of a static set of demo accounts is terrible anyway. We should ideally make them adaptable and ensure that the passwords are randomized.


________________________________
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 abuse at rackspace.com and delete the original message. Your cooperation is appreciated.