s390x is not available as an architecture constraint

[David Lawson]

My impression has been that architecture constraints are at least partially derived from architectures available in streams, which s390x is, but I'm unable to specify it as a constraint:

https://pastebin.canonical.com/190479/

[John A Meinel (jameinel)]

Would it be possible to check that you can reproduce this without Mojo in the mix? I don't know that we have s390x machines to validate this locally, so we'll likely need to work with you directly if we want to make sure any patch that we do actually does work for you.

[David Lawson (deej)]

$ juju deploy ./nova-compute nova-compute-s390x --constraints arch=s390x
Deploying charm "local:xenial/nova-compute-136".
ERROR cannot add application "nova-compute-s390x": invalid constraint value: arch=s390x
valid values are: [amd64 arm64 i386 ppc64el]

Looks like it's still a problem without mojo in play.

[David Lawson (deej)]

That's with juju 2.1, I haven't had a chance to try 2.2.1 as of yet.

[Tim Penhey (thumper)]

Hmm...

https://github.com/juju/juju/blob/juju-2.1.0/dependencies.tsv has juju/utils at

github.com/juju/utils git 9f8aeb9b09e2d8c769be8317ccfa23f7eec62c26 2017-02-15T08:19:00Z

https://github.com/juju/utils/blob/master/arch/arch.go was last modified Sep 2016 to add the s390x.

Reading through the code some more, it appears that there are additional provider constraints. Some providers just don't support some architectures.

Which provider are you using?

[David Lawson (deej)]

The cloud as a whole is using the maas provider, I'm adding the s390x unit via add-machine since there's no s390x support in maas.

[Tim Penhey (thumper)]

Ah... for MAAS, it does checks on the architecture of all the enlisted
machines to get a validation set. So if MAAS doesn't know it has any
s390x architecture, Juju won't let you specify it.

On 06/07/17 16:05, David Lawson wrote:
> The cloud as a whole is using the maas provider, I'm adding the s390x
> unit via add-machine since there's no s390x support in maas.
>

[David Lawson (deej)]

So you need to use the manual provider explicitly, you can't mix in any architecture that maas doesn't support with a maas provided environment? That seems...kind of not great actually. I've got this working but it's reliant on a relatively fragile set of circumstances for a correct deployment, i.e. the s390x node has to be the last thing to deploy and there must be no more deployable machines in maas, I was hoping to use architecture constraints to shore that piece of the deployment up. Are there any other constraints I can apply in this situation? I.e. is it possible to tag a machine added via add-machine perhaps?

[Frank Heimes (fheimes)]

Well, excuse my ignorance, but how can we improve this situation to avoid such fragile workarounds like the one that Dave had to do?
Does this need to be addressed more towards Juju or MAAS?

[Launchpad Janitor (janitor)]

[Expired for juju because there has been no activity for 60 days.]

[Junien F (axino)]

Setting back to Triaged, as far as I can see this is still a valid bug.

[Jamon Camisso (jamon)]

I'm wondering what the status of this is. We're going to be adding s390x support to a cloud soon and would like to be able to specify architecture constraints like we do with arm64 and ppc64el.

[Ian Booth (wallyworld)]

There's been no further work on how arches are handled by the maas provider. Valid arches are restricted to the set of enlisted machines managed by maas. If a manual machine is added to the model, that machine's arch is not added to the allowed set. In general for maas provider, only machines managed by maas are available to be used with arch or tag constraints.

For the use case at hand, a placement directive is perhaps the best we can do at the moment. ie when a manual machine is added, it gets a juju machine id. Then you can do:

$ juju deploy myapp --to 5

Not the same as "pick any free s390 machine" for sure, but maybe good enough for now.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.