Open Stack

Hi All,
    As you're all aware we're trying to bring support to tripleo that
enables multiple-architectures in the same tripleo managed/deployed
overcloud.  The first real difference comes to how we handle the ,now,
multiple images required.

To validated that my understanding of the x86_64 only situation is
correct we have the following images:
 - ironic-python-agent.kernel
 - ironic-python-agent.initramfs
 - overcloud-full.vmlinuz
 - overcloud-full.initrd
 - overcloud-full.qcow2

And we'll need each of those to support multiple architectures which
backwards compatibility the list for a 2 architecture cloud would be 
 - {,x86_64-}ironic-python-agent.kernel
 - {,x86_64-}ironic-python-agent.initramfs
 - {,x86_64-}overcloud-full.vmlinuz
 - {,x86_64-}overcloud-full.initrd
 - {,x86_64-}overcloud-full.qcow2
 - ppc64le-ironic-python-agent.kernel
 - ppc64le-ironic-python-agent.initramfs
 - ppc64le-overcloud-full.vmlinuz
 - ppc64le-overcloud-full.initrd
 - ppc64le-overcloud-full.qcow2

All images would be tagged with a hw_architecture, defaulting to x86_64
if not supplied.

So the selection model for any given image target would be:
 1. $arch-imagename
 2. if arch isn't supplied or is x86_64 fall back to plain imagename

And then we'd add logic to tripleo to look at the architecture of the
baremetal node and pick the correct image for deploy/imageing.  There
are a couple of work in progress changes to do this at:
 - https://review.openstack.org/#/q/status:open+topic:bug/173822

We can iterate on those, however a single architecture 'ppc64le' doesn't
always provide adequate differentiation.  For example you may need one
kernel image (and userspace) for POWER8 processors and a different one
for POWER9.  Ideally we'd just use arch but that's invariant :(

I'd like to introduce the concept of a platform which is in many ways a
companion or a fine grained selector for images.  This would be supplied
by the operator in instackenv.json, added as image meta-data as the
image is uploaded and if needed added to the baremetal node as
a capability.  Then the selection model would become:
 1. $arch-imagename with appropriate image meta-data
 1. $arch-imagename
 2. if arch isn't supplied or is x86_64 fall back to plain imagename

How does that sound?

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171219/b52029b6/attachment.sig>