Open Stack

Hi Remo,

I can't see obvious issue from the log you posted. You can pop up at
#openstack-containers IRC channel as for Magnum questions. Cheers.


On 21/06/18 08:56, Remo Mattei wrote:
> Hello guys, what will be the right channel to as a question about
> having K8 (magnum working with Tripleo)? 
>
> I have the following errors..
>
> http://pastebin.mattei.co/index.php/view/2d1156f1
>
> Any tips are appreciated. 
>
> Thanks 
> Remo 
>
>> On Jun 19, 2018, at 2:13 PM, Fei Long Wang <feilong at catalyst.net.nz
>> <mailto:feilong at catalyst.net.nz>> wrote:
>>
>> Hi there,
>>
>> For people who maybe still interested in this issue. I have proposed
>> a patch, see https://review.openstack.org/576029 And I have verified
>> with Sonobuoy for both multi masters (3 master nodes) and single
>> master clusters, all worked. Any comments will be appreciated. Thanks.
>>
>>
>> On 21/05/18 01:22, Sergey Filatov wrote:
>>> Hi!
>>> I’d like to initiate a discussion about this bug: [1].
>>> To resolve this issue we need to generate a secret cert and pass it
>>> to master nodes. We also need to store it somewhere to support scaling.
>>> This issue is specific for kubernetes drivers. Currently in magnum
>>> we have a general cert manager which is the same for all the drivers.
>>>
>>> What do you think about moving cert_manager logic into a
>>> driver-specific area?
>>> Having this common cert_manager logic forces us to generate client
>>> cert with “admin” and “system:masters” subject & organisation names
>>> [2], 
>>> which is really something that we need only for kubernetes drivers.
>>>
>>> [1] https://bugs.launchpad.net/magnum/+bug/1766546
>>> [2] https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64
>>>
>>>
>>> ..Sergey Filatov
>>>
>>>
>>>
>>>> On 20 Apr 2018, at 20:57, Sergey Filatov <s.s.filatov94 at gmail.com
>>>> <mailto:s.s.filatov94 at gmail.com>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I looked into k8s drivers for magnum I see that each api-server on
>>>> master node generates it’s own service-account-key-file. This
>>>> causes issues with service-accounts authenticating on api-server.
>>>> (In case api-server endpoint moves).
>>>> As far as I understand we should have either all api-server keys
>>>> synced on api-servesr or pre-generate single api-server key.
>>>>
>>>> What is the way for magnum to get over this issue?
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> -- 
>> Cheers & Best regards,
>> Feilong Wang (王飞龙)
>> --------------------------------------------------------------------------
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flwang at catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> -------------------------------------------------------------------------- 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180621/868a0c82/attachment-0001.html>