On Fri, Nov 4, 2016 at 1:36 PM, Raoul Scarazzini <rasca@redhat.com> wrote:

Hi guys,
just would like to share the status around the role in the subject so to
keep the one interested up to date. What we want to achieve with this
role is to have a ready to use baremetal undercloud, like the virtual
one produced by tripleo-quickstart.
At the moment there is just one job in the RDO pipeline that uses this
role [1], plan is to have more than this, because you already know that
"with baremetal is never easy".

This role sets up the undercloud on a provided server directly w/o setting up a virtual guest for the undercloud.

I would think the performance team would be interested in this role so that the undercloud performance metrics are not skewed by libvirt.

I was also thinking it may be useful in the multinode nodepool workflow, where the undercloud is directly installed.  I don't see there being an advantage in using it, but I could be missing something. 

I could also see ops teams taking advantage of this to deploy out to production environments.  We would need to ensure the role is uncoupled from any provisioning, but I see it being valuable for sure.

I've copied some other folks to get their thoughts.

Thanks Raoul! 

I've worked to make the role integrate with the oooq evolution, trying
to reuse as much as possible the existing extra roles. So, with the
latest modifications the role does these basic task:

1) machine-provision: provide the machine with specific a script that
needs to be passed;
2) machine-setup: create the user, add the machine to ansible inventory
and basically makes virthost == undercloud;
3) undercloud-repos-conf: configure the repos based upon the release
parameter passed to quickstar.sh command line;
4) overcloud-images: download the images again based upon the release
parameter;

So a playbook that deploys a complete undercloud baremetal env should
include these roles:

- tripleo-baremetal-undercloud
- undercloud-scripts (from tripleo-quickstart)
- undercloud-install (from tripleo-quickstart)

The additional role for the baremetal preparation must be used to finish
the bm setup:

- overcloud-prep-baremetal

And then, from this point on, everything can proceed with the usual
order, so:

- overcloud-prep-config
- overcloud-prep-images
- overcloud-prep-flavors
- overcloud-prep-network
- tripleo-overcloud
- tripleo-inventory

In addition one can specify the validation steps, in my case I'm using
this [2] because of HA.

Interventions were needed on these roles:

- ansible-role-tripleo-overcloud-prep-network: Do not copy
network-environment.yaml on baremetal [3];
- ansible-role-tripleo-overcloud-prep-baremetal: Add optional upstream
ipxe installation [4];
- ansible-role-tripleo-baremetal-undercloud: Integrate role with oooq
extra roles [5];

That's basically all, all this stuff was tested as working on a bm env,
and basically I'm asking now for reviews and considerations.

Thanks,

[1]
https://rhos-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/tripleo-quickstart-newton-baremetal-undercloud-haa01-lab-float_nic_with_vlans/
[2]
https://github.com/redhat-openstack/ansible-role-tripleo-overcloud-validate-ha
[3] https://review.gerrithub.io/#/c/300865/
[4] https://review.gerrithub.io/#/c/300866/
[5] https://review.gerrithub.io/#/c/300869/

--
Raoul Scarazzini
rasca@redhat.com

_______________________________________________
rdo-list mailing list
rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list

To unsubscribe: rdo-list-unsubscribe@redhat.com