[rdo-list] [quickstart] Status of undercloud baremetal role and future evolutions
Justin Kilpatrick
jkilpatr at redhat.com
Tue Nov 8 13:45:22 UTC 2016
Nice job Raoul, I'll probably be using this for a couple of things in the
coming weeks. Expect more formal overcloud deployment benchmarking soon as
I'm wrapping up the alpha of a tool for it, comparing virt vs non-virt
underclouds will be worthwhile I'm sure.
On Mon, Nov 7, 2016 at 9:53 PM, Wesley Hayutin <whayutin at redhat.com> wrote:
>
>
> On Fri, Nov 4, 2016 at 1:36 PM, Raoul Scarazzini <rasca at 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/tri
>> pleo-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 at redhat.com
>>
>> _______________________________________________
>> rdo-list mailing list
>> rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20161108/7420d9a9/attachment.html>
More information about the dev
mailing list