From ildiko at openstack.org Wed Jan 2 19:03:01 2019 From: ildiko at openstack.org (Ildiko Vancsa) Date: Wed, 2 Jan 2019 20:03:01 +0100 Subject: [Edge-computing] Meeting reminder Message-ID: <1113616A-4D03-425F-A57E-C3D61F44E834@openstack.org> Hi, It is a friendly reminder that this week we have the APAC-friendly time slot for the weekly calls: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings See you on the call tomorrow! Thanks and Best Regards, Ildikó From ildiko at openstack.org Mon Jan 7 06:28:40 2019 From: ildiko at openstack.org (Ildiko Vancsa) Date: Mon, 7 Jan 2019 07:28:40 +0100 Subject: [Edge-computing] Weekly call tomorrow in the US/Europe friendly slot Message-ID: Hi, It is a friendly reminder that we have the next weekly call tomorrow at 7am Pacific / 1500 UTC. Please find the meeting details here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings The calendar file is available from this link: https://www.openstack.org/assets/edge/OSF-Edge-Computing-Group-Weekly-Calls.ics Please let me know if you have any questions. Thanks and Best Regards, Ildikó From gergely.csatari at nokia.com Mon Jan 7 15:23:23 2019 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Mon, 7 Jan 2019 15:23:23 +0000 Subject: [Edge-computing] Status of Keystone federation testing with tempest In-Reply-To: References: , , Message-ID: Hi, Just to send a signal, that I'm still working on this (with best effort). What I could figure out in the last some months, is that we need a "verify=False" parameter in the session.post of send_identity_provider_authn_request (in saml2_client.py) to be able to connect to the IdP using self signed certificates. Now I'm able to communicate with the IdP and I can see, that there is a problem with the IdP config. This is the log of Shibboleth: 2019-01-07 11:33:55,165 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/ecp is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID http://127.0.0.1/shibboleth) 2019-01-07 11:33:55,167 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration I keep debugging this and update you about the results. Would it help if I would push all modified things to GitHub with a description how am I doing the configuration? Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Saturday, September 15, 2018 12:36 AM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Re: Status of Keystone federation testing with tempest Hi, Some update on the open issues: - Make this work 😉: Okay, I realized, that I use the wrong certificate in the Idp. Based on the IdP-s description I should generate a p12 certificate using the certificate and the key used by the Shibboleth Sp. When I try to generate the certificate I get a strange error: openssl pkcs12 -inkey /etc/shibboleth/sp-key.pem -in /etc/shibboleth/sp-cert.pem -out ../keystone-shibboleth-idp-dockerized/shibboleth-idp/credentials/idp-browser.p12 139822780584384:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1129: 139822780584384:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:289:Type=PKCS12 Google tells me that this is becouse one of my pem files are in the wrong format. This is really strange as the error persist even after I regenerated these files with shib-keygen -f -y 1 - Figure out how to start a Container in a Keystone plugin or a tempest plugin - no progress on this - Figure out ow to integrate with CI - no progress on this - Figure out how to use static certificates and keys, so the same IdP container image can be used. If you are bigger fans of IRC than email I can start sending these updates to the keystone channel. Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, September 12, 2018 11:25:32 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Re: Status of Keystone federation testing with tempest Hi, Some update on the open issues. - Make this work 😉 - here I have some progress, however I can not explain why. Now keystone is able to reach Shibboleth and Shibboleth answers with FatalProfileException "A valid authentication statement was not found in the incoming message.". I continue to figure out what is the problem. - Set the idp address in the correct place - This is done thanks to gmann. - Figure out how to start a Container in a Keystone plugin or a tempest plugin - Here I try to use https://github.com/openstack/devstack-plugin-container however I'm not sure if this is the right tool to start containers in DevStack environment. - Figure out ow to integrate with CI - no progress on this I'm still happy get any help either in mail, IRC or in person on the PTG. Thanks, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, August 31, 2018 1:03:43 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Status of Keystone federation testing with tempest Hi, I'm working on this for a while, but as I am not a big expert of IdP, Keysone or Tempest I have a bit slow progress. I decided to share what I did and what are my current probelms to 1) inform the team about the progress 2) keep a record for myself 3) hoping for help and/or hints. So I did this: 1) Get an Ubuntu 2) Install devstack with enable_plugin keystone git://git.openstack.org/openstack/keystone enable_service keystone-saml2-federation Here I already ran into some package maangement issues due to some libcurl3 and libcurl4 incompatibility issue what I solved using https://launchpad.net/~xapienz/+archive/ubuntu/curl34 3) Install the Keystone tempest plugin 4) Build a Shibboleth IdP container based on https://github.com/Unicon/shibboleth-idp-dockerized with the configuration I believe is correct. I have a feeling that we will need to set a proper organisation for this if we want to publish this to Docker Hub. By the way is there a container registry maintained in the OpenStack development infra? 5) Run the container and expose 8080, 4443 and 8443 ports This is a half success. Shibboleth contacts Keystone (or actually the Shibboleth apache module) for metadata update, but it works only on the first attempt. The regular updates are not working for some reason. Also I was not able to get a positive answer from the status script of Shibboleth itself, so i just decided to move a bit forward. 6) Set idp_url to https://localhost:8080/idp/profile/SAML2/SOAP/ECP in _request_unscoped_token inside the Keystone tempest plugin. Here I have no idea where the configuration is actually stores and where should I set this in a nice way. 7) Run the tempest tests. Now here I get an error message which tells me about SSL version numbers (hands.hake: Error([('SSL routines', 'ssl3_get_record', 'wrong version number')],)",),))). I tried to use different ssl versions with Curl, but it complains about the lack of support in libsso. So here I am now. Things what I deffinetly should figure out: - Make this work 😉 - Set the idp address in the correct place - Figure out how to start a Container in a Keystone plugin or a tempest plugin - Figure out ow to integrate with CI Any comments are welcome. Br, Gerg0 Curl 3 and 4 : Evgeny Brazgin - launchpad.net launchpad.net PPA contains libcurl4 package, which supports both libcurl3 and libcurl4 API. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Tue Jan 8 15:57:28 2019 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 8 Jan 2019 15:57:28 +0000 Subject: [Edge-computing] Weekly meeting minutes Message-ID: is here: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2019/weekly_edge_computing_group_call.2019-01-08-14.59.html Br, Geg0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhaoqihui at chinamobile.com Wed Jan 9 09:36:20 2019 From: zhaoqihui at chinamobile.com (zhaoqihui at chinamobile.com) Date: Wed, 9 Jan 2019 17:36:20 +0800 Subject: [Edge-computing] [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting References: <1569231DC06A0846.23762@lists.opnfv.org>, <201811271147449384076@chinamobile.com>, <156F3B766B549CBF.21862@lists.opnfv.org>, <2018121117145221586888@chinamobile.com>, <2018121220212661606146@chinamobile.com>, <2018122514385416054410@chinamobile.com>, <201812260905336684741@chinamobile.com>, <2019010909291507376211@chinamobile.com>, , <2019010917064767623860@chinamobile.com>, Message-ID: <2019010917361973987684@chinamobile.com> Yes, I think we should try that. When I was doing the edge Pharos Spec, which is a draft for now, I definitely consulted the whitepaper, but was trying to do as less modification about the original Pharos spec as possible. Because I thought a test environment could not actually follow the real environment. And edge pharos spec is only one possible scenario that could be picked from edge site definitions. I'll see how to modify it and we can discuss in the following edge cloud meetings. Best, Qihui China Mobile Research Institute (+86) 13810659120 From: Gergely Csatari Date: 2019-01-09 17:13 To: zhaoqihui at chinamobile.com; fuqiao; beth.cohen; Peret, Adrian (Nokia - FI/Espoo); julienjut; haojingbo; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; Tikkanen, Viktor (Nokia - FI/Espoo); simple_hlw; kailun.qin; mark.beierl; Manuel Buil CC: opnfv-tech-discuss; opnfv-tsc; edge-computing Subject: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Hi, Thanks for the links. I still think, that we should keep the Edge Pharos Specs [1] and the Edge Cloud Site definitions [2] in the whitepaper consistent. Br, Gerg0 [1]: https://wiki.opnfv.org/display/EC/Edge+cloud?preview=/20745277/32015361/Edge%20Cloud_Pharos%20Spec_StarlingX.pdf [2]: https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios From: zhaoqihui at chinamobile.com Sent: Wednesday, January 9, 2019 10:07 AM To: Csatari, Gergely (Nokia - HU/Budapest) ; fuqiao ; beth.cohen ; Peret, Adrian (Nokia - FI/Espoo) ; julienjut ; haojingbo ; ildiko ; paul-andre.raymond ; trevor.cooper ; cristina.pauna ; xiaohua.zhang ; Bob.Monkman ; deepak.s ; asayeed ; Tina.Tsou ; klaus.mehler ; periyasamy.palanisamy ; hu.jie ; kliu ; wanglu ; pvaanane ; fanyamei ; glenn.seiler ; huang.shuquan ; adrien.lebre ; pierre.lynch ; pj ; valentin.boucher ; kan.hong ; claudio_serra ; acm ; Tikkanen, Viktor (Nokia - FI/Espoo) ; simple_hlw ; kailun.qin ; mark.beierl ; Manuel Buil Cc: opnfv-tech-discuss ; opnfv-tsc ; edge-computing Subject: Re: RE: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Sure. I have uploaded the slides onto our wiki home page: https://wiki.opnfv.org/display/EC/Edge+cloud you can find them at the bottom of the page -> "Related discussion links and slides" -> under "January 2019 Plugfest slides" Best, Qihui China Mobile Research Institute (+86) 13810659120 From: Csatari, Gergely (Nokia - HU/Budapest) Date: 2019-01-09 16:40 To: zhaoqihui at chinamobile.com; fuqiao; beth.cohen; Peret, Adrian (Nokia - FI/Espoo); julienjut; haojingbo; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; Tikkanen, Viktor (Nokia - FI/Espoo); simple_hlw; kailun.qin; mark.beierl; Manuel Buil CC: opnfv-tech-discuss; opnfv-tsc; edge-computing Subject: RE: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Hi, Is it possible to get the presented materials in some form? Thanks, Gerg0 From: zhaoqihui at chinamobile.com Sent: Wednesday, January 9, 2019 2:29 AM To: fuqiao ; beth.cohen ; Peret, Adrian (Nokia - FI/Espoo) ; julienjut ; haojingbo ; Csatari, Gergely (Nokia - HU/Budapest) ; ildiko ; paul-andre.raymond ; trevor.cooper ; cristina.pauna ; xiaohua.zhang ; Bob.Monkman ; deepak.s ; asayeed ; Tina.Tsou ; klaus.mehler ; periyasamy.palanisamy ; hu.jie ; kliu ; wanglu ; pvaanane ; fanyamei ; glenn.seiler ; huang.shuquan ; adrien.lebre ; pierre.lynch ; pj ; valentin.boucher ; kan.hong ; claudio_serra ; acm ; Tikkanen, Viktor (Nokia - FI/Espoo) ; simple_hlw ; kailun.qin ; mark.beierl ; Manuel Buil Cc: opnfv-tech-discuss ; opnfv-tsc ; edge-computing Subject: Re: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Hello edge cloud team, This week's meeting will be held together with the plugfest sessions. Time: Jan. 9th, 2019, Wednesday, UTC 07:30 ~ 09:00 Zoom link: https://zoom.us/j/457096090 Best, Qihui China Mobile Research Institute (+86) 13810659120 发件人： zhaoqihui at chinamobile.com 发送时间： 2018-12-26 09:05 收件人： fuqiao; beth.cohen; adrian.peret; julienjut; haojingbo; gergely.csatari; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; viktor.tikkanen; simple_hlw; kailun.qin; mark.beierl; Manuel Buil 抄送： opnfv-tech-discuss; opnfv-tsc; edge-computing 主题： Re: Re: [opnfv-tech-discuss] [edge cloud] Canceled：Edge Cloud Bi-weekly Meeting As a lot of us are on vacation, today's meeting has been canceled. China Mobile Research Institute (+86) 13810659120 发件人： zhaoqihui at chinamobile.com 发送时间： 2018-12-25 14:38 收件人： fuqiao; beth.cohen; adrian.peret; julienjut; haojingbo; gergely.csatari; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; viktor.tikkanen; simple_hlw; kailun.qin; mark.beierl; Manuel Buil 抄送： opnfv-tech-discuss; opnfv-tsc; edge-computing 主题： Re: Re: [opnfv-tech-discuss] [edge cloud] Canceled：Edge Cloud Bi-weekly Meeting Hello Edge Cloud Team, Merry Christmas & Happy Vacation~~ Best, Qihui China Mobile Research Institute (+86) 13810659120 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Wed Jan 9 09:53:30 2019 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Wed, 9 Jan 2019 09:53:30 +0000 Subject: [Edge-computing] [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting In-Reply-To: <2019010917361973987684@chinamobile.com> References: <1569231DC06A0846.23762@lists.opnfv.org>, <201811271147449384076@chinamobile.com>, <156F3B766B549CBF.21862@lists.opnfv.org>, <2018121117145221586888@chinamobile.com>, <2018121220212661606146@chinamobile.com>, <2018122514385416054410@chinamobile.com>, <201812260905336684741@chinamobile.com>, <2019010909291507376211@chinamobile.com>, , <2019010917064767623860@chinamobile.com>, <2019010917361973987684@chinamobile.com> Message-ID: Hi, Sure I agree, that a test deployment is not always following the production, but at least we should 1. describe what are the differneces and what is the reason for that 2. provide feedback for the production definition if there are new findings during the test definition, execution Thanks, Gerg0 From: zhaoqihui at chinamobile.com Sent: Wednesday, January 9, 2019 10:36 AM To: Csatari, Gergely (Nokia - HU/Budapest) Cc: opnfv-tech-discuss ; opnfv-tsc ; edge-computing Subject: Re: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Yes, I think we should try that. When I was doing the edge Pharos Spec, which is a draft for now, I definitely consulted the whitepaper, but was trying to do as less modification about the original Pharos spec as possible. Because I thought a test environment could not actually follow the real environment. And edge pharos spec is only one possible scenario that could be picked from edge site definitions. I'll see how to modify it and we can discuss in the following edge cloud meetings. Best, Qihui ________________________________ China Mobile Research Institute (+86) 13810659120 From: Gergely Csatari Date: 2019-01-09 17:13 To: zhaoqihui at chinamobile.com; fuqiao; beth.cohen; Peret, Adrian (Nokia - FI/Espoo); julienjut; haojingbo; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; Tikkanen, Viktor (Nokia - FI/Espoo); simple_hlw; kailun.qin; mark.beierl; Manuel Buil CC: opnfv-tech-discuss; opnfv-tsc; edge-computing Subject: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Hi, Thanks for the links. I still think, that we should keep the Edge Pharos Specs [1] and the Edge Cloud Site definitions [2] in the whitepaper consistent. Br, Gerg0 [1]: https://wiki.opnfv.org/display/EC/Edge+cloud?preview=/20745277/32015361/Edge%20Cloud_Pharos%20Spec_StarlingX.pdf [2]: https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios From: zhaoqihui at chinamobile.com > Sent: Wednesday, January 9, 2019 10:07 AM To: Csatari, Gergely (Nokia - HU/Budapest) >; fuqiao >; beth.cohen >; Peret, Adrian (Nokia - FI/Espoo) >; julienjut >; haojingbo >; ildiko >; paul-andre.raymond >; trevor.cooper >; cristina.pauna >; xiaohua.zhang >; Bob.Monkman >; deepak.s >; asayeed >; Tina.Tsou >; klaus.mehler >; periyasamy.palanisamy >; hu.jie >; kliu >; wanglu >; pvaanane >; fanyamei >; glenn.seiler >; huang.shuquan >; adrien.lebre >; pierre.lynch >; pj >; valentin.boucher >; kan.hong >; claudio_serra >; acm >; Tikkanen, Viktor (Nokia - FI/Espoo) >; simple_hlw >; kailun.qin >; mark.beierl >; Manuel Buil > Cc: opnfv-tech-discuss >; opnfv-tsc >; edge-computing > Subject: Re: RE: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Sure. I have uploaded the slides onto our wiki home page: https://wiki.opnfv.org/display/EC/Edge+cloud you can find them at the bottom of the page -> "Related discussion links and slides" -> under "January 2019 Plugfest slides" Best, Qihui ________________________________ China Mobile Research Institute (+86) 13810659120 From: Csatari, Gergely (Nokia - HU/Budapest) Date: 2019-01-09 16:40 To: zhaoqihui at chinamobile.com; fuqiao; beth.cohen; Peret, Adrian (Nokia - FI/Espoo); julienjut; haojingbo; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; Tikkanen, Viktor (Nokia - FI/Espoo); simple_hlw; kailun.qin; mark.beierl; Manuel Buil CC: opnfv-tech-discuss; opnfv-tsc; edge-computing Subject: RE: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Hi, Is it possible to get the presented materials in some form? Thanks, Gerg0 From: zhaoqihui at chinamobile.com > Sent: Wednesday, January 9, 2019 2:29 AM To: fuqiao >; beth.cohen >; Peret, Adrian (Nokia - FI/Espoo) >; julienjut >; haojingbo >; Csatari, Gergely (Nokia - HU/Budapest) >; ildiko >; paul-andre.raymond >; trevor.cooper >; cristina.pauna >; xiaohua.zhang >; Bob.Monkman >; deepak.s >; asayeed >; Tina.Tsou >; klaus.mehler >; periyasamy.palanisamy >; hu.jie >; kliu >; wanglu >; pvaanane >; fanyamei >; glenn.seiler >; huang.shuquan >; adrien.lebre >; pierre.lynch >; pj >; valentin.boucher >; kan.hong >; claudio_serra >; acm >; Tikkanen, Viktor (Nokia - FI/Espoo) >; simple_hlw >; kailun.qin >; mark.beierl >; Manuel Buil > Cc: opnfv-tech-discuss >; opnfv-tsc >; edge-computing > Subject: Re: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting Hello edge cloud team, This week's meeting will be held together with the plugfest sessions. Time: Jan. 9th, 2019, Wednesday, UTC 07:30 ~ 09:00 Zoom link: https://zoom.us/j/457096090 Best, Qihui ________________________________ China Mobile Research Institute (+86) 13810659120 发件人： zhaoqihui at chinamobile.com 发送时间： 2018-12-26 09:05 收件人： fuqiao; beth.cohen; adrian.peret; julienjut; haojingbo; gergely.csatari; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; viktor.tikkanen; simple_hlw; kailun.qin; mark.beierl; Manuel Buil 抄送： opnfv-tech-discuss; opnfv-tsc; edge-computing 主题： Re: Re: [opnfv-tech-discuss] [edge cloud] Canceled：Edge Cloud Bi-weekly Meeting As a lot of us are on vacation, today's meeting has been canceled. ________________________________ China Mobile Research Institute (+86) 13810659120 发件人： zhaoqihui at chinamobile.com 发送时间： 2018-12-25 14:38 收件人： fuqiao; beth.cohen; adrian.peret; julienjut; haojingbo; gergely.csatari; ildiko; paul-andre.raymond; trevor.cooper; cristina.pauna; xiaohua.zhang; Bob.Monkman; deepak.s; asayeed; Tina.Tsou; klaus.mehler; periyasamy.palanisamy; hu.jie; kliu; wanglu; pvaanane; fanyamei; glenn.seiler; huang.shuquan; adrien.lebre; pierre.lynch; pj; valentin.boucher; kan.hong; claudio_serra; acm; viktor.tikkanen; simple_hlw; kailun.qin; mark.beierl; Manuel Buil 抄送： opnfv-tech-discuss; opnfv-tsc; edge-computing 主题： Re: Re: [opnfv-tech-discuss] [edge cloud] Canceled：Edge Cloud Bi-weekly Meeting Hello Edge Cloud Team, Merry Christmas & Happy Vacation~~ Best, Qihui ________________________________ China Mobile Research Institute (+86) 13810659120 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Thu Jan 10 13:43:19 2019 From: ildiko at openstack.org (Ildiko Vancsa) Date: Thu, 10 Jan 2019 14:43:19 +0100 Subject: [Edge-computing] Use cases mapping to MVP architectures - FEEDBACK NEEDED Message-ID: Hi, We are reaching out to you about the use cases for edge cloud infrastructure that the Edge Computing Group is working on to collect. They are recorded in our wiki [1] and they describe high level scenarios when an edge cloud infrastructure would be needed. During the second Denver PTG discussions we drafted two MVP architectures what we could build from the current functionality of OpenStack with some slight modifications [2]. These are based on the work of James and his team from Oath. We differentiate between a distributed [3] and a centralized [4] control plane architecture scenarios. In one of the Berlin Forum sessions we were asked to map the MVP architecture scenarios to the use cases so I made an initial mapping and now we are looking for feedback. This mapping only means, that the listed use case can be implemented using the MVP architecture scenarios. It should be noted, that none of the MVP architecture scenarios provide solution for edge cloud infrastructure upgrade or centralized management. Please comment on the wiki or in a reply to this mail in case you have questions or disagree with the initial mapping we put together. Please let us know if you have any questions. Here is the use cases and the mapped architecture scenarios: Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X [5] Both distributed [3] and centralized [4] Universal customer premise equipment (uCPE) for Enterprise Network Services[6] Both distributed [3] and centralized [4] Unmanned Aircraft Systems (Drones) [7] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Cloud Storage Gateway - Storage at the Edge [8] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Open Caching - stream/store data at the edge [9] Both distributed [3] and centralized [4] Smart City as Software-Defined closed-loop system [10] The use case is not complete enough to figure out Augmented Reality -- Sony Gaming Network [11] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Analytics/control at the edge [12] The use case is not complete enough to figure out Manage retail chains - chick-fil-a [13] The use case is not complete enough to figure out At this moment chick-fil-a uses a different Kubernetes cluster in every edge location and they manage them using Git [14] Smart Home [15] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Data Collection - Smart cooler/cold chain tracking [16] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event VPN Gateway Service Delivery [17] The use case is not complete enough to figure out [1]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases [2]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario [4]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario [5]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Mobile_service_provider_5G.2F4G_virtual_RAN_deployment_and_Edge_Cloud_B2B2X. [6]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Universal_customer_premise_equipment_.28uCPE.29_for_Enterprise_Network_Services [7]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Aircraft_Systems_.28Drones.29 [8]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Cloud_Storage_Gateway_-_Storage_at_the_Edge [9]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge [10]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_City_as_Software-Defined_closed-loop_system [11]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Augmented_Reality_--_Sony_Gaming_Network [12]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Analytics.2Fcontrol_at_the_edge [13]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Manage_retail_chains_-_chick-fil-a [14]: https://schd.ws/hosted_files/kccna18/34/GitOps.pdf [15]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home [16]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Data_Collection_-_Smart_cooler.2Fcold_chain_tracking [17]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#VPN_Gateway_Service_Delivery Thanks and Best Regards, Gergely and Ildikó From ildiko at openstack.org Thu Jan 10 14:16:28 2019 From: ildiko at openstack.org (Ildiko Vancsa) Date: Thu, 10 Jan 2019 15:16:28 +0100 Subject: [Edge-computing] Upcoming CFP deadlines in January to keep an eye on Message-ID: <2C13EFC6-FF8A-4BB1-87B4-EE156353B705@openstack.org> Hi, It is a friendly reminder to the CFP deadlines coming up over the next three weeks including the Open Infrastructure Summit: * January 21 - Open Networking Summit in San Jose April 3-5 - https://events.linuxfoundation.org/events/open-networking-summit-north-america-2019/program/cfp/ * January 23 - Open Infrastructure Summit in Denver April 29-May 1 - https://www.openstack.org/summit/denver-2019/ Please see the following Google sheet for further events this year to keep in mind that are relevant to the area of edge computing and IoT: https://docs.google.com/spreadsheets/d/1A9HiMjnqVGxSCd9No7theW8oNu3V1rmK6R1xJOzfUEU/edit?usp=sharing Please let me know if you have any questions or need any help. Thanks and Best Regards, Ildikó From gergely.csatari at nokia.com Thu Jan 10 14:50:52 2019 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Thu, 10 Jan 2019 14:50:52 +0000 Subject: [Edge-computing] Status of Keystone federation testing with tempest In-Reply-To: References: , , , Message-ID: Hi, Okay, the problem was with the wrong IP configuration for the metadata fetching. Now it is sorted out, but Shibboleth is still not happy. I've attached the error log I get now from the idp. If you have any idea for the reason please notify me. Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Monday, January 7, 2019 4:23:23 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org; Ildiko Vancsa; Beierl, Mark Subject: Re: Status of Keystone federation testing with tempest Hi, Just to send a signal, that I'm still working on this (with best effort). What I could figure out in the last some months, is that we need a "verify=False" parameter in the session.post of send_identity_provider_authn_request (in saml2_client.py) to be able to connect to the IdP using self signed certificates. Now I'm able to communicate with the IdP and I can see, that there is a problem with the IdP config. This is the log of Shibboleth: 2019-01-07 11:33:55,165 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/ecp is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID http://127.0.0.1/shibboleth) 2019-01-07 11:33:55,167 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration I keep debugging this and update you about the results. Would it help if I would push all modified things to GitHub with a description how am I doing the configuration? Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Saturday, September 15, 2018 12:36 AM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Re: Status of Keystone federation testing with tempest Hi, Some update on the open issues: - Make this work 😉: Okay, I realized, that I use the wrong certificate in the Idp. Based on the IdP-s description I should generate a p12 certificate using the certificate and the key used by the Shibboleth Sp. When I try to generate the certificate I get a strange error: openssl pkcs12 -inkey /etc/shibboleth/sp-key.pem -in /etc/shibboleth/sp-cert.pem -out ../keystone-shibboleth-idp-dockerized/shibboleth-idp/credentials/idp-browser.p12 139822780584384:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1129: 139822780584384:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:289:Type=PKCS12 Google tells me that this is becouse one of my pem files are in the wrong format. This is really strange as the error persist even after I regenerated these files with shib-keygen -f -y 1 - Figure out how to start a Container in a Keystone plugin or a tempest plugin - no progress on this - Figure out ow to integrate with CI - no progress on this - Figure out how to use static certificates and keys, so the same IdP container image can be used. If you are bigger fans of IRC than email I can start sending these updates to the keystone channel. Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, September 12, 2018 11:25:32 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Re: Status of Keystone federation testing with tempest Hi, Some update on the open issues. - Make this work 😉 - here I have some progress, however I can not explain why. Now keystone is able to reach Shibboleth and Shibboleth answers with FatalProfileException "A valid authentication statement was not found in the incoming message.". I continue to figure out what is the problem. - Set the idp address in the correct place - This is done thanks to gmann. - Figure out how to start a Container in a Keystone plugin or a tempest plugin - Here I try to use https://github.com/openstack/devstack-plugin-container however I'm not sure if this is the right tool to start containers in DevStack environment. - Figure out ow to integrate with CI - no progress on this I'm still happy get any help either in mail, IRC or in person on the PTG. Thanks, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, August 31, 2018 1:03:43 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Status of Keystone federation testing with tempest Hi, I'm working on this for a while, but as I am not a big expert of IdP, Keysone or Tempest I have a bit slow progress. I decided to share what I did and what are my current probelms to 1) inform the team about the progress 2) keep a record for myself 3) hoping for help and/or hints. So I did this: 1) Get an Ubuntu 2) Install devstack with enable_plugin keystone git://git.openstack.org/openstack/keystone enable_service keystone-saml2-federation Here I already ran into some package maangement issues due to some libcurl3 and libcurl4 incompatibility issue what I solved using https://launchpad.net/~xapienz/+archive/ubuntu/curl34 3) Install the Keystone tempest plugin 4) Build a Shibboleth IdP container based on https://github.com/Unicon/shibboleth-idp-dockerized with the configuration I believe is correct. I have a feeling that we will need to set a proper organisation for this if we want to publish this to Docker Hub. By the way is there a container registry maintained in the OpenStack development infra? 5) Run the container and expose 8080, 4443 and 8443 ports This is a half success. Shibboleth contacts Keystone (or actually the Shibboleth apache module) for metadata update, but it works only on the first attempt. The regular updates are not working for some reason. Also I was not able to get a positive answer from the status script of Shibboleth itself, so i just decided to move a bit forward. 6) Set idp_url to https://localhost:8080/idp/profile/SAML2/SOAP/ECP in _request_unscoped_token inside the Keystone tempest plugin. Here I have no idea where the configuration is actually stores and where should I set this in a nice way. 7) Run the tempest tests. Now here I get an error message which tells me about SSL version numbers (hands.hake: Error([('SSL routines', 'ssl3_get_record', 'wrong version number')],)",),))). I tried to use different ssl versions with Curl, but it complains about the lack of support in libsso. So here I am now. Things what I deffinetly should figure out: - Make this work 😉 - Set the idp address in the correct place - Figure out how to start a Container in a Keystone plugin or a tempest plugin - Figure out ow to integrate with CI Any comments are welcome. Br, Gerg0 Curl 3 and 4 : Evgeny Brazgin - launchpad.net launchpad.net PPA contains libcurl4 package, which supports both libcurl3 and libcurl4 API. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: idp-error.log Type: text/x-log Size: 75870 bytes Desc: idp-error.log URL: From bdobreli at redhat.com Thu Jan 10 15:34:45 2019 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Thu, 10 Jan 2019 16:34:45 +0100 Subject: [Edge-computing] Use cases mapping to MVP architectures - FEEDBACK NEEDED In-Reply-To: References: Message-ID: <133ad3bc-bc57-b627-7b43-94f8ac846746@redhat.com> On 10.01.2019 14:43, Ildiko Vancsa wrote: > Hi, > > We are reaching out to you about the use cases for edge cloud infrastructure that the Edge Computing Group is working on to collect. They are recorded in our wiki [1] and they describe high level scenarios when an edge cloud infrastructure would be needed. Hello. Verifying the mappings created for the "Elementary operations on a site" [18] feature against the distributed glance specification [19], I can see a vital feature is missing for "Advanced operations on a site", like creating an image locally, when the parent control plane is not available. And consequences coming off that, like availability of create snapshots for Nova as well. All that boils down to a) better identifying the underlying requirement/limitations for CRUD operations available for middle edge sites in the Distributed Control Plane case. And b) the requirement of data replication and conflicts resolving tooling, which comes out, if we assume we want all CRUDs being always available for middle edge sites disregard of the parent edge's control plane state. So that is the missing and important thing to have socialised and noted for the mappings. [18] https://wiki.openstack.org/wiki/MappingOfUseCasesFeaturesRequirementsAndUserStories#Elementary_operations_on_one_site [19] https://review.openstack.org/619638 > > During the second Denver PTG discussions we drafted two MVP architectures what we could build from the current functionality of OpenStack with some slight modifications [2]. These are based on the work of James and his team from Oath. We differentiate between a distributed [3] and a centralized [4] control plane architecture scenarios. > > In one of the Berlin Forum sessions we were asked to map the MVP architecture scenarios to the use cases so I made an initial mapping and now we are looking for feedback. > > This mapping only means, that the listed use case can be implemented using the MVP architecture scenarios. It should be noted, that none of the MVP architecture scenarios provide solution for edge cloud infrastructure upgrade or centralized management. > > Please comment on the wiki or in a reply to this mail in case you have questions or disagree with the initial mapping we put together. > > Please let us know if you have any questions. > > > Here is the use cases and the mapped architecture scenarios: > > Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X [5] > Both distributed [3] and centralized [4] > Universal customer premise equipment (uCPE) for Enterprise Network Services[6] > Both distributed [3] and centralized [4] > Unmanned Aircraft Systems (Drones) [7] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Cloud Storage Gateway - Storage at the Edge [8] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Open Caching - stream/store data at the edge [9] > Both distributed [3] and centralized [4] > Smart City as Software-Defined closed-loop system [10] > The use case is not complete enough to figure out > Augmented Reality -- Sony Gaming Network [11] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Analytics/control at the edge [12] > The use case is not complete enough to figure out > Manage retail chains - chick-fil-a [13] > The use case is not complete enough to figure out > At this moment chick-fil-a uses a different Kubernetes cluster in every edge location and they manage them using Git [14] > Smart Home [15] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > Data Collection - Smart cooler/cold chain tracking [16] > None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event > VPN Gateway Service Delivery [17] > The use case is not complete enough to figure out > > [1]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases > [2]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures > [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario > [4]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario > [5]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Mobile_service_provider_5G.2F4G_virtual_RAN_deployment_and_Edge_Cloud_B2B2X. > [6]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Universal_customer_premise_equipment_.28uCPE.29_for_Enterprise_Network_Services > [7]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Aircraft_Systems_.28Drones.29 > [8]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Cloud_Storage_Gateway_-_Storage_at_the_Edge > [9]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge > [10]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_City_as_Software-Defined_closed-loop_system > [11]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Augmented_Reality_--_Sony_Gaming_Network > [12]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Analytics.2Fcontrol_at_the_edge > [13]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Manage_retail_chains_-_chick-fil-a > [14]: https://schd.ws/hosted_files/kccna18/34/GitOps.pdf > [15]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home > [16]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Data_Collection_-_Smart_cooler.2Fcold_chain_tracking > [17]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#VPN_Gateway_Service_Delivery > > > Thanks and Best Regards, > Gergely and Ildikó > > > > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing > -- Best regards, Bogdan Dobrelya, Irc #bogdando From Mark.Beierl at dell.com Thu Jan 10 19:27:39 2019 From: Mark.Beierl at dell.com (Beierl, Mark) Date: Thu, 10 Jan 2019 19:27:39 +0000 Subject: [Edge-computing] Status of Keystone federation testing with tempest In-Reply-To: References: Message-ID: <9942DBA5-DCFA-41BF-B0F7-D26107919509@emc.com> Thanks, Gergely. Can I get you to update https://wiki.opnfv.org/display/EC/Keystone+Federation+Demo with what you have done differently to get to this stage? Thanks! Regards, Mark Mark Beierl SW System Sr Principal Developer Dell EMC | Cloud & Communication Service Provider Solution Mark.Beierl at Dell.com From: "Csatari, Gergely (Nokia - HU/Budapest)" Date: Thursday, January 10, 2019 at 09:51 To: "nick at stackhpc.com" , "knikolla at bu.edu" , "colleen at gazlene.net" , "mbuil at suse.com" , "edge-computing at lists.openstack.org" , Ildiko Vancsa , "Beierl, Mark" Subject: Re: Status of Keystone federation testing with tempest [EXTERNAL EMAIL] Hi, Okay, the problem was with the wrong IP configuration for the metadata fetching. Now it is sorted out, but Shibboleth is still not happy. I've attached the error log I get now from the idp. If you have any idea for the reason please notify me. Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Monday, January 7, 2019 4:23:23 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org; Ildiko Vancsa; Beierl, Mark Subject: Re: Status of Keystone federation testing with tempest Hi, Just to send a signal, that I'm still working on this (with best effort). What I could figure out in the last some months, is that we need a "verify=False" parameter in the session.post of send_identity_provider_authn_request (in saml2_client.py) to be able to connect to the IdP using self signed certificates. Now I'm able to communicate with the IdP and I can see, that there is a problem with the IdP config. This is the log of Shibboleth: 2019-01-07 11:33:55,165 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/ecp is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID http://127.0.0.1/shibboleth) 2019-01-07 11:33:55,167 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration I keep debugging this and update you about the results. Would it help if I would push all modified things to GitHub with a description how am I doing the configuration? Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Saturday, September 15, 2018 12:36 AM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Re: Status of Keystone federation testing with tempest Hi, Some update on the open issues: - Make this work 😉: Okay, I realized, that I use the wrong certificate in the Idp. Based on the IdP-s description I should generate a p12 certificate using the certificate and the key used by the Shibboleth Sp. When I try to generate the certificate I get a strange error: openssl pkcs12 -inkey /etc/shibboleth/sp-key.pem -in /etc/shibboleth/sp-cert.pem -out ../keystone-shibboleth-idp-dockerized/shibboleth-idp/credentials/idp-browser.p12 139822780584384:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1129: 139822780584384:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:289:Type=PKCS12 Google tells me that this is becouse one of my pem files are in the wrong format. This is really strange as the error persist even after I regenerated these files with shib-keygen -f -y 1 - Figure out how to start a Container in a Keystone plugin or a tempest plugin - no progress on this - Figure out ow to integrate with CI - no progress on this - Figure out how to use static certificates and keys, so the same IdP container image can be used. If you are bigger fans of IRC than email I can start sending these updates to the keystone channel. Br, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Wednesday, September 12, 2018 11:25:32 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Re: Status of Keystone federation testing with tempest Hi, Some update on the open issues. - Make this work 😉 - here I have some progress, however I can not explain why. Now keystone is able to reach Shibboleth and Shibboleth answers with FatalProfileException "A valid authentication statement was not found in the incoming message.". I continue to figure out what is the problem. - Set the idp address in the correct place - This is done thanks to gmann. - Figure out how to start a Container in a Keystone plugin or a tempest plugin - Here I try to use https://github.com/openstack/devstack-plugin-container however I'm not sure if this is the right tool to start containers in DevStack environment. - Figure out ow to integrate with CI - no progress on this I'm still happy get any help either in mail, IRC or in person on the PTG. Thanks, Gerg0 ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, August 31, 2018 1:03:43 PM To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at suse.com; edge-computing at lists.openstack.org Subject: Status of Keystone federation testing with tempest Hi, I'm working on this for a while, but as I am not a big expert of IdP, Keysone or Tempest I have a bit slow progress. I decided to share what I did and what are my current probelms to 1) inform the team about the progress 2) keep a record for myself 3) hoping for help and/or hints. So I did this: 1) Get an Ubuntu 2) Install devstack with enable_plugin keystone git://git.openstack.org/openstack/keystone enable_service keystone-saml2-federation Here I already ran into some package maangement issues due to some libcurl3 and libcurl4 incompatibility issue what I solved using https://launchpad.net/~xapienz/+archive/ubuntu/curl34 3) Install the Keystone tempest plugin 4) Build a Shibboleth IdP container based on https://github.com/Unicon/shibboleth-idp-dockerized with the configuration I believe is correct. I have a feeling that we will need to set a proper organisation for this if we want to publish this to Docker Hub. By the way is there a container registry maintained in the OpenStack development infra? 5) Run the container and expose 8080, 4443 and 8443 ports This is a half success. Shibboleth contacts Keystone (or actually the Shibboleth apache module) for metadata update, but it works only on the first attempt. The regular updates are not working for some reason. Also I was not able to get a positive answer from the status script of Shibboleth itself, so i just decided to move a bit forward. 6) Set idp_url to https://localhost:8080/idp/profile/SAML2/SOAP/ECP in _request_unscoped_token inside the Keystone tempest plugin. Here I have no idea where the configuration is actually stores and where should I set this in a nice way. 7) Run the tempest tests. Now here I get an error message which tells me about SSL version numbers (hands.hake: Error([('SSL routines', 'ssl3_get_record', 'wrong version number')],)",),))). I tried to use different ssl versions with Curl, but it complains about the lack of support in libsso. So here I am now. Things what I deffinetly should figure out: - Make this work 😉 - Set the idp address in the correct place - Figure out how to start a Container in a Keystone plugin or a tempest plugin - Figure out ow to integrate with CI Any comments are welcome. Br, Gerg0 Curl 3 and 4 : Evgeny Brazgin - launchpad.net launchpad.net PPA contains libcurl4 package, which supports both libcurl3 and libcurl4 API. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Tue Jan 15 09:53:00 2019 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 15 Jan 2019 09:53:00 +0000 Subject: [Edge-computing] Use cases mapping to MVP architectures - FEEDBACK NEEDED In-Reply-To: <741FC607-65D8-4345-AC6A-42FE7ECAD2BA@openstack.org> References: <133ad3bc-bc57-b627-7b43-94f8ac846746@redhat.com> <741FC607-65D8-4345-AC6A-42FE7ECAD2BA@openstack.org> Message-ID: Hi, Thanks for the comment. Do you see any other use of the capability to create images on an edge site except creating snapshots? Thanks, Gerg0 From: Ildiko Vancsa Sent: Tuesday, January 15, 2019 2:59 AM To: Csatari, Gergely (Nokia - HU/Budapest) Subject: Fwd: [Edge-computing] Use cases mapping to MVP architectures - FEEDBACK NEEDED Begin forwarded message: From: Bogdan Dobrelya > Subject: Re: [Edge-computing] Use cases mapping to MVP architectures - FEEDBACK NEEDED Date: 2019. January 10. 8:34:45 GMT-7 To: edge-computing at lists.openstack.org, "openstack-discuss at lists.openstack.org" > On 10.01.2019 14:43, Ildiko Vancsa wrote: Hi, We are reaching out to you about the use cases for edge cloud infrastructure that the Edge Computing Group is working on to collect. They are recorded in our wiki [1] and they describe high level scenarios when an edge cloud infrastructure would be needed. Hello. Verifying the mappings created for the "Elementary operations on a site" [18] feature against the distributed glance specification [19], I can see a vital feature is missing for "Advanced operations on a site", like creating an image locally, when the parent control plane is not available. And consequences coming off that, like availability of create snapshots for Nova as well. All that boils down to a) better identifying the underlying requirement/limitations for CRUD operations available for middle edge sites in the Distributed Control Plane case. And b) the requirement of data replication and conflicts resolving tooling, which comes out, if we assume we want all CRUDs being always available for middle edge sites disregard of the parent edge's control plane state. So that is the missing and important thing to have socialised and noted for the mappings. [18] https://wiki.openstack.org/wiki/MappingOfUseCasesFeaturesRequirementsAndUserStories#Elementary_operations_on_one_site [19] https://review.openstack.org/619638 During the second Denver PTG discussions we drafted two MVP architectures what we could build from the current functionality of OpenStack with some slight modifications [2]. These are based on the work of James and his team from Oath. We differentiate between a distributed [3] and a centralized [4] control plane architecture scenarios. In one of the Berlin Forum sessions we were asked to map the MVP architecture scenarios to the use cases so I made an initial mapping and now we are looking for feedback. This mapping only means, that the listed use case can be implemented using the MVP architecture scenarios. It should be noted, that none of the MVP architecture scenarios provide solution for edge cloud infrastructure upgrade or centralized management. Please comment on the wiki or in a reply to this mail in case you have questions or disagree with the initial mapping we put together. Please let us know if you have any questions. Here is the use cases and the mapped architecture scenarios: Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X [5] Both distributed [3] and centralized [4] Universal customer premise equipment (uCPE) for Enterprise Network Services[6] Both distributed [3] and centralized [4] Unmanned Aircraft Systems (Drones) [7] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Cloud Storage Gateway - Storage at the Edge [8] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Open Caching - stream/store data at the edge [9] Both distributed [3] and centralized [4] Smart City as Software-Defined closed-loop system [10] The use case is not complete enough to figure out Augmented Reality -- Sony Gaming Network [11] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Analytics/control at the edge [12] The use case is not complete enough to figure out Manage retail chains - chick-fil-a [13] The use case is not complete enough to figure out At this moment chick-fil-a uses a different Kubernetes cluster in every edge location and they manage them using Git [14] Smart Home [15] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event Data Collection - Smart cooler/cold chain tracking [16] None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event VPN Gateway Service Delivery [17] The use case is not complete enough to figure out [1]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases [2]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures [3]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario [4]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario [5]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Mobile_service_provider_5G.2F4G_virtual_RAN_deployment_and_Edge_Cloud_B2B2X. [6]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Universal_customer_premise_equipment_.28uCPE.29_for_Enterprise_Network_Services [7]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Aircraft_Systems_.28Drones.29 [8]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Cloud_Storage_Gateway_-_Storage_at_the_Edge [9]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Open_Caching_-_stream.2Fstore_data_at_the_edge [10]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_City_as_Software-Defined_closed-loop_system [11]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Augmented_Reality_--_Sony_Gaming_Network [12]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Analytics.2Fcontrol_at_the_edge [13]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Manage_retail_chains_-_chick-fil-a [14]: https://schd.ws/hosted_files/kccna18/34/GitOps.pdf [15]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home [16]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Data_Collection_-_Smart_cooler.2Fcold_chain_tracking [17]: https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#VPN_Gateway_Service_Delivery Thanks and Best Regards, Gergely and Ildikó _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing -- Best regards, Bogdan Dobrelya, Irc #bogdando _______________________________________________ Edge-computing mailing list Edge-computing at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Tue Jan 15 17:51:55 2019 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 15 Jan 2019 10:51:55 -0700 Subject: [Edge-computing] February APAC slot is colliding with the Chinese New Year Message-ID: Hi, We have the APAC slot for the weekly calls every first Thursday of the month which in February is on the 7th. As Chinese New Year is on the 5th of February I wonder whether we should move the APAC slot to the week after (February 14th)? And if we do, should we switch it with the US-friendly slot or just simply move the call and have two calls on the week of February 11th? What would be your preference? Thanks and Best Regards, Ildikó From claire at openstack.org Tue Jan 22 20:50:24 2019 From: claire at openstack.org (Claire Massey) Date: Tue, 22 Jan 2019 12:50:24 -0800 Subject: [Edge-computing] CFP Open Until January 23, Open Infrastructure Summit in Denve In-Reply-To: <530BC84C-FE80-4C2D-B636-D8205AC5E23B@openstack.org> References: <530BC84C-FE80-4C2D-B636-D8205AC5E23B@openstack.org> Message-ID: <4CB0CC8F-1977-4830-930C-64B49796F8E4@openstack.org> Friendly reminder - *Tomorrow, Jan 23*, is the CFP deadline for the Denver Open Infrastructure Summit (formerly the OpenStack Summit). Submit talks here: https://www.openstack.org/summit/denver-2019/ . > On Dec 18, 2018, at 8:17 AM, Claire Massey wrote: > > Hi everyone, > > FYI - the CFP is now open for the first Open Infrastructure Summit (formerly the OpenStack Summit) which will be held in Denver, Colorado April 29 - May 1, 2019. > > Wednesday, *January 23* is the deadline to Submit presentations . > > The Open Infrastructure Summit is organized by OSF and designed to be a place where open source infrastructure communities can come together and collaborate in the open. Edge Computing will again have a prominent focus at the event so please submit talks to the CFP and plan to attend! > > SUBMIT YOUR PRESENTATION > Important info: > Based on previous Program Committee and attendee feedback, we have added / updated three Tracks: Security, Getting Started, and Open Development (previously Open Source Community). You can find the Track descriptions here . > All of the OSF pilot projects —including Airship, Kata Containers, StarlingX and Zuul — will be front and center alongside other open source communities like Ansible, Cloud Foundry, Docker, Kubernetes, and many more. > The Open Infrastructure Summit (formerly the OpenStack Summit), has evolved to recognize our diverse audience, and to signal to the market that the event is relevant for all IT infrastructure decision makers. > If you’re interested in influencing the Summit content, apply to be a Programming Committee member *, where you can also find a full list of time requirements and expectations. Nominations will close on January 4, 2019. The content submission process for the Forum and Project Teams Gathering will be managed separately in the upcoming months. > > *OSF Staff will serve as the Programming Committee for the Getting Started Track. > > Denver Summit registration and sponsor sales are currently open. Learn more and email summit at openstack.org with any questions. > > Please email speakersupport at openstack.org with any questions or feedback. > > Thanks, > Claire > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko at openstack.org Tue Jan 22 20:58:08 2019 From: ildiko at openstack.org (Ildiko Vancsa) Date: Tue, 22 Jan 2019 12:58:08 -0800 Subject: [Edge-computing] CFP tracking etherpad Message-ID: Hi, Following up on my action item from today’s edge working group call I created an etherpad to track our planned/submitted session proposals for industry events: https://etherpad.openstack.org/p/edge-cfp-for-industry-events Please add your proposals and also feel free to add further events you are planning to propose edge related sessions that cover topics such as the work of this group, StarlingX, OpenStack projects, and so forth. Please let me know if you have any questions. Thanks, Ildikó From lbragstad at gmail.com Fri Jan 25 19:16:15 2019 From: lbragstad at gmail.com (Lance Bragstad) Date: Fri, 25 Jan 2019 13:16:15 -0600 Subject: [Edge-computing] [keystone] x509 authentication Message-ID: Hi all, We've been going over keystone gaps that need to be addressed for edge use cases every Tuesday. Since Berlin, Oath has open-sourced some of their custom authentication plugins for keystone that help them address these gaps. The basic idea is that users authenticate to some external identity provider (Athenz in Oath's case), and then present an Athenz token to keystone. The custom plugins decode the token from Athenz to determine the user, project, roles assignments, and other useful bits of information. After that, it creates any resources that don't exist in keystone already. Ultimately, a user can authenticate against a keystone node and have specific resources provisioned automatically. In Berlin, engineers from Oath were saying they'd like to move away from Athenz tokens altogether and use x509 certificates issued by Athenz instead. The auto-provisioning approach is very similar to a feature we have in keystone already. In Berlin, and shortly after, there was general agreement that if we could support x509 authentication with auto-provisioning via keystone federation, that would pretty much solve Oath's use case without having to maintain custom keystone plugins. Last week, Colleen started digging into keystone's existing x509 authentication support. I'll start with the good news, which is x509 authentication works, for the most part. It's been a feature in keystone for a long time, and it landed after we implemented federation support around the Kilo release. Chances are there won't be a need for a keystone specification like we were initially thinking in the edge meetings. Unfortunately, the implementation for x509 authentication has outdated documentation, is extremely fragile, hard to set up, and hasn't been updated with improvements we've made to the federation API since the original implementation (like shadow users or auto-provisioning, which work with other federated protocols like OpenID Connect and SAML). We've started tracking the gaps with bugs [0] so that we have things written down. I think the good thing is that once we get this cleaned up, we'll be able to re-use some of the newer federation features with x509 authentication/federation. These updates would make x509 a first-class federated protocol. The approach, pending the bug fixes, would remove the need for Oath's custom authentication plugins. It could be useful for edge deployments, or even deployments with many regions, by allowing users to be auto-provisioned in each region. Although, it doesn't necessarily solve the network partition issue. Now that we have an idea of where to start and some bug reports [0], I'm wondering if anyone is interested in helping with the update or refactor. Because this won't require a specification, we can get started on it sooner, instead of having to wait for Train development and a new specification. I'm also curious if anyone has comments or questions about the approach. Thanks, Lance [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpenick at gmail.com Fri Jan 25 21:01:52 2019 From: jpenick at gmail.com (James Penick) Date: Fri, 25 Jan 2019 13:01:52 -0800 Subject: [Edge-computing] [keystone] x509 authentication In-Reply-To: References: Message-ID: Hey Lance, We'd definitely be interested in helping with the work. I'll grab some volunteers from my team and get them in touch within the next few days. -James On Fri, Jan 25, 2019 at 11:16 AM Lance Bragstad wrote: > Hi all, > > We've been going over keystone gaps that need to be addressed for edge use > cases every Tuesday. Since Berlin, Oath has open-sourced some of their > custom authentication plugins for keystone that help them address these > gaps. > > The basic idea is that users authenticate to some external identity > provider (Athenz in Oath's case), and then present an Athenz token to > keystone. The custom plugins decode the token from Athenz to determine the > user, project, roles assignments, and other useful bits of information. > After that, it creates any resources that don't exist in keystone already. > Ultimately, a user can authenticate against a keystone node and have > specific resources provisioned automatically. In Berlin, engineers from > Oath were saying they'd like to move away from Athenz tokens altogether and > use x509 certificates issued by Athenz instead. The auto-provisioning > approach is very similar to a feature we have in keystone already. In > Berlin, and shortly after, there was general agreement that if we could > support x509 authentication with auto-provisioning via keystone federation, > that would pretty much solve Oath's use case without having to maintain > custom keystone plugins. > > Last week, Colleen started digging into keystone's existing x509 > authentication support. I'll start with the good news, which is x509 > authentication works, for the most part. It's been a feature in keystone > for a long time, and it landed after we implemented federation support > around the Kilo release. Chances are there won't be a need for a keystone > specification like we were initially thinking in the edge meetings. > Unfortunately, the implementation for x509 authentication has outdated > documentation, is extremely fragile, hard to set up, and hasn't been > updated with improvements we've made to the federation API since the > original implementation (like shadow users or auto-provisioning, which work > with other federated protocols like OpenID Connect and SAML). We've started > tracking the gaps with bugs [0] so that we have things written down. > > I think the good thing is that once we get this cleaned up, we'll be able > to re-use some of the newer federation features with x509 > authentication/federation. These updates would make x509 a first-class > federated protocol. The approach, pending the bug fixes, would remove the > need for Oath's custom authentication plugins. It could be useful for edge > deployments, or even deployments with many regions, by allowing users to be > auto-provisioned in each region. Although, it doesn't necessarily solve the > network partition issue. > > Now that we have an idea of where to start and some bug reports [0], I'm > wondering if anyone is interested in helping with the update or refactor. > Because this won't require a specification, we can get started on it > sooner, instead of having to wait for Train development and a new > specification. I'm also curious if anyone has comments or questions about > the approach. > > Thanks, > > Lance > > [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509 > _______________________________________________ > Edge-computing mailing list > Edge-computing at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Greg.Waines at windriver.com Tue Jan 29 14:05:22 2019 From: Greg.Waines at windriver.com (Waines, Greg) Date: Tue, 29 Jan 2019 14:05:22 +0000 Subject: [Edge-computing] [keystone] x509 authentication In-Reply-To: References: Message-ID: <1677A2C3-F648-4611-8332-474938ECC677@windriver.com> Hey Lance, I like the plan. Just a clarifying question on “Although, it doesn't necessarily solve the network partition issue.” . * I’m assuming this is in a scenario where after the network partition the Edge Cloud and local client(s) do not have access to the Identity Provider ? * And in this case, it doesn’t work because ? * For a new local client (without any cached tokens), even if there are local shadow users already configured, the authentication still requires communication with the Identity Provider ? Is this correct ? Greg. From: Lance Bragstad Date: Friday, January 25, 2019 at 2:16 PM To: "edge-computing at lists.openstack.org" , "openstack-discuss at lists.openstack.org" Subject: [Edge-computing] [keystone] x509 authentication Hi all, We've been going over keystone gaps that need to be addressed for edge use cases every Tuesday. Since Berlin, Oath has open-sourced some of their custom authentication plugins for keystone that help them address these gaps. The basic idea is that users authenticate to some external identity provider (Athenz in Oath's case), and then present an Athenz token to keystone. The custom plugins decode the token from Athenz to determine the user, project, roles assignments, and other useful bits of information. After that, it creates any resources that don't exist in keystone already. Ultimately, a user can authenticate against a keystone node and have specific resources provisioned automatically. In Berlin, engineers from Oath were saying they'd like to move away from Athenz tokens altogether and use x509 certificates issued by Athenz instead. The auto-provisioning approach is very similar to a feature we have in keystone already. In Berlin, and shortly after, there was general agreement that if we could support x509 authentication with auto-provisioning via keystone federation, that would pretty much solve Oath's use case without having to maintain custom keystone plugins. Last week, Colleen started digging into keystone's existing x509 authentication support. I'll start with the good news, which is x509 authentication works, for the most part. It's been a feature in keystone for a long time, and it landed after we implemented federation support around the Kilo release. Chances are there won't be a need for a keystone specification like we were initially thinking in the edge meetings. Unfortunately, the implementation for x509 authentication has outdated documentation, is extremely fragile, hard to set up, and hasn't been updated with improvements we've made to the federation API since the original implementation (like shadow users or auto-provisioning, which work with other federated protocols like OpenID Connect and SAML). We've started tracking the gaps with bugs [0] so that we have things written down. I think the good thing is that once we get this cleaned up, we'll be able to re-use some of the newer federation features with x509 authentication/federation. These updates would make x509 a first-class federated protocol. The approach, pending the bug fixes, would remove the need for Oath's custom authentication plugins. It could be useful for edge deployments, or even deployments with many regions, by allowing users to be auto-provisioned in each region. Although, it doesn't necessarily solve the network partition issue. Now that we have an idea of where to start and some bug reports [0], I'm wondering if anyone is interested in helping with the update or refactor. Because this won't require a specification, we can get started on it sooner, instead of having to wait for Train development and a new specification. I'm also curious if anyone has comments or questions about the approach. Thanks, Lance [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Tue Jan 29 17:55:00 2019 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 29 Jan 2019 11:55:00 -0600 Subject: [Edge-computing] [keystone] x509 authentication In-Reply-To: <1677A2C3-F648-4611-8332-474938ECC677@windriver.com> References: <1677A2C3-F648-4611-8332-474938ECC677@windriver.com> Message-ID: On Tue, Jan 29, 2019 at 8:06 AM Waines, Greg wrote: > Hey Lance, > > I like the plan. > > > > Just a clarifying question on *“Although, it doesn't necessarily solve > the network partition issue.”* . > > - I’m assuming this is in a scenario where after the network partition > the Edge Cloud and local client(s) do not have access to the Identity > Provider ? > > Correct. Using x509 certificates to authenticate to keystone still requires access to keystone. Keystone doesn't necessarily need a link to the "identity provider" in this case, since the authentication path doesn't require online validation. This is different from using SAML assertions, where the entire flow establishes a connection between keystone acting as the service provider (at the edge) and an identity provider somewhere authenticating the user. > > - > - And in this case, it doesn’t work because ? > - For a new local client (without any cached tokens), > even if there are local shadow users already configured, > the authentication still requires communication with the Identity > Provider ? > > I guess it depends on the architecture you're considering [0]. There isn't a hard requirement to talk to the identity provider of an x509 certificate, but token validation still needs to work. If you're deploying the architecture with the distributed control plane, you can authenticate with an x509 certificate against any keystone. For example, only using a centralized data center and medium/large edge cluster would make keystone available everywhere, so a network partition might not be an issue. Conversely, if you authenticate for a token with an x509 certificate and use it to spin up compute resources in a small edge cluster, which doesn't have a keystone deployment, the network partition is going to make online token validation impossible, if you're calling APIs in the small edge directly. The same issue is going to be present for deployments following the centralized control plane architecture since keystone is only available in the central data center and isn't available at the large, medium, or small edge sites. Validating the token online from edge sites to the centralized data center is going to be susceptible to network partitions. In my opinion, the big difference between x509 and other federated protocols is that it doesn't really have a hard requirement on linking back to the identity provider. In the case of SAML, the identity provider is anything that has the ability to issue SAML assertions proving the identity of its users (e.g., keystone acting as an identity provider, ADFS, etc.) With x509 certificates, the identity provider is a certificate authority that issues and signs user certificates. Keystone needs to be configured to "trust" certificated signed by that certificate authority. When a user authenticates, keystone relies on SSL plugin libraries to validate the certificate against the root certificate authority, but this is done offline since the SSL configuration has a copy of the root certificates. >From there, the plan is to treat each trusted certificate authority as its own identity provider, so all users with certificates signed by the same authority get mapped into the same namespace/identity provider. Once the users have their signed certificate, they can authenticate for tokens without a link being established between keystone and whatever certificate authority issued the certificate. The downside is that certificate revocation and certificate distribution is now a thing you need to worry about. James might have more input there since it sounds like this is the approach they are shooting for with Athenz (which is the certificate authority in their case.) I hope that helps clear things up? [0] https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures > > - > - > > Is this correct ? > > > > Greg. > > > > > > *From: *Lance Bragstad > *Date: *Friday, January 25, 2019 at 2:16 PM > *To: *"edge-computing at lists.openstack.org" < > edge-computing at lists.openstack.org>, " > openstack-discuss at lists.openstack.org" < > openstack-discuss at lists.openstack.org> > *Subject: *[Edge-computing] [keystone] x509 authentication > > > > Hi all, > > > > We've been going over keystone gaps that need to be addressed for edge use > cases every Tuesday. Since Berlin, Oath has open-sourced some of their > custom authentication plugins for keystone that help them address these > gaps. > > > > The basic idea is that users authenticate to some external identity > provider (Athenz in Oath's case), and then present an Athenz token to > keystone. The custom plugins decode the token from Athenz to determine the > user, project, roles assignments, and other useful bits of information. > After that, it creates any resources that don't exist in keystone already. > Ultimately, a user can authenticate against a keystone node and have > specific resources provisioned automatically. In Berlin, engineers from > Oath were saying they'd like to move away from Athenz tokens altogether and > use x509 certificates issued by Athenz instead. The auto-provisioning > approach is very similar to a feature we have in keystone already. In > Berlin, and shortly after, there was general agreement that if we could > support x509 authentication with auto-provisioning via keystone federation, > that would pretty much solve Oath's use case without having to maintain > custom keystone plugins. > > > > Last week, Colleen started digging into keystone's existing x509 > authentication support. I'll start with the good news, which is x509 > authentication works, for the most part. It's been a feature in keystone > for a long time, and it landed after we implemented federation support > around the Kilo release. Chances are there won't be a need for a keystone > specification like we were initially thinking in the edge meetings. > Unfortunately, the implementation for x509 authentication has outdated > documentation, is extremely fragile, hard to set up, and hasn't been > updated with improvements we've made to the federation API since the > original implementation (like shadow users or auto-provisioning, which work > with other federated protocols like OpenID Connect and SAML). We've started > tracking the gaps with bugs [0] so that we have things written down. > > > > I think the good thing is that once we get this cleaned up, we'll be able > to re-use some of the newer federation features with x509 > authentication/federation. These updates would make x509 a first-class > federated protocol. The approach, pending the bug fixes, would remove the > need for Oath's custom authentication plugins. It could be useful for edge > deployments, or even deployments with many regions, by allowing users to be > auto-provisioned in each region. Although, it doesn't necessarily solve the > network partition issue. > > > > Now that we have an idea of where to start and some bug reports [0], I'm > wondering if anyone is interested in helping with the update or refactor. > Because this won't require a specification, we can get started on it > sooner, instead of having to wait for Train development and a new > specification. I'm also curious if anyone has comments or questions about > the approach. > > > > Thanks, > > > > Lance > > > > [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Tue Jan 29 17:55:09 2019 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 29 Jan 2019 11:55:09 -0600 Subject: [Edge-computing] [keystone] x509 authentication In-Reply-To: References: Message-ID: On Fri, Jan 25, 2019 at 3:02 PM James Penick wrote: > Hey Lance, > We'd definitely be interested in helping with the work. I'll grab some > volunteers from my team and get them in touch within the next few days. > > Awesome, that sounds great! I'm open to using this thread for more technical communication if needed. Otherwise, #openstack-keystone is always open for folks to swing by if they want to discuss things there. FWIW - we brought this up in the keystone meeting today and there several other people interested in this work. There is probably going to be an opportunity to break the work up a bit. > -James > > > On Fri, Jan 25, 2019 at 11:16 AM Lance Bragstad > wrote: > >> Hi all, >> >> We've been going over keystone gaps that need to be addressed for edge >> use cases every Tuesday. Since Berlin, Oath has open-sourced some of their >> custom authentication plugins for keystone that help them address these >> gaps. >> >> The basic idea is that users authenticate to some external identity >> provider (Athenz in Oath's case), and then present an Athenz token to >> keystone. The custom plugins decode the token from Athenz to determine the >> user, project, roles assignments, and other useful bits of information. >> After that, it creates any resources that don't exist in keystone already. >> Ultimately, a user can authenticate against a keystone node and have >> specific resources provisioned automatically. In Berlin, engineers from >> Oath were saying they'd like to move away from Athenz tokens altogether and >> use x509 certificates issued by Athenz instead. The auto-provisioning >> approach is very similar to a feature we have in keystone already. In >> Berlin, and shortly after, there was general agreement that if we could >> support x509 authentication with auto-provisioning via keystone federation, >> that would pretty much solve Oath's use case without having to maintain >> custom keystone plugins. >> >> Last week, Colleen started digging into keystone's existing x509 >> authentication support. I'll start with the good news, which is x509 >> authentication works, for the most part. It's been a feature in keystone >> for a long time, and it landed after we implemented federation support >> around the Kilo release. Chances are there won't be a need for a keystone >> specification like we were initially thinking in the edge meetings. >> Unfortunately, the implementation for x509 authentication has outdated >> documentation, is extremely fragile, hard to set up, and hasn't been >> updated with improvements we've made to the federation API since the >> original implementation (like shadow users or auto-provisioning, which work >> with other federated protocols like OpenID Connect and SAML). We've started >> tracking the gaps with bugs [0] so that we have things written down. >> >> I think the good thing is that once we get this cleaned up, we'll be able >> to re-use some of the newer federation features with x509 >> authentication/federation. These updates would make x509 a first-class >> federated protocol. The approach, pending the bug fixes, would remove the >> need for Oath's custom authentication plugins. It could be useful for edge >> deployments, or even deployments with many regions, by allowing users to be >> auto-provisioned in each region. Although, it doesn't necessarily solve the >> network partition issue. >> >> Now that we have an idea of where to start and some bug reports [0], I'm >> wondering if anyone is interested in helping with the update or refactor. >> Because this won't require a specification, we can get started on it >> sooner, instead of having to wait for Train development and a new >> specification. I'm also curious if anyone has comments or questions about >> the approach. >> >> Thanks, >> >> Lance >> >> [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509 >> _______________________________________________ >> Edge-computing mailing list >> Edge-computing at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbuil at suse.com Wed Jan 9 10:16:31 2019 From: mbuil at suse.com (Manuel Buil) Date: Wed, 09 Jan 2019 10:16:31 -0000 Subject: [Edge-computing] [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting In-Reply-To: References: <1569231DC06A0846.23762@lists.opnfv.org> , <201811271147449384076@chinamobile.com> , <156F3B766B549CBF.21862@lists.opnfv.org> , <2018121117145221586888@chinamobile.com> , <2018121220212661606146@chinamobile.com> , <2018122514385416054410@chinamobile.com> , <201812260905336684741@chinamobile.com> , <2019010909291507376211@chinamobile.com> , <2019010917064767623860@chinamobile.com> Message-ID: <1547029140.2335.5.camel@suse.com> Hi Qihui, Regarding the StarlingX integration with XCI, have you started discussions? Is there any meeting where we could dicuss this? I could help. Regards,Manuel On Wed, 2019-01-09 at 09:13 +0000, Csatari, Gergely (Nokia - HU/Budapest) wrote: > Hi, > > Thanks for the links. > > > I still think, that we should keep the Edge Pharos Specs [1] and the > Edge Cloud Site definitions [2] in the whitepaper consistent. > > > Br, > Gerg0 > > [1]: https://wiki.opnfv.org/display/EC/Edge+cloud?preview=/20745277/3 > 2015361/Edge%20Cloud_Pharos%20Spec_StarlingX.pdf > [2]: https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/developm > ent/requirements/requirements.html#edge-sites-conditions-deployment- > scenarios > > > > From: zhaoqihui at chinamobile.com > > > Sent: Wednesday, January 9, 2019 10:07 AM > > To: Csatari, Gergely (Nokia - HU/Budapest) >; fuqiao ; beth.cohen m>; Peret, Adrian (Nokia - FI/Espoo) ; > julienjut ; haojingbo ; > ildiko ; paul-andre.raymond d at b-yond.com>; trevor.cooper ; > cristina.pauna ; xiaohua.zhang g at windriver.com>; Bob.Monkman ; deepak.s .s at linux.intel.com>; > asayeed ; Tina.Tsou ; > klaus.mehler ; periyasamy.palanisamy yasamy.palanisamy at ericsson.com>; hu.jie ; kliu iu at cavium.com>; wanglu ; pvaanane > ; fanyamei ; > glenn.seiler ; huang.shuquan an at 99cloud.net>; adrien.lebre ; pierre.lynch < > pierre.lynch at keysight.com>; pj ; valentin.boucher > ; kan.hong ; > claudio_serra ; acm ; > Tikkanen, Viktor (Nokia - FI/Espoo) ; > simple_hlw ; kailun.qin ; > mark.beierl ; Manuel Buil > > Cc: opnfv-tech-discuss ; opnfv- > tsc ; edge-computing .openstack.org> > > Subject: Re: RE: [opnfv-tech-discuss] [edge cloud] Time changed for > this week's meeting > > > > > Sure. > > > > > > I have uploaded the slides onto our wiki home page: > https://wiki.opnfv.org/display/EC/Edge+cloud > > > you can find them at the bottom of the page -> "Related discussion > links and slides" -> under "January 2019 Plugfest slides" > > > > > > Best, > > > Qihui > > > > > > > > China Mobile Research Institute > > > (+86) 13810659120 > > > > > > > > > > > > > > > From: Csatari, > > Gergely (Nokia - HU/Budapest) > > > > > > Date: 2019-01-09 16:40 > > > > > > To: zhaoqihui at chinamobile.com; > > fuqiao; > > beth.cohen; Peret, Adrian (Nokia - FI/Espoo); > > julienjut; > > haojingbo; ildiko; > > paul-andre.raymond; trevor.cooper; > > cristina.pauna; > > xiaohua.zhang; Bob.Monkman; > > deepak.s; asayeed; > > Tina.Tsou; klaus.mehler; > > periyasamy.palanisamy; hu.jie; > > kliu; wanglu; > > pvaanane; fanyamei; > > glenn.seiler; huang.shuquan; > > adrien.lebre; pierre.lynch; > > pj; valentin.boucher; > > kan.hong; claudio_serra; > > acm; Tikkanen, Viktor (Nokia - FI/Espoo); > > simple_hlw; > > kailun.qin; mark.beierl; > > Manuel Buil > > > > > > CC: opnfv-tech-discuss; > > opnfv-tsc; > > edge-computing > > > > > > Subject: RE: Re: [opnfv-tech-discuss] [edge cloud] > > Time changed for this week's meeting > > > > > > > > > > > > Hi, > > > > > > Is it possible to get the presented materials in some form? > > > > Thanks, > > > > Gerg0 > > > > > > > > From: > > zhaoqihui at chinamobile.com > > > > > > Sent: Wednesday, January 9, 2019 2:29 AM > > > > To: fuqiao ; beth.cohen > .com>; Peret, Adrian (Nokia - FI/Espoo) ; > > julienjut ; haojingbo ; > > Csatari, Gergely (Nokia - HU/Budapest) ; > > ildiko ; paul-andre.raymond > ond at b-yond.com>; trevor.cooper ; > > cristina.pauna ; xiaohua.zhang > hang at windriver.com>; Bob.Monkman ; > > deepak.s ; asayeed ; > > Tina.Tsou ; klaus.mehler > com>; > > periyasamy.palanisamy ; hu.jie > > ; kliu ; wanglu > bile.com>; > > pvaanane ; fanyamei > >; glenn.seiler ; huang.shuquan > > ; adrien.lebre ; > > pierre.lynch ; pj ; > > valentin.boucher ; kan.hong > g at 99cloud.net>; claudio_serra ; > > acm ; Tikkanen, Viktor (Nokia - FI/Espoo) > iktor.tikkanen at nokia.com>; simple_hlw ; > > kailun.qin > > ; mark.beierl ; Manuel > > Buil > > > > Cc: opnfv-tech-discuss ; opnfv- > > tsc ; edge-computing > ts.openstack.org> > > > > Subject: Re: Re: [opnfv-tech-discuss] [edge cloud] Time changed for > > this week's meeting > > > > > > > > > > Hello edge cloud team, > > > > > > > > > > > > This week's meeting will be held together with the plugfest > > sessions. > > > > > > > > > > > > Time: Jan. 9th, 2019, Wednesday, UTC 07:30 ~ 09:00 > > > > > > Zoom link: https://zoom.us/j/457096090 > > > > > > > > > > > > Best, > > > > > > Qihui > > > > > > > > > > > > > > > > > > > > China Mobile Research Institute > > > > > > (+86) 13810659120 > > > > > > > > > > > > > > > > > > > > > > > > 发件人： zhaoqihui at chinamobile.com > > > > > > > > > 发送时间： 2018-12-26 09:05 > > > > > > > > > 收件人： fuqiao; > > > beth.cohen; > > > adrian.peret; julienjut; > > > haojingbo; gergely.csatari; > > > ildiko; paul-andre.raymond; > > > trevor.cooper; > > > cristina.pauna; xiaohua.zhang; > > > Bob.Monkman; > > > deepak.s; asayeed; > > > Tina.Tsou; klaus.mehler; > > > periyasamy.palanisamy; hu.jie; > > > kliu; wanglu; > > > pvaanane; fanyamei; > > > glenn.seiler; huang.shuquan; > > > adrien.lebre; pierre.lynch; > > > pj; valentin.boucher; > > > kan.hong; claudio_serra; > > > acm; viktor.tikkanen; > > > simple_hlw; kailun.qin; > > > mark.beierl; Manuel Buil > > > > > > > > > 抄送： opnfv-tech-discuss; > > > opnfv-tsc; > > > edge-computing > > > > > > > > > 主题： Re: Re: [opnfv-tech-discuss] [edge > > > cloud] Canceled：Edge Cloud Bi-weekly Meeting > > > > > > > > > > > > > > > > > > > > > As a lot of us are on vacation, today's meeting has been > > > canceled. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > China Mobile Research Institute > > > > > > > > > (+86) 13810659120 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 发件人： zhaoqihui at chinamobile.com > > > > > > > > > > > > 发送时间： 2018-12-25 14:38 > > > > > > > > > > > > 收件人： fuqiao; > > > > beth.cohen; > > > > adrian.peret; julienjut; > > > > haojingbo; gergely.csatari; > > > > ildiko; paul-andre.raymond; > > > > trevor.cooper; > > > > cristina.pauna; xiaohua.zhang; > > > > Bob.Monkman; > > > > deepak.s; asayeed; > > > > Tina.Tsou; klaus.mehler; > > > > periyasamy.palanisamy; hu.jie; > > > > kliu; wanglu; > > > > pvaanane; fanyamei; > > > > glenn.seiler; huang.shuquan; > > > > adrien.lebre; pierre.lynch; > > > > pj; valentin.boucher; > > > > kan.hong; claudio_serra; > > > > acm; viktor.tikkanen; > > > > simple_hlw; kailun.qin; > > > > mark.beierl; Manuel Buil > > > > > > > > > > > > 抄送： opnfv-tech-discuss; > > > > opnfv-tsc; > > > > edge-computing > > > > > > > > > > > > 主题： Re: Re: [opnfv-tech-discuss] [edge > > > > cloud] Canceled：Edge Cloud Bi-weekly Meeting > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Edge Cloud Team, > > > > > > > > > > > > > > > > > > > > > > > > Merry Christmas & Happy Vacation~~ > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > Qihui > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > China Mobile Research Institute > > > > > > > > > > > > (+86) 13810659120 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbuil at suse.com Thu Jan 10 12:09:50 2019 From: mbuil at suse.com (Manuel Buil) Date: Thu, 10 Jan 2019 12:09:50 -0000 Subject: [Edge-computing] [opnfv-tsc] [opnfv-tech-discuss] [edge cloud] Time changed for this week's meeting In-Reply-To: <4DD1D172-3F96-4D20-B8AC-CEC9F4A687F3@emc.com> References: <1569231DC06A0846.23762@lists.opnfv.org> <201811271147449384076@chinamobile.com> <156F3B766B549CBF.21862@lists.opnfv.org> <2018121117145221586888@chinamobile.com> <2018121220212661606146@chinamobile.com> <2018122514385416054410@chinamobile.com> <201812260905336684741@chinamobile.com> <2019010909291507376211@chinamobile.com> <2019010917064767623860@chinamobile.com> <1547029140.2335.5.camel@suse.com> <4DD1D172-3F96-4D20-B8AC-CEC9F4A687F3@emc.com> Message-ID: <1547122340.2127.39.camel@suse.com> Hey Mark, I think what the slides show is basically what was discussed (I joined 20 minutes late, so perhaps at the beginning something different was discussed). I did not take any extra notes. Regards,Manuel On Wed, 2019-01-09 at 17:09 +0000, Mark Beierl wrote: > Are there any minutes or notes taken from the XCI/StarlingX meeting? > I was not able to attend online. > > > Regards, > Mark > > Mark Beierl > SW System Sr Principal Developer > Dell EMC | > Cloud & Communication Service Provider Solution > > Mark.Beierl at Dell.com > > > From: on behalf of Manuel Buil < > mbuil at suse.com> > > Date: Wednesday, January 9, 2019 at 05:16 > > To: "Csatari, Gergely (Nokia - HU/Budapest)" om>, "zhaoqihui at chinamobile.com" , fuqiao > , "beth.cohen" , > "Peret, Adrian (Nokia - FI/Espoo)" , > julienjut , haojingbo , > ildiko , "paul-andre.raymond" nd at b-yond.com>, "trevor.cooper" , > "cristina.pauna" , "xiaohua.zhang" zhang at windriver.com>, > "Bob.Monkman" , "deepak.s" l.com>, asayeed , "Tina.Tsou" > , "klaus.mehler" , "periyasamy.palanisamy" > , "hu.jie" , > kliu , wanglu , pvaanane

vaanane at redhat.com>, fanyamei , > "glenn.seiler" , "huang.shuquan" huquan at 99cloud.net>, "adrien.lebre" , > "pierre.lynch" , pj , > "valentin.boucher" , "kan.hong" ng at 99cloud.net>, claudio_serra , acm search.att.com>, "Tikkanen, Viktor (Nokia - FI/Espoo)" > , simple_hlw , > "kailun.qin" , "Beierl, Mark" com> > > Cc: opnfv-tech-discuss , opnfv- > tsc , edge-computing .openstack.org> > > Subject: Re: [opnfv-tech-discuss] [edge cloud] Time changed for this > week's meeting > > > > > > [EXTERNAL EMAIL] > > > Hi Qihui, > > > > > > Regarding the StarlingX integration with XCI, have you started > discussions? Is there any meeting where we could dicuss this? I could > help. > > > > > > Regards, > > > Manuel > > > > > > On Wed, 2019-01-09 at 09:13 +0000, Csatari, Gergely (Nokia - > HU/Budapest) wrote: > > > Hi, > > > > Thanks for the links. > > > > I still think, that we should keep the Edge Pharos Specs [1] and > > the Edge Cloud Site definitions [2] > > in the whitepaper consistent. > > > > Br, > > Gerg0 > > > > [1]: https://wiki.opnfv.org/display/EC/Edge+cloud?preview=/20745277 > > /32015361/Edge%20Cloud_Pharos%20Spec_StarlingX.pdf > > [2]: https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/develo > > pment/requirements/requirements.html#edge-sites-conditions- > > deployment-scenarios > > > > > > > > From: zhaoqihui at chinamobile.com > > > > > > Sent: Wednesday, January 9, 2019 10:07 AM > > > > To: Csatari, Gergely (Nokia - HU/Budapest) > om>; fuqiao ; beth.cohen > n.com>; Peret, Adrian (Nokia - FI/Espoo) ; > > julienjut ; haojingbo ; > > ildiko ; paul-andre.raymond > ond at b-yond.com>; trevor.cooper ; > > cristina.pauna ; xiaohua.zhang > ang at windriver.com>; Bob.Monkman ; deepak.s > epak.s at linux.intel.com>; > > asayeed ; Tina.Tsou ; > > klaus.mehler ; periyasamy.palanisamy > riyasamy.palanisamy at ericsson.com>; hu.jie ; kliu > > ; wanglu ; pvaanane > > ; fanyamei ; > > glenn.seiler ; huang.shuquan > quan at 99cloud.net>; adrien.lebre ; > > pierre.lynch ; pj ; > > valentin.boucher > > ; kan.hong ; > > claudio_serra ; acm > > ; Tikkanen, Viktor (Nokia - FI/Espoo) ; > > simple_hlw ; kailun.qin ; > > mark.beierl ; Manuel Buil > > > > Cc: opnfv-tech-discuss ; opnfv- > > tsc ; edge-computing > ts.openstack.org> > > > > Subject: Re: RE: [opnfv-tech-discuss] [edge cloud] Time changed for > > this week's meeting > > > > > > > > > > Sure. > > > > > > > > > > > > I have uploaded the slides onto our wiki home page: > > https://wiki.opnfv.org/display/EC/Edge+cloud > > > > > > you can find them at the bottom of the page -> "Related discussion > > links and slides" -> under "January 2019 Plugfest slides" > > > > > > > > > > > > Best, > > > > > > Qihui > > > > > > > > > > > > > > > > > > > > China Mobile Research Institute > > > > > > (+86) 13810659120 > > > > > > > > > > > > > > > > > > > > > > > > From: Csatari, > > > Gergely (Nokia - HU/Budapest) > > > > > > > > > Date: 2019-01-09 16:40 > > > > > > > > > To: zhaoqihui at chinamobile.com; > > > fuqiao; > > > beth.cohen; Peret, Adrian (Nokia - FI/Espoo); > > > julienjut; > > > haojingbo; ildiko; > > > paul-andre.raymond; trevor.cooper; > > > cristina.pauna; > > > xiaohua.zhang; Bob.Monkman; > > > deepak.s; asayeed; > > > Tina.Tsou; klaus.mehler; > > > periyasamy.palanisamy; hu.jie; > > > kliu; wanglu; > > > pvaanane; fanyamei; > > > glenn.seiler; huang.shuquan; > > > adrien.lebre; pierre.lynch; > > > pj; valentin.boucher; > > > kan.hong; claudio_serra; > > > acm; Tikkanen, Viktor (Nokia - FI/Espoo); > > > simple_hlw; > > > kailun.qin; mark.beierl; > > > Manuel Buil > > > > > > > > > CC: opnfv-tech-discuss; > > > opnfv-tsc; > > > edge-computing > > > > > > > > > Subject: RE: Re: [opnfv-tech-discuss] [edge cloud] > > > Time changed for this week's meeting > > > > > > > > > > > > > > > > > > Hi, > > > > > > Is it possible to get the presented materials in some form? > > > > > > Thanks, > > > Gerg0 > > > > > > > > > > > > From: > > > zhaoqihui at chinamobile.com > > > > > > > > > Sent: Wednesday, January 9, 2019 2:29 AM > > > > > > To: fuqiao ; beth.cohen > > on.com>; Peret, Adrian (Nokia - FI/Espoo) > > >; > > > julienjut ; haojingbo > > >; Csatari, Gergely (Nokia - HU/Budapest) > > com>; > > > ildiko ; paul-andre.raymond > > ymond at b-yond.com>; trevor.cooper ; > > > cristina.pauna ; xiaohua.zhang > > .zhang at windriver.com>; Bob.Monkman ; > > > deepak.s ; asayeed > > >; Tina.Tsou ; klaus.mehler > > sson.com>; > > > periyasamy.palanisamy ; > > > hu.jie ; kliu ; wanglu > > u at chinamobile.com>; > > > pvaanane ; fanyamei > > om>; glenn.seiler ; huang.shuquan > > > ; adrien.lebre > > >; pierre.lynch ; pj ; > > > valentin.boucher ; kan.hong > > ong at 99cloud.net>; claudio_serra ; > > > acm ; Tikkanen, Viktor (Nokia - FI/Espoo) > > > ; simple_hlw ; > > > kailun.qin > > > ; mark.beierl ; > > > Manuel Buil > > > > > > Cc: opnfv-tech-discuss ; > > > opnfv-tsc ; edge-computing > > ting at lists.openstack.org> > > > > > > Subject: Re: Re: [opnfv-tech-discuss] [edge cloud] Time changed > > > for this week's meeting > > > > > > > > > > > > > > > Hello edge cloud team, > > > > > > > > > > > > > > > > > > This week's meeting will be held together with the plugfest > > > sessions. > > > > > > > > > > > > > > > > > > Time: Jan. 9th, 2019, Wednesday, UTC 07:30 ~ 09:00 > > > > > > > > > Zoom link: https://zoom.us/j/457096090 > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > Qihui > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > China Mobile Research Institute > > > > > > > > > (+86) 13810659120 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 发件人： zhaoqihui at chinamobile.com > > > > > > > > > > > > 发送时间： 2018-12-26 09:05 > > > > > > > > > > > > 收件人： fuqiao; > > > > beth.cohen; > > > > adrian.peret; julienjut; > > > > haojingbo; gergely.csatari; > > > > ildiko; paul-andre.raymond; > > > > trevor.cooper; > > > > cristina.pauna; xiaohua.zhang; > > > > Bob.Monkman; > > > > deepak.s; asayeed; > > > > Tina.Tsou; klaus.mehler; > > > > periyasamy.palanisamy; hu.jie; > > > > kliu; wanglu; > > > > pvaanane; fanyamei; > > > > glenn.seiler; huang.shuquan; > > > > adrien.lebre; pierre.lynch; > > > > pj; valentin.boucher; > > > > kan.hong; claudio_serra; > > > > acm; viktor.tikkanen; > > > > simple_hlw; kailun.qin; > > > > mark.beierl; Manuel Buil > > > > > > > > > > > > 抄送： opnfv-tech-discuss; > > > > opnfv-tsc; > > > > edge-computing > > > > > > > > > > > > 主题： Re: > > > > Re: [opnfv-tech-discuss] [edge cloud] Canceled：Edge Cloud Bi- > > > > weekly Meeting > > > > > > > > > > > > > > > > > > > > > > > > > > > > As a lot of us are on vacation, today's meeting has been > > > > canceled. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > China Mobile Research Institute > > > > > > > > > > > > (+86) 13810659120 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 发件人： zhaoqihui at chinamobile.com > > > > > > > > > > > > > > > 发送时间： 2018-12-25 14:38 > > > > > > > > > > > > > > > 收件人： fuqiao; > > > > > beth.cohen; > > > > > adrian.peret; julienjut; > > > > > haojingbo; gergely.csatari; > > > > > ildiko; paul-andre.raymond; > > > > > trevor.cooper; > > > > > cristina.pauna; xiaohua.zhang; > > > > > Bob.Monkman; > > > > > deepak.s; asayeed; > > > > > Tina.Tsou; klaus.mehler; > > > > > periyasamy.palanisamy; hu.jie; > > > > > kliu; wanglu; > > > > > pvaanane; fanyamei; > > > > > glenn.seiler; huang.shuquan; > > > > > adrien.lebre; pierre.lynch; > > > > > pj; valentin.boucher; > > > > > kan.hong; claudio_serra; > > > > > acm; viktor.tikkanen; > > > > > simple_hlw; kailun.qin; > > > > > mark.beierl; Manuel Buil > > > > > > > > > > > > > > > 抄送： opnfv-tech-discuss; > > > > > opnfv-tsc; > > > > > edge-computing > > > > > > > > > > > > > > > 主题： Re: > > > > > Re: [opnfv-tech-discuss] [edge cloud] Canceled：Edge Cloud > > > > > Bi-weekly Meeting > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Edge Cloud Team, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Merry Christmas & Happy Vacation~~ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > > Qihui > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > China Mobile Research Institute > > > > > > > > > > > > > > > (+86) 13810659120 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#4948): https://lists.opnfv.org/g/opnfv-tsc/messag > e/4948 > Mute This Topic: https://lists.opnfv.org/mt/28982870/675458 > Group Owner: opnfv-tsc+owner at lists.opnfv.org > Unsubscribe: https://lists.opnfv.org/g/opnfv-tsc/unsubb [mbuil at suse. > com] > -=-=-=-=-=-=-=-=-=-=-=- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbuil at suse.com Tue Jan 15 15:53:29 2019 From: mbuil at suse.com (Manuel Buil) Date: Tue, 15 Jan 2019 15:53:29 -0000 Subject: [Edge-computing] Status of Keystone federation testing with tempest In-Reply-To: References: , , , Message-ID: <1547567769.2225.16.camel@suse.com> Hi Gerg0, I had a K2K deployment working (I was able to fetch a token from the SP) and I tried to document all the steps: https://wiki.opnfv.org/display/EC/Keystone+Federation+demo+in+opensuse Regarding the IdP config, this is what I wrote to check that things were fine at the IdP side: # If the IdP configuration is correct, you should see the following in /var/log/apache2/keystone_access.log when the user requests the token through the federated_project: 172.29.236.11 - - [07/Nov/2018:18:53:04 +0000] "GET /v3 HTTP/1.1" 200 254 "-" "openstacksdk/0.17.2 keystoneauth1/3.10.0 python- requests/2.19.1 CPython/2.7.13" 172.29.236.11 - - [07/Nov/2018:18:53:04 +0000] "POST /v3/auth/tokens HTTP/1.1" 201 6234 "-" "openstacksdk/0.17.2 keystoneauth1/3.10.0 python-requests/2.19.1 CPython/2.7.13" 172.29.236.11 - - [07/Nov/2018:18:53:04 +0000] "POST /v3/auth/OS- FEDERATION/saml2/ecp HTTP/1.1" 200 6535 "-" "openstacksdk/0.17.2 keystoneauth1/3.10.0 python-requests/2.19.1 CPython/2.7.13" By looking at your logs it seems you are getting a config problem in Shibboleth, however, Keystone is capable of providing the SAML implementation for IdP, so in theory you don't need Shibboleth at the IdP side. Could you check the steps I followed in that link in the section "### MAKING EDGE1 IdP ###"? Have you documented the steps you have followed? Perhaps we could compare them. Regards,Manuel On Thu, 2019-01-10 at 14:50 +0000, Csatari, Gergely (Nokia - HU/Budapest) wrote: > Hi, > > > > > > Okay, the problem was with the wrong IP configuration for the > metadata fetching. > > > > Now it is sorted out, but Shibboleth is still not happy. > > > > > > > I've attached the error log I get now from the idp. > > > > > > > If you have any idea for the reason please notify me. > > > > > > > Br, > > > Gerg0 > > > > > > > > > > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: Monday, January 7, 2019 4:23:23 PM > > To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at su > se.com; edge-computing at lists.openstack.org; Ildiko Vancsa; Beierl, > Mark > > Subject: Re: Status of Keystone federation testing with tempest > > > > > > > > Hi, > > > > > > Just to send a signal, that I'm still working on this (with best > effort). > > > > > > > What I could figure out in the last some months, is that we need a > "verify=False" parameter in the session.post of > send_identity_provider_authn_request (in saml2_client.py) to be able > to connect to the IdP using self > signed certificates. > > > > > > Now I'm able to communicate with the IdP and I can see, that there is > a problem with the IdP config. > > > > This is the log of Shibboleth: > > 2019-01-07 11:33:55,165 - WARN > [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - > Profile Action SelectProfileConfiguration: Profile http://shibboleth. > net/ns/profiles/saml2/sso/ecp is not available for RP configuration > shibboleth.UnverifiedRelyingParty > (RPID http://127.0.0.1/shibboleth) > > 2019-01-07 11:33:55,167 - WARN > [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event > occurred while processing the request: InvalidProfileConfiguration > > > > > I keep debugging this and update you about the results. > > > > > > Would it help if I would push all modified things to GitHub with a > description how am I doing the configuration? > > > > > > > Br, > > > Gerg0 > > > > > > > > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: Saturday, September 15, 2018 12:36 AM > > To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at su > se.com; edge-computing at lists.openstack.org > > Subject: Re: Status of Keystone federation testing with tempest > > > > > Hi, > > > > > > Some update on the open issues: > - Make this work 😉: Okay, I realized, > that I use the wrong certificate in the Idp. Based on the IdP-s > description I should generate a p12 certificate using the certificate > and the key used by the Shibboleth Sp. When I try to generate the > certificate I get a strange error: > > > > > > > > openssl pkcs12 -inkey /etc/shibboleth/sp-key.pem -in > /etc/shibboleth/sp-cert.pem -out ../keystone-shibboleth-idp- > dockerized/shibboleth-idp/credentials/idp-browser.p12 > > > > > > > 139822780584384:error:0D0680A8:asn1 encoding > routines:asn1_check_tlen:wrong tag:../crypto/asn1/tasn_dec.c:1129: > > 139822780584384:error:0D07803A:asn1 encoding > routines:asn1_item_embed_d2i:nested asn1 > error:../crypto/asn1/tasn_dec.c:289:Type=PKCS12 > > > > > > Google tells me that this is becouse one of my pem files are in the > wrong format. This is really strange as the error persist even after > I regenerated these files with > > > > shib-keygen -f -y 1 > > > > > - Figure out how to start a Container in a > > Keystone plugin or a tempest plugin - no progress on this > - Figure out ow to integrate with CI - no progress on this > - Figure out how to use static certificates and keys, so the same > IdP container image can be used. > > > > If you are bigger fans of IRC than email I can start sending these > updates to the keystone channel. > > > > > > > Br, > > > > Gerg0 > > > > > > > > > > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: Wednesday, September 12, 2018 11:25:32 PM > > To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at su > se.com; edge-computing at lists.openstack.org > > Subject: Re: Status of Keystone federation testing with tempest > > > > > > Hi, > > > > > > Some update on the open issues. > > > > - Make this work 😉 - here I have some progress, however I can no > t explain why. Now keystone is able to reach Shibboleth and > Shibboleth answers with FatalProfileException "A valid authentication > statement was not found in the incoming message.". I continue to > figure out what is the problem. > > > > - Set the idp address in the correct place - This is done thanks > to gmann. > - Figure out how to start a Container in a > > Keystone plugin or a tempest plugin - Here I try to use https://githu > b.com/openstack/devstack-plugin-container however I'm not sure if > this > is the right tool to start containers in DevStack environment. > - Figure out ow to integrate with CI - no progress on this > > > > I'm still happy get any help either in mail, IRC or in person on the > PTG. > > > > > > > Thanks, > > > Gerg0 > > > > > > > > > > > > > > > > > From: Csatari, Gergely (Nokia - HU/Budapest) > > Sent: Friday, August 31, 2018 1:03:43 PM > > To: nick at stackhpc.com; knikolla at bu.edu; colleen at gazlene.net; mbuil at su > se.com; edge-computing at lists.openstack.org > > Subject: Status of Keystone federation testing with tempest > > > > > > > > > Hi, > > > > > > I'm working on this for a while, but as I am not a big expert of IdP, > Keysone or Tempest I have a bit slow progress. I decided to share > what I did and what are my current probelms to 1) inform the team > about the progress > 2) keep a record for myself 3) hoping for help and/or hints. > > > > So I did this: > 1) Get an Ubuntu > > > 2) Install devstack with > enable_plugin keystone git://git.openstack.org/openstack/keystone > > enable_service keystone-saml2-federation > Here I already ran into some package maangement issues due to some > libcurl3 and libcurl4 incompatibility issue what I solved using > > https://launchpad.net/~xapienz/+archive/ubuntu/curl34 > > 3) Install the Keystone tempest plugin > 4) Build a Shibboleth IdP container based on > > https://github.com/Unicon/shibboleth-idp-dockerized with the > configuration I believe is correct. I have a feeling that we will > need to set a proper organisation for this if we want to publish this > to Docker Hub. By the way is there a container registry > maintained in the OpenStack development infra? > 5) Run the container and expose 8080, 4443 and 8443 ports > This is a half success. Shibboleth contacts Keystone (or actually the > Shibboleth apache module) for metadata update, but it works only on > the first attempt. The regular updates are not working for some > reason. > > > > Also I was not able to get a positive answer from the status script > of Shibboleth itself, so i just decided to move a bit forward. > > > > 6) Set idp_url to > https://localhost:8080/idp/profile/SAML2/SOAP/ECP in > _request_unscoped_token inside the Keystone tempest plugin. Here I > have no idea where the configuration is actually stores and where > should I set this in a nice way. > 7) Run the tempest tests. Now here I get an error message which tells > me about SSL version numbers (hands.hake: Error([('SSL routines', > 'ssl3_get_record', 'wrong version number')],)",),))). > I tried to use different ssl versions with Curl, but it complains > about the lack of support in libsso. > > > > So here I am now. > > > > > > Things what I deffinetly should figure out: > > > > - Make this work 😉 > > > - Set the idp address in the correct place > - Figure out how to start a Container in a Keystone plugin or a > tempest plugin > - Figure out ow to integrate with CI > > > > > > > > > Any comments are welcome. > > > > > > Br, > > > Gerg0 > > > > > > > > > > > > > Curl 3 and 4 : Evgeny Brazgin - launchpad.net > > launchpad.net > > PPA contains libcurl4 package, which supports both libcurl3 and > libcurl4 API. > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: