- Edge-computing - lists.opendev.org

Joint sessions on Thursday at the PTG
by Ildiko Vancsa 07 Nov '19

07 Nov '19

Hi, It is a friendly reminder that we have two joint sessions at the PTG today: * meeting with the Neutron team today at 12:00pm in room 431 * meeting with the Cinder team at 1:30pm at table Austin Edge PTG etherpad: https://etherpad.openstack.org/p/PVG-ECG-PTG Thanks, Ildikó

1 0

Cyborg joint session on Wednesday (November 6) at the Shanghai PTG
by Ildiko Vancsa 05 Nov '19

05 Nov '19

Hi, Just a quick heads up that we are planning a joint session with the Cyborg project tomorrow (November 6) at 4pm at the Cyborg table (Diablo) at the PTG (https://www.openstack.org/ptg/) The objective for the discussion is to kick off the collaboration between the edge group and the Cyborg project to make sure we have a good awareness on both sides around how acceleration devices are leveraged on the edge and what we need to do to make sure the infrastructure services support the needs. Edge group PTG etherpad: https://etherpad.openstack.org/p/PVG-ECG-PTG Thanks, Ildikó

1 0

PTG cross-project session scheduling and plans
by Ildiko Vancsa 31 Oct '19

31 Oct '19

Hi, As a few people from the group are already on the road and had to skip the meeting today I’m dropping this mail as a reminder to the PTG planning. We have a few cross-project slots that are currently scheduled for Thursday, namely: * Neutron - Thursday 12:00pm - 12:30pm * Cinder - 1:30pm - A few more cross-project sessions scheduled for Friday * Ironic - Friday 1:30pm - * Airship - some time in the afternoon, check right after lunch Beyond the above you can find the currently planned topics here: https://etherpad.openstack.org/p/PVG-ECG-PTG Please reply to this thread asap if any of the cross-project sessions are colliding with other activities. Please add comments to the etherpad or reply to this thread with further questions or comments. Thanks, Ildikó

2 4

Edge call is on now
by Ildiko Vancsa 16 Oct '19

16 Oct '19

Zoom is fixed. :) https://zoom.us/j/879678938 Thanks, Ildikó

2 1

StarlingX's Use of Keystone for Kubernetes Authentication
by Waines, Greg 12 Oct '19

12 Oct '19

Hey Colleen, Ildiko asked me to summarize StarlingX’s experiences with using Keystone in STX R2.0 . Specifically summarize StarlingX’s experiences with using Keystone for Kubernetes API Authentication and Docker Registry Authentication. Greg. Background: In STX 1.0 * StarlingX managed a Baremetal OpenStack Cloud, * All the OpenStack Services, e.g. neutron, nova, cinder, etc. ... including StarlingX itself, used Keystone to authenticate, In STX 2.0 * StarlingX changed to manage a Baremetal Kubernetes Cluster, with a Containerized OpenStack Cloud running on top of Kubernetes. * The solution is now layered * StarlingX Kubernetes * Keystone * StarlingX ... authenticating with the Platform Keystone * Kubernetes ... authenticating with the Platform Keystone (intent ... but abandoned) * Docker Registry ... authenticating with the Platform Keystone * OPTIONAL Containerized OpenStack * Keystone, * Nova, Neutron, Glance, Cinder, Horizon, Heat * ... all authenticating with the OpenStack Keystone * Barbican, Telemetry (Ceilometer, Panko, Gnocchi, Aodh), Ironic * ... all authenticating with the OpenStack Keystone Use of Keystone in “StarlingX Kubernetes”: * Ironically we were using Keystone for authentication of a Baremetal Kubernetes Cluster * Normally this would be done for a Kubernetes Cluster running on top of OpenStack * i.e. the Kubernetes Cluster using services of the underlying cloud provider * e.g. using the cloud provider’s authentication services, load balancing services, storage services, etc. * ( This doesn’t have any relevance to this discussion ... just thought I’d point it out. ) * StarlingX Services authenticating with Keystone * No issues ... did it in STX 1.0 ... so no changes required. * Docker Registry authenticating with Keystone * This link: https://docs.docker.com/registry/spec/auth/token/ describes how Docker Registry token authentication works * The Authentication/Authorization Service in the above link’s diagram, MUST be a JSON Web Token Server supporting OAUTH2 interface to docker, * Docker provides an EXAMPLE of such a Token Server in its github: https://github.com/docker/distribution/tree/master/contrib/token-server , which can be copied and updated to handle your preferred authn/z backend. * Docker guy we spoke to was kind of surprised someone hadn’t done this already for keystone. * So StarlingX started with this example and built a JSON Web Token Server supporting OAUTH2 interface to docker and with a backend talking to Keystone * Located here: https://opendev.org/starlingx/containers/src/branch/master/registry-token-s… * ... we are still doing this currently. * Kubernetes API authenticating with Keystone * So we were using the Keystone Authentication and Authorization Webhooks and the Client-Keystone-Auth defined here: https://github.com/kubernetes/cloud-provider-openstack * I presented this solution in this presentation at the DENVER OPENSTACK SUMMIT https://www.dropbox.com/s/gnyf3mtyf5janq1/KubernetesMultiTenancyWithKeyston… * See slides 6,7,8 * This did not work out-of-the box circa early-2019, we had to fix the following issues: * Had to add Authentication to Armada (upstreamed) * StarlingX used Armada to manage set of helm charts for openstack * Armada did NOT support kubernetes authentication * StarlingX team added it and upstreamed it * Had to fix lock feature for Authentication in Armada (upstreamed) * After previous upstream commit to support authentication in armada, * A commit went in to Armada to support locking (for atomic transactions I think), and the commit forgot to take into account authentication, * StarlingX team fixed this commit upstream. * Had issues with expiring tokens with the client-keystone-auth * I believe that the client-auth-plugin was using a cached keystone client that was holding on to tokens that eventually expired * We put in some workaround for this ... can’t remember details. * Eventually we “generally” had this working ... except for a specific but-easily-repeatable use case, where the system would hang or fail in client-keystone-auth (being called from the StarlingX systemInventory process) * It was a path in the client-keystone-auth, where the code was trying to refresh the token in the kubernetes client, * Investigation suggested that the client-keystone-auth was not compatible with our version of eventlet(0.18.4) ... which is a few years old, * There was no way to update the token through “proper” methods. Attempting to delete the client caused the code to mysteriously freeze. If you tried to set the client to none on 1 line then set it to a new client in another line, the code would freeze as you try to set the client to none. * we managed to get it to work by digging through the internals of the client and setting a new token that way, but this was somewhat of a hack. * Since eventlet was used everywhere and we were getting close to STX 2.0 release date, we felt like it was too much risk to try and upversion it. * So, we abandoned the “Kubernetes API authentication with Keystone” work. * StarlingX Roadmap wrt Kubernetes API Authentication * Given our struggles in getting Keystone working ... a little uneasy in picking it up again, * Also Authentication requirements from StarlingX 2.0 Users of the Kubernetes Layer only, are asking for things like: * OpenID Connect (OIDC, OAuth2) type authentication, * LDAP * SAML * Integration with specific authentication platforms like: * GitHub, * LinkedIn, * Azure, * Windows Active Directory * I suspect many of these would require development in Keystone to support. * Whereas there are other existing opensource solutions that can provide that now. Greg.

2 1

PTG planning - ACTION NEEDED
by Ildiko Vancsa 11 Oct '19

11 Oct '19

Hi, I’m reaching out with a friendly reminder that it is time now to prepare for the upcoming PTG (https://www.openstack.org/ptg/) which will be held in Shanghai, November 6-8. The Edge Computing Group session is scheduled for all day Friday (November 8). We have time to discuss items that are more relevant for the working group’s activities as well as organizing cross-project sessions. I created an etherpad which has a few items there already: https://etherpad.openstack.org/p/PVG-ECG-PTG Please add ‘+1’s next to the items you are interested in discussing as well as comments or new items to talk about. We will continue the planning on the next weekly call next Tuesday (October 15). It is crucial to identify projects to have sessions with to make sure we get a chance to schedule the collaborative sessions. Please let me know if you have any questions. Thanks and Best Regards, Ildikó

1 0

FW: [ironic] FFE: Add idrac HW type Redfish virtual media boot interface
by David.Paterson＠dell.com 25 Sep '19

25 Sep '19

My associate wasn't getting much traction with this FFE and I know this group expressed interest in this feature. Please take a look and review and +1 if possible. Thanks, dp From: Pioso, Richard Sent: Monday, September 23, 2019 8:09 PM To: 'openstack-discuss(a)lists.openstack.org' Subject: [ironic] FFE: Add idrac HW type Redfish virtual media boot interface Hi, I request a late feature freeze exception (FFE) for https://review.opendev.org/#/c/672498/ -- "Add Redfish vmedia boot interface to idrac HW type". There is high demand from operators for this feature. They would be delighted if it were included in Train. We believe it is a low risk change, because of the following: 1) It affects only the idrac hardware type. 2) The highest priority boot interfaces supported by the idrac hardware type remain so. 'ipxe' and 'pxe' continue to have the highest priority, and the new 'idrac-redfish-virtual-media' has the lowest priority. The new order from highest to lowest priority is 'ipxe', 'pxe', and 'idrac-redfish-virtual-media'. 3) The new interface is based on and almost entirely leverages an already merged interface implementation, 'redfish-virtual-media'. [1] Please let me know if you have any concerns or questions. Thank you for your consideration. Rick [1] https://review.opendev.org/#/c/638453/

1 0

OSF Edge Whitepaper update
by Ildiko Vancsa 20 Sep '19

20 Sep '19

Hi, First of all thanks to all of you who signed up to be an author for our second whitepaper. We have 12 volunteers so far which means that I think we have reached the limits of a group size with which we can effectively work on the paper. With that said if you are just catching up and would like to participate please reach out to me or reply to this thread to see how we can still have you involved. You can find details and current plans on this etherpad: https://etherpad.openstack.org/p/osf-ecg-second-whitepaper We plan our next call for next Monday (September 23) at 1300 UTC, further details are on the etherpad. Please let me know if you have any questions. Thanks and Best Regards, Ildikó

1 0

[ndnSIM] CFP [Deadline Extended]: 1st ACM CoNEXT Workshop on Emerging in-Network Computing Paradigms (ENCP’19)
by Reza Tourani 19 Sep '19

19 Sep '19

(Apologies if you have received multiple copies of this email) The paper submission deadline was extended to accommodate the extension requests received from several authors. Dear Colleagues, Please consider contributing to the 1st ACM CoNEXT Workshop on Emerging in-Network Computing Paradigms (ENCP’19) to be held on 9 December 2019; Orlando, FL, USA. Workshop links: http://www.cs.umsl.edu/~encp19/ <https://nam01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.umsl.…> , https://conferences2.sigcomm.org/co-next/2019/#!/workshop-encp <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconferenc…> Scope and Topic List The integration of computing and networking is considered a promising direction to fulfill the strict low latency and high data exchange requirements of a number of new and innovative application use-cases (e.g., augmented/virtual reality, autonomous driving, drone coverage). Context-aware networking can help maximize the compute utilization at the edge increasing the network capacity. For instance, network functions may enable intelligent distribution of tasks to resources, the reuse of results from previously executed tasks, adaptability to the dynamic nature of edge ecosystems (e.g., network dynamics, bursty rates of tasks, dynamic resource availability). The ENCP workshop has the integration of networking and computing as the central theme with a focus on mechanisms for the joint optimization of networking and computing resources, infrastructure virtualization, in-network caching, compute reuse, and security and privacy concerns. The ENCP workshop has the goal of serving as a venue, where minds from the Distributed Computing, Information-Centric Networking (ICN), Network Function Virtualization (NFV), Software-Defined Networking (SDN), Edge Computing communities meet to advance the state-of-the-art in the area of systems for In-Network Computing. The workshop welcomes submissions from researchers and practitioners from academia and industry, who explore challenges and advances in architectures, algorithms, protocols, middleware, and technologies in the current or the future clean-slate Internet. We also encourage work-in-progress and position papers that describe original ideas, present new directions, or have the potential to stimulate insightful discussions. ENCP invites submissions of unpublished work on the following topics (but not limited to): • Architectures of in-network computing • In-network caching solutions • Virtualization for in-network computing systems • Network Function Virtualization (NFV) for in-network computing • Security, privacy, trust management, and access control in in-network computing architectures • Information-Centric Networking (ICN) for in-network computing • Software-Defined Networking for in-network computing • In-network computing for challenged networks (e.g., disaster scenarios) • Deployment and interoperability with traditional network architectures/functions • Network slicing for in-network computing systems • Internet of Things (IoT) for in-network computing • Pricing and billing in in-network computing systems • Highly available in-network computing systems • Management of in-network computing systems • In-network computing in the era of 5G • Scalability, performance advancements, and fault-tolerance • Tools for troubleshooting, monitoring, and validation of in-network computing systems and architectures • Innovative applications that in-network computing enables • In-network computing in public and private clouds, as well as edge computing paradigms • Resource allocation, modeling, and analysis • Applications of machine learning to in-network computing • Microservice architectures • Distributed consensus algorithms • Data processing frameworks Important dates Paper submission deadline: September 23, 2019 (11:59PM EDT) Acceptance notification: October 10, 2019 Camera-ready deadline: October 17, 2019 Workshop date: December 9, 2019 Submission details The workshop solicits papers written in the standard (2-column, 10pt ACM format). All the submissions will be double-blind and will be peer-reviewed. Per the anonymity guide, authors must remove their own names and any other information that may identify themselves to the reviewers. Submissions should be no more than 6 pages (including references, appendix, and all figures). The submission links will be announced shortly. — Best Regards, Abderrahmen Mtibaa, Spyridon Mastorakis, and Dirk Kutscher ENCP'19 General Chairs

1 0

Re: [Edge-computing] Lab requirements collection
by Waines, Greg 17 Sep '19

17 Sep '19

Agreed I did volunteer. I can put something together for next week’s meeting. Greg. From: "ANDREAS.FLORATH(a)TELEKOM.DE" <ANDREAS.FLORATH(a)TELEKOM.DE> Date: Friday, May 31, 2019 at 5:58 AM To: "gergely.csatari(a)nokia.com" <gergely.csatari(a)nokia.com>, "edge-computing(a)lists.openstack.org" <edge-computing(a)lists.openstack.org> Cc: "matthias.britsch(a)telekom.de" <matthias.britsch(a)telekom.de> Subject: Re: [Edge-computing] Lab requirements collection Hello! We are also waiting that somebody asks for hardware ;-) IMHO Greg volunteered to collect requirements: https://etherpad.openstack.org/p/edge-wg-ptg-preparation-denver-2019 > ACTION(gwaines): Put together requirements and start collecting an inventory of hardware that can be used for a testing lab > Requirements for both distributed and centralized MVPs > Greg Waines, greg.waines(a)windriver.com, GregWaines, in person Kind regards Andre ________________________________ From: Csatari, Gergely (Nokia - HU/Budapest) <gergely.csatari(a)nokia.com> Sent: Tuesday, May 28, 2019 17:05 To: edge-computing(a)lists.openstack.org Subject: [Edge-computing] Lab requirements collection Hi, During the PTG sessions we agreed that we will try to build and verify the minimal reference architectures (formally known as MVP architectures). We also discovered, that we might need to have some hardware for this. Some companies were kind enough to promise some hardware resource for us if we can define the “lab requirements” for these. There was someone in the room who volunteered for this task, but unfortunatelly I forgot the name. Can someone please remind me who was the kind person to volunteer for this task? Thanks, Gerg0

3 5