Open Stack

On Thu, Mar 29, 2018 at 11:32 AM, David Moreau Simard
<dmsimard at redhat.com> wrote:
> Nice!
>
> I don't have a strong opinion
> about this but what I might recommend would be to chat with the
> openshift-ansible [1] and the kolla-ansible [2] folks.
>
> I'm happy to do the introductions if necessary !
>
> Their models, requirements or context might be different than ours but at
> the end of the day, it's a set of Ansible roles and playbooks to install
> something.
> It would be a good idea just to informally chat about the reasons why their
> things are set up the way they are, what are the pros, cons.. or their
> challenges.
>
> I'm not saying we should structure our things like theirs.
> What I'm trying to say is that they've surely learned a lot over the years
> these projects have existed and it's surely worthwhile to chat with them so
> we don't repeat some of the same mistakes.
>
> Generally just draw from their experience, learn from their conclusions and
> take that into account before committing to any particular model we'd like
> to have in TripleO ?

Yea it'd probably be a good idea to check with them on some of their
structure choices.  I think we do not necessarily want to use a
similar structure to those based on our experiences with oooq,
openstack-puppet-modules, etc.  I think this first iteration to get
some of the upgrade tasks out of the various */services/*.yaml will
help us build out a decent structure that might be reusable.  I did
notice that kolla-ansible has a main.yaml[0] that might be interesting
for us to consider when we start using the ansible roles directly
rather than importing the tasks themselves.

What I'd really like for us to work on is better cookiecutter/testing
structure for ansible roles themselves so we stop just merging ansible
bits that are only tested via full deployment tests (which we may not
even run).  As much as I hate rspec puppet tests, it is really nice
for testing the logic without having to do an actual deployment.

Thanks,
-Alex

[0] https://git.openstack.org/cgit/openstack/kolla-ansible/tree/ansible/roles/keystone/tasks/main.yml

>
> [1]: https://github.com/openshift/openshift-ansible
> [2]: https://github.com/openstack/kolla-ansible
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
> On Thu, Mar 29, 2018, 12:34 PM David Peacock, <dpeacock at redhat.com> wrote:
>>
>> Hi everyone,
>>
>> During the recent PTG in Dublin, it was decided that we'd prototype a way
>> forward with Ansible tasks in TripleO that adhere to Ansible best practises,
>> creating dedicated roles with unique git repositories and RPM packaging per
>> role.
>>
>> With a view to moving in this direction, a couple of us on the TripleO
>> team have begun developing tooling to facilitate this.  Initially we've
>> worked on a tool [0] to extract Ansible tasks lists from
>> tripleo-heat-templates and move them into new formally structured Ansible
>> roles.
>>
>> An example with the existing keystone docker service [1]:
>>
>> The upgrade_tasks block will become:
>>
>> ```
>> upgrade_tasks:
>>   - import_role:
>>       name: tripleo-role-keystone
>>       tasks_from: upgrade.yaml
>> ```
>>
>> The fast_forward_upgrade_tasks block will become:
>>
>> ```
>> fast_forward_upgrade_tasks:
>>   - import_role:
>>       name: tripleo-role-keystone
>>       tasks_from: fast_forward_upgrade.yaml
>> ```
>>
>> And this role [2] will be structured:
>>
>> ```
>> tripleo-role-keystone/
>> └── tasks
>>     ├── fast_forward_upgrade.yaml
>>     ├── main.yaml
>>     └── upgrade.yaml
>> ```
>>
>> We'd love to hear any feedback from the community as we move towards this.
>>
>> Thank you,
>> David Peacock
>>
>> [0]
>> https://github.com/davidjpeacock/openstack-role-extract/blob/master/role-extractor-creator.py
>> [1]
>> https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/keystone.yaml
>> [2] https://github.com/davidjpeacock/tripleo-role-keystone
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>