[Starlingx-discuss] [Containers] Not able to boot controller-1 on Duplex installation

[Saul Wold]

Jose,

Can you also talk with Memo as he is looking into this while Mingyuan is 
on break.

Sau!

On 2/7/19 9:30 AM, Perez Carranza, Jose wrote:
> Thanks Bart
> 
> Yes, I have connectivity actually the proxies are set correctly on "/etc/systemd/system/docker.service.d/http-proxy.conf" but seems like are not well recognized by controller-1.
> 
> If I run below commands the URL is reachable. I'll update the Launchpad with this info.
> 
> $ https_proxy=<my_prooxy>  curl  https://kubernetes-charts.storage.googleapis.com
> $ https_proxy=<my_proxy> helm init
> 
> 
> Regards,
> José
> 
> 
>> -----Original Message-----
>> From: Wensley, Barton [mailto:Barton.Wensley at windriver.com]
>> Sent: Thursday, February 7, 2019 11:11 AM
>> To: Perez Carranza, Jose <jose.perez.carranza at intel.com>; starlingx-
>> discuss at lists.starlingx.io
>> Subject: RE: [Starlingx-discuss] [Containers] Not able to boot controller-1 on
>> Duplex installation
>>
>> José,
>>
>> The proxy configuration you supply during config_controller should be
>> propagated to controller-1. If you are sure your controller-1 has connectivity to
>> your proxy, then you will need help from Mingyuan Qi who implemented the
>> proxy support.
>>
>> Bart
>>
>> -----Original Message-----
>> From: Perez Carranza, Jose [mailto:jose.perez.carranza at intel.com]
>> Sent: February 6, 2019 5:21 PM
>> To: starlingx-discuss at lists.starlingx.io
>> Subject: [Starlingx-discuss] [Containers] Not able to boot controller-1 on
>> Duplex installation
>>
>> Hi,
>>
>> I'm installing a Duplex with containers and I'm getting below error when
>> unlocking controller-1 ========
>>
>> | task                | Configuration Failed, re-enabling                                     |
>> | task                | Rebooting                                                             |
>> | task                | Booting                                                               |
>> ...
>> ...
>> ...
>> | 200.011 | controller-1 experienced a configuration failure. |
>> | host=controller-1 | critical | 2019-02-06T13:44:19 | controller
>> ========
>>
>> then  controller tries to boot again until but below failure appears and the
>> controller satays on failure status.
>> ===================
>> | task | Configuration failure, threshold reached, Lock/Unlock to retry
>> | |
>> ======================
>>
>> If I made a lock/unlock cycle I get with the same issues. I was searching on the
>> puppet.log of controller-1 and I found below errors, seems like the repository
>> is not reachable, my question is if I used a proxy on the config_controller those
>> proxies are also propagated to controller-1 when is automatically installed?
>>
>> ====================
>> 2019-02-06T13:52:15.219 Notice: 2019-02-06 13:52:15 +0000
>> /Stage[main]/Platform::Helm/Exec[initialize helm]/returns: Error: Looks like
>> "https://kubernetes-charts.storage.googleapis.com" is not a valid chart
>> repository or cannot be reached: Get https://kubernetes-
>> charts.storage.googleapis.com/index.yaml: dial tcp: lookup kubernetes-
>> charts.storage.googleapis.com on 8.8.4.4:53: read udp 10.10.10.4:52260-
>>> 8.8.4.4:53: i/o timeout =======================
>>
>> I created a Launchpad to track down this behavior
>>
>> https://bugs.launchpad.net/starlingx/+bug/1814968
>>
>> Regards,
>> José
>>
>>
>>
>> _______________________________________________
>> Starlingx-discuss mailing list
>> Starlingx-discuss at lists.starlingx.io
>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
>