<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
fwiw<br>
We've been building arm images for tripleo and posting them.<br>
<a class="moz-txt-link-freetext" href="https://images.rdoproject.org/aarch64/pike/delorean/current-tripleo-rdo/">https://images.rdoproject.org/aarch64/pike/delorean/current-tripleo-rdo/</a><br>
<br>
<br>
This uses delorean and overcloud build:<br>
<br>
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"
\<br>
openstack --debug overcloud image build \<br>
--config-file overcloud-aarch64.yaml \<br>
--config-file
/usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml
\<br>
--config-file
/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos7.yaml<br>
# --config-file overcloud-images.yaml --config-file
overcloud-images-centos7.yaml --config-file aarch64-gumpf.yaml
--image-name<br>
#openstack --debug overcloud image build --type overcloud-full
--node-arch aarch64<br>
<br>
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.<br>
<br>
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.<br>
<br>
Happy to share details if anyone wants more.<br>
<br>
Radez<br>
<br>
<br>
<br>
On 01/12/2018 09:59 AM, Jeremy Stanley wrote:<br>
<blockquote type="cite"
cite="mid:20180112145912.rrmujb4h56oxqzvv@yuggoth.org">
<pre wrap="">On 2018-01-12 11:17:33 +0100 (+0100), Marcin Juszkiewicz wrote:
[...]
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">[...]
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
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/bootloader/finalise.d/50-bootloader">http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/bootloader/finalise.d/50-bootloader</a>
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.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-Infra mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-Infra@lists.openstack.org">OpenStack-Infra@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra</a></pre>
</blockquote>
<br>
</body>
</html>