bootstrap failure on MAAS

We track Juju 2.x issues and concerns in launchpad 'juju" project - re-targeting :D

Since the error is coming from https://github.com/juju/juju/blob/2.0/provider/maas/environ.go#L172, it is possible that download newer version of GUI took longer than the default time we were given MAAS bootstraps in Juju 2.0.x

Pleas try to increase bootstrap timeout [1] or try later version of Juju, say 2.1x or daily snap?

[1] I *think*, it's '--config bootstrap-timeout='. Default value is set to 1200 seconds.

Hello,

Thank you for your reply,

Not sure that changing the timeout will change anything :

sysadmin@vMAAS01:~$ ps -eLf | grep juju
sysadmin 4104 3747 4104 0 7 19:01 pts/0 00:00:00 juju bootstrap maas juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --default-model default --to star-quail --bootstrap-series=xenial --credential admin --debug --config bootstrap-timeout=10000
sysadmin 4104 3747 4105 0 7 19:01 pts/0 00:00:00 juju bootstrap maas juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --default-model default --to star-quail --bootstrap-series=xenial --credential admin --debug --config bootstrap-timeout=10000
sysadmin 4104 3747 4106 0 7 19:01 pts/0 00:00:00 juju bootstrap maas juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --default-model default --to star-quail --bootstrap-series=xenial --credential admin --debug --config bootstrap-timeout=10000
sysadmin 4104 3747 4107 0 7 19:01 pts/0 00:00:00 juju bootstrap maas juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --default-model default --to star-quail --bootstrap-series=xenial --credential admin --debug --config bootstrap-timeout=10000
sysadmin 4104 3747 4108 0 7 19:01 pts/0 00:00:00 juju bootstrap maas juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --default-model default --to star-quail --bootstrap-series=xenial --credential admin --debug --config bootstrap-timeout=10000
sysadmin 4104 3747 4109 2 7 19:01 pts/0 00:00:00 juju bootstrap maas juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --default-model default --to star-quail --bootstrap-series=xenial --credential admin --debug --config bootstrap-timeout=10000
sysadmin 4104 3747 4110 0 7 19:01 pts/0 00:00:00 juju bootstrap maas juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --default-model default --to star-quail --bootstrap-series=xenial --credential admin --debug --config bootstrap-timeout=10000
sysadmin 4216 3838 4216 0 1 19:02 pts/1 00:00:00 grep --color=auto juju

sysadmin@vMAAS01:~$ sudo strace -p 4104
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.100.10")}, 16) = -1 EINPROGRESS (Operation now in progress)
epoll_ctl(4, EPOLL_CTL_ADD, 3, {EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, {u32=1933115328, u64=139644204810176}}) = 0
futex(0x3e533e8, FUTEX_WAIT, 0, NULL) = 0
epoll_wait(4, [], 128, 0) = 0
futex(0x3e533e8, FUTEX_WAIT, 0, NULL) = 0
epoll_wait(4, [], 128, 0) = 0
epoll_wait(4, [{EPOLLOUT, {u32=1933115328, u64=139644204810176}}], 128, -1) = 1
futex(0x3e52830, FUTEX_WAKE, 1) = 1
futex(0x3e52770, FUTEX_WAKE, 1) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(50944), sin_addr=inet_addr("192.168.100.10")}, [16]) = 0
getpeername(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.100.10")}, [16]) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
futex(0xc820029108, FUTEX_WAKE, 1) = 1
write(3, "GET /MAAS/api/2.0/machines/...

We can eliminate possibility that this failure is related to GUI 2.5 as we continuously and successfully bootstrap with it during our development cycle.

Have you tried later Juju? after 2.0.x?

Also what version of MAAS are you using?

Hello,

Thanks for your reply

Juju Version 2.0.2-xenial-amd64

MAAS Version 2.1.3+bzr5573-0ubuntu1 (16.04.1)

bothe of them provided by the stable Ubuntu channel I guess

I am confused because it seems so easy to deploy an openstack with that procedure:
https://www.ubuntu.com/download/cloud/autopilot

But I am either stuck with juju or conjure-up

tcpdump doe not show any failed connection no retry
logs show the following :
19:01:43 INFO cmd cmd.go:129 Fetching Juju GUI 2.5.0
21:48:15 INFO juju.provider.common destroy.go:20 destroying model "controller"

almost 3 hours between the command Fetching JUJU and the time out

Perhaps there are more detailed logs linked with the fetching process. But I do not know where to look for them.

Do you have any suggestions ?

TY again.

Yes :D please try later version of Juju.

Did it ^^

2.1.2-xenial-amd64

enable-os-upgrade:false image-stream:daily apt-https-proxy: apt-mirror: net-bond-reconfigure-delay:17 logging-config: resource-tags: development:false logforward-enabled:false ssl-hostname-verification:true automatically-retry-hooks:true name:controller image-metadata-url: type:maas http-proxy: ignore-machine-addresses:false enable-os-refresh-update:true disable-network-management:false no-proxy: default-series:xenial ftp-proxy: transmit-vendor-metrics:true provisioner-harvest-mode:destroyed]
22:28:05 DEBUG juju.provider.maas environprovider.go:51 opening model "controller".
22:28:05 INFO cmd cmd.go:129 Creating Juju controller "juju-ctrl" on maas
22:28:05 INFO juju.cmd.juju.commands bootstrap.go:526 combined bootstrap constraints:
22:28:05 DEBUG juju.environs.bootstrap bootstrap.go:199 model "controller" supports service/machine networks: true
22:28:05 DEBUG juju.environs.bootstrap bootstrap.go:201 network management by juju enabled: true
22:28:05 INFO cmd cmd.go:141 Loading image metadata
22:28:05 INFO cmd cmd.go:129 Looking for packaged Juju agent version 2.1.2 for amd64
22:28:05 INFO juju.environs.bootstrap tools.go:72 looking for bootstrap agent binaries: version=2.1.2
22:28:05 INFO juju.environs.tools tools.go:101 finding agent binaries in stream "released"
22:28:05 INFO juju.environs.tools tools.go:103 reading agent binaries with major.minor version 2.1
22:28:05 INFO juju.environs.tools tools.go:111 filtering agent binaries by version: 2.1.2
22:28:05 INFO juju.environs.tools tools.go:114 filtering agent binaries by series: xenial
22:28:05 INFO juju.environs.tools tools.go:117 filtering agent binaries by architecture: amd64
22:28:05 DEBUG juju.environs.tools urls.go:109 trying datasource "keystone catalog"
22:28:05 DEBUG juju.environs.simplestreams simplestreams.go:680 using default candidate for content id "com.ubuntu.juju:released:tools" are {20161007 mirrors:1.0 content-download streams/v1/cpc-mirrors.sjson []}
22:28:06 INFO juju.environs.bootstrap tools.go:74 found 1 packaged agent binaries
22:28:06 INFO cmd cmd.go:141 Starting new instance for initial controller
Launching controller instance(s) on maas...
22:28:06 DEBUG juju.cloudconfig.instancecfg instancecfg.go:781 Setting numa ctl preference to false
22:28:06 DEBUG juju.service discovery.go:63 discovered init system "systemd" from series "xenial"
22:28:06 DEBUG juju.provider.maas environ.go:1001 maas user data; 2024 bytes
22:28:07 DEBUG juju.provider.maas environ.go:1033 started instance "p4cawt"
 - p4cawt (arch=amd64 mem=3.8G cores=1)
22:28:07 INFO juju.environs.bootstrap bootstrap.go:601 newest version: 2.1.2
22:28:07 INFO juju.environs.bootstrap bootstrap.go:616 picked bootstrap tools version: 2.1.2
22:28:07 INFO juju.environs.bootstrap bootstrap.go:393 Installing Juju agent on bootstrap instance
22:28:08 INFO cmd cmd.go:129 Fetching Juju GUI 2.5.0
...

No change. it is still stuck at the same step, Where does it fetch JUJU GUI ? I am thinking about a network problem but I do not understand why.

If I cancel the provisionning, I get the following :

22:44:39 INFO juju.provider.common destroy.go:20 destroying model "controller"...

GUI is always retrieved from https://streams.canonical.com/juju/gui/gui/
This location is not configurable.

@fab an ice (fabanice),
Is it possible for you to re-run with Trace logging enabled? We might be missing something at debug level and up.

Something like will gives us more insight in what is happening... `JUJU_LOGGING_CONFIG="<root>=TRACE" juju bootstrap ...`

Hi, usefull logging option, TY.

the trace shows that the following request is looping

10:05:55 TRACE maas controller.go:792 request 15: GET http://192.168.100.10/MAAS/api/2.0/machines/?agent_name=1f62be4e-359b-470a-866f-f73066466d69&id=p4cawt
10:05:56 TRACE maas controller.go:800 response 15: [
    {
        "system_id": "p4cawt",
        "distro_series": "xenial",
        "power_type": "manual",
        "status": 9,
        "storage": 21474.83648,
        "netboot": true,
        "status_action": "start",
        "resource_uri": "/MAAS/api/2.0/machines/p4cawt/",
        "owner": "maasadmin",
        "memory": 3934,
        "interface_set": [
            {
                "system_id": "p4cawt",
                "effective_mtu": 1500,
                "discovered": [],
                "parents": [],
                "enabled": true,
                "vlan": {
                    "mtu": 1500,
                    "external_dhcp": null,
                    "id": 5001,
                    "fabric_id": 0,
                    "fabric": "myfabric",
                    "primary_rack": "x6smkq",
                    "vid": 0,
                    "secondary_rack": null,
                    "dhcp_on": true,
                    "resource_uri": "/MAAS/api/2.0/vlans/5001/",
                    "name": "untagged"
                },
                "type": "physical",
                "children": [],
                "id": 13,
                "resource_uri": "/MAAS/api/2.0/nodes/p4cawt/interfaces/13/",
                "tags": [],
                "params": "",
                "mac_address": "00:0c:29:11:2a:35",
                "links": [
                    {
                        "mode": "auto",
                        "subnet": {
                            "rdns_mode": 2,
                            "active_discovery": false,
                            "gateway_ip": "172.16.100.10",
                            "dns_servers": [
                                "8.8.8.8"
                            ],
                            "id": 12,
                            "cidr": "172.16.100.0/24",
                            "vlan": {
                                "mtu": 1500,
                                "external_dhcp": null,
                                "id": 5001,
                                "fabric_id": 0,
                                "fabric": "myfabric",
                                "primary_rack": "x6smkq",
                                "vid": 0,
                                "secondary_rack": null,
                                "dhcp_on": true,
                                "resource_uri": "/MAAS/api/2.0/vlans/5001/",
                                "name": "untagged"
                            },
                            "allow_proxy": true,
                            "space": "space-0",
                            "resource_uri": "/MAAS/api/2.0/subnets/12/",
                            "name": "172.16.100.0/24"
                        },
                        "id": 376,
                        "ip_address": "172.16.100.1"
                    }
                ],
                "name": "ens33"
            }
        ],
    ...

Update:

juju ends with the following output :

11:44:32 TRACE maas controller.go:733 request 203: POST http://192.168.100.10/MAAS/api/2.0/machines/?op=release, params=comment=Released+by+Juju+MAAS+provider&machines=p4cawt
11:44:32 TRACE maas controller.go:741 response 203: [
    "p4cawt"
]
11:44:32 TRACE maas controller.go:792 request 204: GET http://192.168.100.10/MAAS/api/2.0/files/42670847-c843-4042-8aa0-d9f17b5d7ce9-provider-state/
11:44:32 TRACE maas controller.go:796 response 204: error: "ServerError: 404 NOT FOUND (Not Found)"
11:44:32 TRACE maas controller.go:797 error detail: &errors.Err{message:"", cause:gomaasapi.ServerError{error:(*errors.Err)(0xc8205a13b0), StatusCode:404, Header:http.Header{"Server":[]string{"TwistedWeb/16.0.0"}, "Content-Type":[]string{"text/html; charset=utf-8"}, "Workaround":[]string{"bug1123986"}, "Date":[]string{"Thu, 13 Apr 2017 09:44:32 GMT"}, "X-Frame-Options":[]string{"SAMEORIGIN"}, "Vary":[]string{"Authorization,Cookie"}, "X-Maas-Api-Hash":[]string{"f5352e2e0cfa06fc9fe5bb5e62f78509962dbeea"}}, BodyMessage:"Not Found"}, previous:gomaasapi.ServerError{error:(*errors.Err)(0xc8205a13b0), StatusCode:404, Header:http.Header{"X-Maas-Api-Hash":[]string{"f5352e2e0cfa06fc9fe5bb5e62f78509962dbeea"}, "Date":[]string{"Thu, 13 Apr 2017 09:44:32 GMT"}, "X-Frame-Options":[]string{"SAMEORIGIN"}, "Vary":[]string{"Authorization,Cookie"}, "Server":[]string{"TwistedWeb/16.0.0"}, "Content-Type":[]string{"text/html; charset=utf-8"}, "Workaround":[]string{"bug1123986"}}, BodyMessage:"Not Found"}, file:"github.com/juju/gomaasapi/client.go", line:123}
11:44:32 INFO juju.provider.common destroy.go:51 destroying storage
11:44:32 TRACE maas controller.go:792 request 205: GET http://192.168.100.10/MAAS/api/2.0/files/?prefix=42670847-c843-4042-8aa0-d9f17b5d7ce9-
11:44:32 TRACE maas controller.go:800 response 205: []
11:44:32 ERROR cmd supercommand.go:458 failed to bootstrap model: bootstrap instance started but did not change to Deployed state: instance "p4cawt" is started but not deployed
11:44:32 DEBUG cmd supercommand.go:459 (error details: [{github.com/juju/juju/cmd/juju/commands/bootstrap.go:574: failed to bootstrap model} {github.com/juju/juju/provider/maas/environ.go:173: bootstrap instance started but did not change to Deployed state} {github.com/juju/juju/provider/maas/environ.go:1176: instance "p4cawt" is started but not deployed}])

Hello Anastasia,

As long as I am trying to configure a "Private Cloud" based on openstack in 2 differents environnements :

@home with a macbook and VMware fusion installed on it
@work with ESXi 6.5 running on Proliant servers

I had differents problem on both environnments. But now I have the same on both environnment also :

JUJU_LOGGING_CONFIG="<root>=TRACE" juju bootstrap myMAAS juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --bootstrap-series=xenial --credential maasadmin --config=.local/share/juju/config.yaml
Creating Juju controller "juju-ctrl" on myMAAS
Looking for packaged Juju agent version 2.1.2 for amd64
Launching controller instance(s) on myMAAS...
 - rsyeba (arch=amd64 mem=4G cores=4)
Fetching Juju GUI 2.5.2

07:13:33 TRACE maas controller.go:792 request 17: GET http://10.137.184.211/MAAS/api/2.0/machines/?agent_name=f6f10634-bab1-40ca-850d-d8031e736d11&id=rsyeba
07:13:33 TRACE maas controller.go:800 response 17: [
    {
        "status": 9,
        "blockdevice_set": [
            {
                "resource_uri": "/MAAS/api/2.0/nodes/rsyeba/blockdevices/5/",
                "partition_table_type": "MBR",
                "model": "Virtual disk",
                "path": "/dev/disk/by-dname/sda",
                "name": "sda",
                "size": 21474836480,
                "partitions": [
                    {
                        "device_id": 5,
                        "resource_uri": "/MAAS/api/2.0/nodes/rsyeba/blockdevices/5/partition/6",
                        "id": 6,
                        "path": "/dev/disk/by-dname/sda-part1",
                        "size": 21466447872,
                        "filesystem": {
                            "mount_point": "/",
                            "fstype": "ext4",
                            "uuid": "e58f8cad-ec34-406f-bed1-3b3908713cbb",
                            "label": "root",
                            "mount_options": null
                        },
...

I am still continuing to understand what is wrong ^^

Hello,

May be, I forgot to tell you about the Network Configuration in MAAS :
The use of an APT and HTTP/HTTPS proxy Provision nodes to use the built-in HTTP proxy (or user specified proxy) for APT. MAAS also uses the proxy for downloading boot images is enableded
http://user:password@192.168.168.5:10080

From the managed host :

ubuntu@needed-bison:~$ export http_proxy="http://user:password@192.168.168.5:10080"
ubuntu@needed-bison:~$ export https_proxy="http://user:password@192.168.168.5:10080"
ubuntu@needed-bison:~$ wget jujucharms.com --no-check-certificate
--2017-05-03 08:44:24-- http://jujucharms.com/
Connecting to 192.168.168.5:10080... connected.
Proxy request sent, awaiting response... 302 Found
Location: https://jujucharms.com/ [following]
--2017-05-03 08:44:26-- https://jujucharms.com/
Connecting to 192.168.168.5:10080... connected.
WARNING: cannot verify jujucharms.com's certificate, issued by ‘emailAddress=me.com,CN=myproxy,OU=myou,O=myo,L=myloc,ST=myst,C=myc’:
  Unable to locally verify the issuer's authority.
Proxy request sent, awaiting response... 200 OK

On maas server it is still looping on the following steps until it is timed out:

04:47:46 TRACE maas controller.go:792 request 78: GET http://10.137.184.211/MAAS/api/2.0/machines/?agent_name=de797dc2-a8d6-48c1-8716-fc932bcc926b&id=ya7dwr
04:47:46 TRACE maas controller.go:800 response 78: ...

If it helps you.

Thank you

08:36:16 TRACE juju.environs.simplestreams simplestreams.go:487 fetchData failed for "https://streams.canonical.com/juju/gui/streams/v1/index2.sjson": cannot find URL "https://streams.canonical.com/juju/gui/streams/v1/index2.sjson" not found
08:36:16 TRACE juju.environs.simplestreams simplestreams.go:433 looking for data index using URL https://streams.canonical.com/juju/gui/streams/v1/index2.sjson
08:36:16 TRACE juju.environs.simplestreams simplestreams.go:436 streams/v1/index2.sjson not accessed, actual error: invalid URL "https://streams.canonical.com/juju/gui/streams/v1/index2.sjson" not found
08:36:16 TRACE juju.environs.simplestreams simplestreams.go:437 streams/v1/index2.sjson not accessed, trying legacy index path: streams/v1/index.sjson
08:36:16 TRACE juju.environs.simplestreams simplestreams.go:487 fetchData failed for "https://streams.canonical.com/juju/gui/streams/v1/mirrors.sjson": cannot find URL "https://streams.canonical.com/juju/gui/streams/v1/mirrors.sjson" not found

sysadmin@MAAS:~$ wget https://streams.canonical.com/juju/gui/streams/v1/index2.sjson
--2017-05-03 08:42:25-- https://streams.canonical.com/juju/gui/streams/v1/index2.sjson
Connecting to 192.168.168.5:10080... connected.
Proxy request sent, awaiting response... 404 Not Found
2017-05-03 08:42:26 ERROR 404: Not Found.

If it can't find index2.json it should then fall back to index.json which
does remove:
https://streams.canonical.com/juju/gui/streams/v1/index.json
Which is listed as 'trying legacy' above, which looks like it did succeed.
We shouldn't need mirrors.sjson, which is why I imagine it is giving the
failure only at TRACE level because it is one that we can recover from.

If you need to set APT proxies and plain HTTP proxies then you also need to
set those for Juju and not just for MAAS. We don't use the APT proxy for
regular HTTP because often they are actually enabled differently (many apt
caching proxies *refuse* regular http traffic, etc.)

You can set them in clouds.yaml with something like:
clouds:
  mymaas:
    type: maas
    auth-types: [oauth1]
    endpoint: http://<hostname>/MAAS
    config:
      apt-http-proxy: http://10.0.0.1:3142
      apt-https-proxy: http://10.0.0.1:3142
      http-proxy:...
      https-proxy:...

You can also use:
  juju bootstrap --no-gui
If you don't want to download the Javascript GUI.

On Wed, May 3, 2017 at 8:43 AM, fab an ice <email address hidden>
wrote:

> 08:36:16 TRACE juju.environs.simplestreams simplestreams.go:487 fetchData
> failed for "https://streams.canonical.com/juju/gui/streams/v1/index2.sjson":
> cannot find URL "https://streams.canonical.com/juju/gui/streams/v1/
> index2.sjson" not found
> 08:36:16 TRACE juju.environs.simplestreams simplestreams.go:433 looking
> for data index using URL https://streams.canonical.com/
> juju/gui/streams/v1/index2.sjson
> 08:36:16 TRACE juju.environs.simplestreams simplestreams.go:436
> streams/v1/index2.sjson not accessed, actual error: invalid URL "
> https://streams.canonical.com/juju/gui/streams/v1/index2.sjson" not found
> 08:36:16 TRACE juju.environs.simplestreams simplestreams.go:437
> streams/v1/index2.sjson not accessed, trying legacy index path:
> streams/v1/index.sjson
> 08:36:16 TRACE juju.environs.simplestreams simplestreams.go:487 fetchData
> failed for "https://streams.canonical.com/juju/gui/streams/v1/
> mirrors.sjson": cannot find URL "https://streams.canonical.
> com/juju/gui/streams/v1/mirrors.sjson" not found
>
>
> sysadmin@MAAS:~$ wget https://streams.canonical.com/
> juju/gui/streams/v1/index2.sjson
> --2017-05-03 08:42:25-- https://streams.canonical.com/
> juju/gui/streams/v1/index2.sjson
> Connecting to 192.168.168.5:10080... connected.
> Proxy request sent, awaiting response... 404 Not Found
> 2017-05-03 08:42:26 ERROR 404: Not Found.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1681278
>
> Title:
> bootstrap failure on MAAS
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1681278/+subscriptions
>

Experiencing the same problem today. What's the solution or workaroud?

MAAS Version 2.1.3+bzr5573-0ubuntu1 (16.04.1)
Juju version: 2.0.2-xenial-amd64

MAAS yaml when creating the maas cloud:

clouds:
  devmaas:
    type: maas
    auth-types: [oauth1]
    endpoint: http://192.168.8.1/MAAS
    default-series: centos7

192.168.8.1 is the MAAS server. I can view maas gui fine.

192.168.8.1 has two interfaces, one is serving baremetals (8.1), the other connects to internet. UFW is installed to allow routing so all baremetal nodes have access to internet once provisioned.

This setup has worked since 1/2017. Juju is stock from apt get. What is the solution for this problem?

Hello,

I tried again with your suggestion, I still get the same issue : looping at the same step :
05:41:42 TRACE maas controller.go:792 request 53: GET http://10.137.184.211/MAAS/api/2.0/machines/?agent_name=824e56ea-dad0-42c2-843b-bfe587df3bbb&id=ya7dwr

MAAS Version 2.1.5+bzr5596-0ubuntu1 (16.04.1)
juju version 2.1.2-xenial-amd64

#cat clouds.yaml
clouds:
  myMAAS:
    type: maas
    auth-types: [oauth1]
    endpoint: "http://10.137.184.211/MAAS"
    config:
      apt-http-proxy: "http://xxxx:yyyy@192.168.168.5:10080"
      apt-https-proxy: "http://xxxx:yyyy@192.168.168.5:10080"
      http-proxy: "http://xxxx:yyyy@192.168.168.5:10080"
      https-proxy: "http://xxxx:yyyy@192.168.168.5:10080"

JUJU_LOGGING_CONFIG="<root>=TRACE" juju bootstrap myMAAS juju-ctrl --config image-stream=daily --config enable-os-upgrade=false --bootstrap-series=xenial --credential maasadmin --config=~/.local/share/juju/config.yaml --debug --no-gui

Here is the output

05:30:52 TRACE maas controller.go:792 request 12: GET http://10.137.184.211/MAAS/api/2.0/machines/?agent_name=824e56ea-dad0-42c2-843b-bfe587df3bbb&id=ya7dwr
05:30:52 TRACE maas controller.go:800 response 12: [
    {
        "system_id": "ya7dwr",
        "owner_data": {
            "juju-model-uuid": "824e56ea-dad0-42c2-843b-bfe587df3bbb",
            "juju-is-controller": "true",
            "juju-controller-uuid": "c91b0e53-4605-41b5-8e17-f82641f0d25a"
        },
        "power_state": "unknown",
        "interface_set": [
            {
                "enabled": true,
                "system_id": "ya7dwr",
                "discovered": [],
                "params": "",
                "type": "physical",
                "resource_uri": "/MAAS/api/2.0/nodes/ya7dwr/interfaces/16/",
                "name": "ens160",
                "children": [],
                "id": 16,
                "tags": [],
                "vlan": {
                    "fabric": "fabric-0",
                    "dhcp_on": true,
                    "id": 5001,
                    "resource_uri": "/MAAS/api/2.0/vlans/5001/",
                    "vid": 0,
                    "secondary_rack": null,
                    "fabric_id": 0,
                    "mtu": 1500,
                    "external_dhcp": null,
                    "name": "untagged",
                    "primary_rack": "f8q7as"
                },
                "parents": [],
                "links": [
                    {
                        "mode": "auto",
                        "id": 113,
                        "ip_address": "192.168.168.251",
                        "subnet": {
                            "allow_proxy": true,
                            "space": "space-0",
                            "name": "192.168.168.0/24",
                            "dns_servers": [
                                "8.8.8.8"
                            ],
                            "vlan": {
                                "fabric": "fabric-0",
                                "dhcp_on": true,
                                "id": 5001,
                                "resource_uri": "/MAAS/api/2.0/vlans/5001/",
                                "vid": 0,
        ...

You mentioned your YAML for configuring MAAS, but you don't have an http-proxy set in that configuration.

It isn't quite clear what you mean by 'looping at the same step', is the issue that we are requesting a machine from MAAS, and MAAS is responding with a machine that it claims will be started, but that machine is actually failing to start?

Are you able to use the MAAS GUI to actually provision a machine directly (Acquire Node)?

It sounds like you do a have an HTTP Proxy, so its possible you have to configure the Apt HTTP Proxy in MAAS.

In both cases the MAAS Response has this line:
        "status": 9,
Which looking at MAAS source I find:
    #: The node is being installed.
    DEPLOYING = 9
    #: The node has been allocated to a user and is ready for deployment.
    ALLOCATED = 10

That means that MAAS is trying to create and initialize the machine, but it never gets to 'status: ALLOCATED' which is the point where maas has a functioning machine and has handed off control of that machine to Juju for us to start configuring the machine.

To debug the MAAS failures will probably require interacting with the MAAS team. The first step would be to make sure you can Allocate a machine (such that it gets all the way to where you can SSH in as the 'ubuntu' user).

(including maas because it seems the node is failing to progress from DEPLOYING to ALLOCATED, which is preventing Juju from doing any more setup on that node to configure a Juju controller.)

It would also be ideal that you test deploying a machine *without* Juju at first, to determine whether this is a MAAS bug or not.

Also, it would be ideal if you attach the contents of:

/var/log/maas/*.log
Installation log (you can grab this in the UI).

No http-proxy ? Please tell me what do you mean by no http-proxy set because it seems that http-proxy is set in my configuration

#cat clouds.yaml
...
config:
...
      http-proxy: "http://xxxx:yyyy@192.168.168.5:10080"
      https-proxy: "http://xxxx:yyyy@192.168.168.5:10080"
...

MAAS:~/.local/share/juju$ env | grep proxy | sed 's|Whatever|xxxx:yyyy|'
apt_http_proxy=http://xxxx:yyyy@192.168.168.5:10080
http_proxy=http://xxxx:yyyy@192.168.168.5:10080
apt_https_proxy=http://xxxx:yyyy@192.168.168.5:10080
https_proxy=http://xxxx:yyyy@192.168.168.5:10080
no_proxy=localhost,127.0.0.1,10.137.184.211,hostname,*.hostname.local

wget google.fr
--2017-05-23 09:37:00-- http://google.fr/
Connecting to 192.168.168.5:10080... connected.
Proxy request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.fr/ [following]
--2017-05-23 09:37:03-- http://www.google.fr/
Reusing existing connection to 192.168.168.5:10080.
Proxy request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html [ <=> ] 11.54K --.-KB/s in 0.02s

2017-05-23 09:37:04 (691 KB/s) - ‘index.html’ saved [11820]

The machine is started and you can access to internet from this machine:

ubuntu@needed-bison:~$ uptime
 14:29:52 up 20 days, 6:14, 1 user, load average: 0.00, 0.00, 0.00
ubuntu@needed-bison:~$ export http_proxy="http://xxxx:yyyy@192.168.168.5:10080"
ubuntu@needed-bison:~$ export https_proxy="http://xxxx:yyyy@192.168.168.5:10080"
ubuntu@needed-bison:~$ wget jujucharms.com --no-check-certificate
--2017-05-23 14:27:50-- http://jujucharms.com/
Connecting to 192.168.168.5:10080... connected.
Proxy request sent, awaiting response... 302 Found
Location: https://jujucharms.com/ [following]
--2017-05-23 14:27:55-- https://jujucharms.com/
Connecting to 192.168.168.5:10080... connected.
WARNING: cannot verify jujucharms.com's certificate, issued by ‘ZZZZZZ’:
  Unable to locally verify the issuer's authority.
Proxy request sent, awaiting response... 200 OK
Length: 45039 (44K) [text/html]
Saving to: ‘index.html

The problem is not related to an internet access

Sorry, I saw https://bugs.launchpad.net/juju/+bug/1681278/comments/16 but missed that you had posted an updated YAML in 17.

Is there an issue related to validating SSL certificates on the started machine?

Is there a 192.168 address that should be added to no proxy? I'm not sure where the 10.137... address came from.

It's possible some configuration that juju is requesting from MAAS is causing the machine not to start. I believe the contents of the post request should be in the MAAS log files that Andres mentioned.

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

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