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 <feil...@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.filato...@gmail.com >>> <mailto:s.s.filato...@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-requ...@lists.openstack.org?subject:unsubscribe >> <mailto:openstack-dev-requ...@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: flw...@catalyst.net.nz <mailto:flw...@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-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev