On Fri, Nov 4, 2016 at 1:36 PM, Raoul Scarazzini <rasca(a)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(a)redhat.com
 _______________________________________________
 rdo-list mailing list
 rdo-list(a)redhat.com
 
https://www.redhat.com/mailman/listinfo/rdo-list
 To unsubscribe: rdo-list-unsubscribe(a)redhat.com