arm* agents cannot call home, but amd64 can

[Curtis Hovey]

On a maas with 3 networks, identical charms can be deployed, one for amd64, arm64, and armhf. The amd64 agents call home and the service is deployed and starts. But the arm* agents are stuck in pending.

The machine logs for arm* contain this
2014-10-02 14:05:04 INFO juju.state.api apiclient.go:242 dialing "wss://tytjp.maas:17070/"
2014-10-02 14:05:04 INFO juju.state.api apiclient.go:250 error dialing "wss://tytjp.maas:17070/": websocket.Dial wss://tytjp.maas:17070/: x509: certificate has expired or is not yet valid

An examination of the working and faled machines revealed that ca-cert.pem was placed in the working virtual node but not on armhf and arm64 bit machines.

Note that there were issue getting this env to see the tools. The proxies are configured to provide access to streams.canonical.com, but tools were not found. sync-tools was run to put all the 1.20.9 tools into the env

[Narinder Gupta (narindergupta)]

cloud output log.

[Sean Feole (sfeole)]

this is currently affecting the hyperscale team, we are unable to use --constraints arch=arm64 / armhf for deploying to specific nodes w juju/maas

[John A Meinel (jameinel)]

The warning in the log file looks actually like
https://bugs.launchpad.net/bugs/1352944

Specifically, it is claiming the certificate is not valid (yet) rather than that it isn't present. It *could* just be a bad error message, but have you checked if the clock is in sync between the machines?

[Kapil Thangavelu (hazmat)]

you might want to try ensuring the arm machines aren't subject to clock
skew, the certs have some time senstivity to them. there's a separate bug
for juju to create the certs with validity in the past to avoid this issue.

On Tue, Nov 11, 2014 at 9:07 AM, Andrew Cloke <email address hidden>
wrote:

> ** Tags added: hs-arm64-maas-juju
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https://bugs.launchpad.net/bugs/1376906
>
> Title:
> arm* agents cannot call home, but amd64 can
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1376906/+subscriptions
>

[Narinder Gupta (narindergupta)]

Kapil this is not a cert blocker but blocking the capability to deploy the workload through juju. I can assure you that there is no clock skew and date and time looks good on the installed system.

[Curtis Hovey (sinzui)]

Can you test 1.21-beta1 or beta2 when it is released. the cert issues were fixes a few weeks ago in the 1.21 version.

If the network issue is still present, please provide the logs from one of the units/machines the charm was deployed to. You can ssh into the machine and get these logs
    /var/log/cloud-init-output.log
    /var/log/juju/machine*.log

[Kapil Thangavelu (hazmat)]

also to be clear the clock skew involves not only the server machines, but
also the juju client machine which generates the cert. I'd suggest giving
1.21 a per curtis's suggestion as it may have a fix for this.

On Thu, Nov 13, 2014 at 7:51 AM, Curtis Hovey <email address hidden> wrote:

> Can you test 1.21-beta1 or beta2 when it is released. the cert issues
> were fixes a few weeks ago in the 1.21 version.
>
> If the network issue is still present, please provide the logs from one of
> the units/machines the charm was deployed to. You can ssh into the machine
> and get these logs
> /var/log/cloud-init-output.log
> /var/log/juju/machine*.log
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https://bugs.launchpad.net/bugs/1376906
>
> Title:
> arm* agents cannot call home, but amd64 can
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1376906/+subscriptions
>

[Launchpad Janitor (janitor)]

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