[openstack-dev] [magnum] K8S apiserver key sync

Remo Mattei remo at rm.ht
Thu Jun 21 03:33:32 UTC 2018


Thanks Fei, 
I did post the question on that channel no much noise there though.. I would really like to get this configured since we are pushing for production. 

Thanks 

> On Jun 20, 2018, at 8:27 PM, Fei Long Wang <feilong at catalyst.net.nz> wrote:
> 
> 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 <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 <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 <https://bugs.launchpad.net/magnum/+bug/1766546>
>>>> [2] https://github.com/openstack/magnum/blob/2329cb7fb4d197e49d6c07d37b2f7ec14a11c880/magnum/conductor/handlers/common/cert_manager.py#L59-L64 <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 <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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 <mailto: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 <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 <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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 <mailto: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 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180620/728bcc24/attachment.html>


More information about the OpenStack-dev mailing list