Open Stack

fwiw
We've been building arm images for tripleo and posting them.
https://images.rdoproject.org/aarch64/pike/delorean/current-tripleo-rdo/


This uses delorean and overcloud build:

    DIB_YUM_REPO_CONF+="/etc/yum.repos.d/delorean-deps-${OSVER}.repo
/etc/yum.repos.d/delorean-${OSVER}.repo /etc/yum.repos.d/ceph.repo
/etc/yum.repos.d/epel.repo /etc/yum.repos.d/radez.fedorapeople.repo" \
    openstack --debug overcloud image build \
        --config-file overcloud-aarch64.yaml \
        --config-file
/usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml \
        --config-file
/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos7.yaml
    # --config-file overcloud-images.yaml --config-file
overcloud-images-centos7.yaml --config-file aarch64-gumpf.yaml --image-name
    #openstack --debug overcloud image build --type overcloud-full
--node-arch aarch64

It's not quite an orthodox RDO build, There are still a few things in
place that work around arm related packaging discrepancies or x86
related configs. But we get good builds from it.

I don't know the details of what overcloud build does to the dib builds,
Though I don't believe these are whole disk images. I think the
overcloud and undercloud are root partition images and the kernel an
initrd are composed into the disk for the overcloud by OOO and we direct
boot them to launch a undercloud VM.

Happy to share details if anyone wants more.

Radez



On 01/12/2018 09:59 AM, Jeremy Stanley wrote:
> On 2018-01-12 11:17:33 +0100 (+0100), Marcin Juszkiewicz wrote:
> [...]
>> I am aware that you like to build disk images on your own but have
>> you considered using virt-install with generated preseed/kickstart
>> files? It would move several arch related things (like bootloader)
>> to be handled by distribution rules instead of handling them again
>> in code.
> [...]
>
> We pre-generate and upload images via Glance because it allows us to
> upload the same image to all providers (modulo processor
> architecture in this case obviously). Once we have more than one
> arm64 deployment to integrate, being able to know that we're
> uploading identical images to all of them will be useful from a
> consistency standpoint. Honestly, getting EFI bits into DIB is
> probably no harder than writing a new nodepool builder backend to do
> remote virt-install, and would be of use to a lot more people when
> implemented.
>
> If you look in
> http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/bootloader/finalise.d/50-bootloader
> there's support for setting up ppc64 PReP boot partitions... I don't
> expect getting correct EFI partition creation integrated would be
> much tougher? That said, it's something the DIB maintainers will
> want to weigh in on obviously.
>
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180112/45e24658/attachment.html>