[Sandbox] Radius
jonvsm opened this issue · comments
Application contact emails
rynowak@microsoft.com, aaron.crawfis@microsoft.com, jonsmit@microsoft.com, ryanwaite@microsoft.com
Project Summary
Radius is an open-source, cloud-native application platform for cloud and on-premises environments.
Project Description
Radius is a cloud-native application platform that helps developers, and the platform engineers that support them, to collaborate on delivering and managing cloud-native applications that follow organizational best practices for cost, operations, and security, by default. Radius supports deploying applications across private cloud, Microsoft Azure, and Amazon Web Services, with more cloud providers to come.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/radius-project
Project repo URL in scope of application
https://github.com/radius-project/radius
Additional repos in scope of the application
https://github.com/radius-project/docs
https://github.com/radius-project/recipes
Website URL
Roadmap
https://github.com/orgs/radius-project/projects/8/views/1
Roadmap context
See this blog post for Radius Roadmap context Introducing the Radius feature roadmap | Radius Blog (radapp.io). Note that Radius maintainers review and refine the roadmap monthly, based on community feedback.
Contributing Guide
https://github.com/radius-project/radius/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/radius-project/radius/blob/main/CODE_OF_CONDUCT.md
Adopters
No response
Contributing or Sponsoring Org
Microsoft
Maintainers file
https://github.com/radius-project/community/blob/main/MAINTAINERS.md
IP Policy
- If the project is accepted, I agree the project will follow the CNCF IP Policy
Trademark and accounts
- If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF
Why CNCF?
The CNCF has sponsored multiple projects that are complimentary to Radius, per the integration discussion below. As a result, we see the CNCF community as critical to the future evolution, adoption and usage of Radius, including encouraging third-party contributions and extensions.
Benefit to the Landscape
Per the details below, Radius solves a common set of challenges related to cloud-native application delivery that many at-scale platform engineering teams are beginning to tackle via proprietary, in-house solutions. By donating Radius as an open-source project, the community can collectively deliver a single solution that will serve the ecosystem at large.
The evolution of cloud computing has increased the speed of innovation for many organizations, whether they are building second and third-tier applications or complex microservice-based applications. Cloud native technologies like Kubernetes have made building applications that can run anywhere easier. At the same time, many applications have become more complex, and managing them in the cloud is increasingly difficult, as companies build cloud-native applications composed of interconnected services and deploy them to multiple public clouds and their private infrastructure. While Kubernetes is a key enabler, we see many users building abstractions over Kubernetes, usually focused on compute, to work around its limitations: Kubernetes has no formal definition of an application, it mingles infrastructure and application concepts, and it is overwhelmingly complex. Developers also inevitably realize their applications require much more than Kubernetes, including support for dependencies like application programming interface (API) front ends, key-value stores, caches, and observability systems. Amidst these challenges for developers, their corporate IT counterparts also must enforce an ever-growing matrix of corporate standards, compliance, and security requirements, while still enabling rapid application innovation.
Many enterprise platform engineering teams across the industry prefer to contribute to an open source project to address these challenges, rather than building and maintaining their own proprietary solutions. Many of those same enterprises are multi-cloud and require solutions that work well on any public cloud as well as on-premises. So, Radius is open-source and multi-cloud from the start. It was designed to address the distinct but related challenges that arise across development and operations as companies continue their journey to the cloud. Radius meets application teams where they are by supporting proven technologies like Kubernetes, existing infrastructure tools including Terraform and Bicep, and by integrating with existing continuous integration and continuous delivery (CI/CD) systems like GitHub Actions. Radius supports multi-tier web-plus-data to complex microservice applications.
Cloud Native 'Fit'
Radius fits within the “Application Definition & Image Build” section of the CNCF landscape.
Cloud Native 'Integration'
Radius complements and can be composed with multiple existing CNCF projects, including but not limited to Kubernetes, Ingress controllers, cert-manager, CSI-Drivers, cloud vendor IAM technologies, KEDA, Dapr and Crossplane. Our goal is not to replace these technologies but to make their use simpler.
Radius applications are deployed to Radius environments which run on a Kubernetes cluster. This can be done using Kubernetes YAML or Helm Charts. This can also be done using our abstraction-layer/API from a tool like Bicep.
KEDA enables auto-scaling of Radius applications.
Dapr helps developers write microservices with best practices, abstraction, and portability. Radius does the same for defining application architecture. Radius and Dapr strongly complement each other: Radius works with Dapr, simplifying Dapr configuration. Together, they enable, not just portable code, but portable applications.
Radius is not opinionated about Infrastructure as Code technologies and currently supports both Bicep and Terraform IaC languages. Based on community interest we will support additional integrations such as Helm, Pulumi or Crossplane for resource management.
Cloud Native Overlap
We do not see significant overlap with other CNCF projects. While some may perceive overlap between Crossplane and Radius, the two are complementary and can be integrated to work together per comments above. Infrastructure as code tools are usually unopinionated and work by calling cloud resource management APIs with a low-to-medium level of abstraction. These tools are primarily targeted at platform engineers and operations experts.
Our focus in Radius is enabling developer productivity for application deployment and management through a high-level-of-abstraction self-service workflow based around our concepts of Recipes and Environments. Recipes could be implemented using a variety of infrastructure as code tools, and build upon the support that has already been embraced by the operations community.
The following areas are out of scope for Radius and users should use existing technologies:
- Writing application code: Radius is not a programming model and does not provide an SDK or libraries. This is in contrast with technologies like Dapr.
- Building and pushing containers: Radius has no opinions about the technologies used to create or store containers. Radius can be used with existing technologies in this space.
- CI/CD or Gitops: Radius is not a CI/CD or deployment pipeline technology. Radius can be used with existing technologies in this space.
- Application Delivery pipelines (eg: canary rollouts): Radius can be used with existing technologies in this space.
- Service catalogs (eg: backstage): Radius provides an API that can be integrated with existing technologies like service catalogs.
Similar projects
Radius and the Open Application Model (OAM) share several concepts regarding how to define a cloud native application. OAM, however, is a specification whereas Radius is an actual implementation of a cloud native application platform. OAM has relatively hard dependencies on Kubernetes. In contrast, Radius supports Kubernetes today but was designed from the ground up to support a range of future runtimes, such as serverless, as they inevitably evolve over time.
Landscape
No
Business Product or Service to Project separation
There is currently no hosted product or service based on this project. Radius is only an open-source project offering self-hosted environments.
Project presentations
This video captures a recent presentation of Radius: https://youtu.be/8DdLzNfefxY
Also see this Linux Foundation Members Summit keynote: https://www.youtube.com/live/kuRyYJaXThY?feature=share
Project champions
Lachie Evenson (Microsoft), Chris Aniszczyk (CNCF), Melissa Smolensky (CNCF)
Additional information
As an addendum to the initial submission, here’s an update on Radius Community engagement efforts as of 3/13/2024.
The Radius team announced the open-sourcing of Radius at the Linux Foundation Member Summit on in October 2023, the day after this Sandbox submission. Since then, the team has been very focused on community engagement. To that end, we have the following in place.
Discord - We provide support to the Radius Community via this Discord Server. We have ~728 members @discord. Users have engaged in Discord channels with questions regarding Radius concepts, how Radius relates to other technologies, troubleshooting assistance as well as advice on how to apply Radius in specific enterprise scenarios. Feedback on Radius features and bugs are added to the Radius repositories which are triaged twice weekly by the Radius triage team and the feedback regarding documentation gaps are captured in our docs board which is prioritized in the weekly doc reviews.
GitHub - Community members can submit Issues and PRs at http://github.com/radius-project. The main Radius repository has received ~1300 GitHub stars. We have a total of ~70 community contributors who have made over ~300 contributions to Radius, for both code and document changes. (Note these contributions are measured by CNCF standards and include the following GitHub events: PR open/close and reviews, issue open/close, comments on PRs/issues and commits.) Community members have fixed ~7 good-first issues, which involved resolving bugs and adding Radius features.
Website - Since open-sourcing Radius, ~32k unique users have visited the Radius website (radapp.io) and ~24k unique users have visited the docs website (docs.radapp.io)
Weekly Radius “Office Hours” – anyone in the community interested in engaging the Radius team directly on specific questions can schedule a 15min “Office Hours” session on Wednesday of any given week.
Monthly Community Call - Radius releases every month. After each monthly release we hold a community call open to anyone interested in learning the latest about Radius and demoing work with are doing with Radius and contributions to Radius.
Please join us on Discord, GitHub, Office Hours and the Monthly Community Calls!
Hello, @jonvsm and all Radius maintainers,
As part of CNCF TAG Runtime, I am reaching out to you to present/discuss Radius at one of our meetings since you have applied for Sandbox.
It would be great to learn about the roadmap of the project, tech, community, and the general overview.
If you are interested, there is a slot on November 2nd on our agenda. Please feel free to add it to the agenda or reach out to us in the #tag-runtime channel on the CNCF slack.
Thanks!
This project should be managed by TAG App Delivery like Crossplane, Helm and Atlantis (#60), though no problem with presenting to TAG Runtime too! @helayoty you could also join TAG App Delivery's session on it.
@jonvsm would you all be able to present to TAG App Delivery in one of our weekly meetings? Here is our running agenda/notes. Our next open slot is probably 12/6, unless you could meet at our project meeting at Kubecon on Monday 11/6?
Here's the tracking issue within TAG App Delivery: cncf/tag-app-delivery#481
@joshgav, Thank you! Yes, we'll be at Kubecon so meeting there on Monday 11/6 would be great. I don't see what time that meeting takes place. If you can let me know the time and location on Mon 11/6 I'll confirm myself and relevant colleagues can be there. We look forward to meeting the TAG App Delivery and sharing more details about Radius. Thanks!
@jonvsm that would be great! Our meeting is listed here: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/project-engagement/ from 8-12 on Monday. It's to be at the Marriott AFAIK but we don't have the final room yet - I'll share when we do. If you're not already please join CNCF Slack at https://slack.cncf.io/ and I'll ping you there with more details as they come in.
Do you think you could present at about 9am local time on Radius? Or could be 11am if that's better. Let's set aside at least 30m for you, I really want us to dive in! Thanks.
@joshgav, yes, we can do 9am, Mon 11/6. We could also do 11 if that is better for you. See you on Slack :)
Thanks for finding me on Slack @jonvsm :D. Let's do 9am on Monday 11/6 to maximize the time for Radius. Looking forward!
So! It's actually best to do this in a normal TAG App Delivery session, @joshgav - project meetings are not recorded or live streamed, and the TOC will want to have a recording for sandbox applications to review.
Thanks @amye. We'll be okay as we plan to live stream our project meeting and post the recording.
+1
With the caveat that the CNCF has no opinions on project naming and this will not affect your Sandbox evaluation: are you sure that RADIUS auth is sufficiently dead that you don't have to worry about project name confusion?
Hi Jberkus,
Thanks for reaching out on the naming question. We wanted to be thoughtful about the name and took a time/space approach. First, from a time perspective the RADIUS protocol was established in 1991 and was enormously popular during the dialup Internet connection era. It's 30 years later and Internet connectivity has evolved. From a space perspective, we also felt like dialup authentication and cloud-native application development are really dissimilar parts of the industry. The Radius project (https://github.com/radius-project) is so dissimilar from the Remote Authentication Dial In User Service (RADIUS) and what the two accomplish is so different that they are readily distinguishable. Based on our customer engagements and communications to date, we’ve not seen folks confused about the two technologies so we are comfortable with the name going forward. Thanks again, Jonathan
Hi all! The Radius team presented to TAG App Delivery a couple months ago at Kubecon and we've posted the recording, the presentation deck and notes in cncf/tag-app-delivery#481 (comment).
There were comparisons made to OAM and Score (see #79) and though we didn't seek official consensus it seems Radius is a fit for CNCF sandbox. It's a project built on Kubernetes that provides an orchestrator (or control plane) for managing all types of cloud resources in and out of K8s itself.
@jonvsm Hi, RADIUS person here. I've been doing RADIUS for 27+ years, and am "the" RADIUS guy on the net (for good or bad). I've also known the MS RADIUS / WiFi team for a while. We've had all positive interactions.
A comment like the following does need a bit of clarification:
From a time perspective the RADIUS protocol was established in 1991 and was enormously popular during the dialup Internet connection era. It's 30 years later and Internet connectivity has evolved.
In a word: "nope".
In longer words, every single ISP on the planet is still using RADIUS, for pretty much everything. (Not cell service, that's different). But DSL, WiFi, VPN access, admin login to switches / routers. I could go on. Millions of students get online every day with Eduroam. That's all RADIUS, and most of it runs my software. The use-cases for RADIUS are growing over time, not shrinking.
Based on our customer engagements and communications to date, we’ve not seen folks confused about the two technologies
I agree. So few people know anything about RADIUS, that most people aren't even aware that it exists.
But that doesn't change the fact that it's still in active use. And if RADIUS went away, we likely wouldn't be having this conversation, because both of us would be offline.
Just FYI.
If in the space perspective I can lightly agree, for the time perspective I strongly disagree.
As it happens for Ipv6 (protocol "established" only 7 years later in the past 1998), both protocols are far from being decommissioned from the Internet.
Role based access to network equipment is currently actively managed by radius, tacacs (older) , diameter (newer) protocols.
Also cellular networks rely on Radius to work. In my knowledge only 5G networks switched to Diameter.
Dial-in in radius is unused as mandatory ipsec in IPv6. This do not mean they are dead protocols.
As @alandekok said also a lot of active roaming worldwide networks rely on radius, probably the bigger one being eduroam.
First, from a time perspective the RADIUS protocol was established in 1991 and was enormously popular during the dialup Internet connection era. It's 30 years later and Internet connectivity has evolved. From a space perspective, we also felt like dialup authentication and cloud-native application development are really dissimilar parts of the industry.
Steering conversation back to the right track :) getting started is here - https://docs.radapp.io/getting-started/
/vote-sandbox
Vote created
@castrojo has called for a vote on [Sandbox] Radius (#65).
The members of the following teams have binding votes:
| Team |
|---|
| @cncf/cncf-toc |
Non-binding votes are also appreciated as a sign of support!
How to vote
You can cast your vote by reacting to this comment. The following reactions are supported:
| In favor | Against | Abstain |
|---|---|---|
| 👍 | 👎 | 👀 |
Please note that voting for multiple options is not allowed and those votes won't be counted.
The vote will be open for 7days. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.
/check-vote
Vote status
So far 45.45% of the users with binding vote are in favor (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 5 | 0 | 0 | 6 |
Binding votes (5)
| User | Vote | Timestamp |
|---|---|---|
| TheFoxAtWork | In favor | 2024-04-09 21:49:40.0 +00:00:00 |
| dims | In favor | 2024-04-09 17:37:50.0 +00:00:00 |
| cathyhongzhang | In favor | 2024-04-09 16:12:37.0 +00:00:00 |
| kgamanji | In favor | 2024-04-10 16:17:56.0 +00:00:00 |
| rochaporto | In favor | 2024-04-09 18:40:44.0 +00:00:00 |
| @mauilion | Pending | |
| @linsun | Pending | |
| @dzolotusky | Pending | |
| @kevin-wangzefeng | Pending | |
| @nikhita | Pending | |
| @erinaboyd | Pending |
Non-binding votes (13)
| User | Vote | Timestamp |
|---|---|---|
| itpropro | In favor | 2024-04-09 16:29:31.0 +00:00:00 |
| rynowak | In favor | 2024-04-09 16:31:36.0 +00:00:00 |
| willtsai | In favor | 2024-04-09 16:33:27.0 +00:00:00 |
| Reshrahim | In favor | 2024-04-09 16:33:44.0 +00:00:00 |
| kachawla | In favor | 2024-04-09 16:33:58.0 +00:00:00 |
| alohaninja | In favor | 2024-04-09 16:35:01.0 +00:00:00 |
| vishwahiremat | In favor | 2024-04-09 16:36:33.0 +00:00:00 |
| josephaw1022 | In favor | 2024-04-09 16:38:25.0 +00:00:00 |
| ytimocin | In favor | 2024-04-09 16:38:29.0 +00:00:00 |
| superbeeny | In favor | 2024-04-09 16:38:43.0 +00:00:00 |
| willdavsmith | In favor | 2024-04-09 16:40:47.0 +00:00:00 |
| ryanwaite | In favor | 2024-04-09 16:41:32.0 +00:00:00 |
| jonvsm | In favor | 2024-04-10 19:16:42.0 +00:00:00 |
/check-vote
Vote status
So far 63.64% of the users with binding vote are in favor (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 7 | 0 | 0 | 4 |
Binding votes (7)
| User | Vote | Timestamp |
|---|---|---|
| rochaporto | In favor | 2024-04-09 18:40:44.0 +00:00:00 |
| linsun | In favor | 2024-04-11 10:33:08.0 +00:00:00 |
| cathyhongzhang | In favor | 2024-04-09 16:12:37.0 +00:00:00 |
| TheFoxAtWork | In favor | 2024-04-09 21:49:40.0 +00:00:00 |
| nikhita | In favor | 2024-04-12 9:29:45.0 +00:00:00 |
| kgamanji | In favor | 2024-04-10 16:17:56.0 +00:00:00 |
| dims | In favor | 2024-04-09 17:37:50.0 +00:00:00 |
| @mauilion | Pending | |
| @dzolotusky | Pending | |
| @kevin-wangzefeng | Pending | |
| @erinaboyd | Pending |
Non-binding votes (14)
| User | Vote | Timestamp |
|---|---|---|
| itpropro | In favor | 2024-04-09 16:29:31.0 +00:00:00 |
| rynowak | In favor | 2024-04-09 16:31:36.0 +00:00:00 |
| willtsai | In favor | 2024-04-09 16:33:27.0 +00:00:00 |
| Reshrahim | In favor | 2024-04-09 16:33:44.0 +00:00:00 |
| kachawla | In favor | 2024-04-09 16:33:58.0 +00:00:00 |
| alohaninja | In favor | 2024-04-09 16:35:01.0 +00:00:00 |
| vishwahiremat | In favor | 2024-04-09 16:36:33.0 +00:00:00 |
| josephaw1022 | In favor | 2024-04-09 16:38:25.0 +00:00:00 |
| ytimocin | In favor | 2024-04-09 16:38:29.0 +00:00:00 |
| superbeeny | In favor | 2024-04-09 16:38:43.0 +00:00:00 |
| willdavsmith | In favor | 2024-04-09 16:40:47.0 +00:00:00 |
| jonvsm | In favor | 2024-04-10 19:16:42.0 +00:00:00 |
| sk593 | In favor | 2024-04-10 20:22:18.0 +00:00:00 |
| ryanwaite | In favor | 2024-04-12 21:04:34.0 +00:00:00 |
/check-vote
Vote status
So far 63.64% of the users with binding vote are in favor (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 7 | 0 | 0 | 4 |
Binding votes (7)
| User | Vote | Timestamp |
|---|---|---|
| dims | In favor | 2024-04-09 17:37:50.0 +00:00:00 |
| TheFoxAtWork | In favor | 2024-04-09 21:49:40.0 +00:00:00 |
| nikhita | In favor | 2024-04-12 9:29:45.0 +00:00:00 |
| rochaporto | In favor | 2024-04-09 18:40:44.0 +00:00:00 |
| kgamanji | In favor | 2024-04-10 16:17:56.0 +00:00:00 |
| cathyhongzhang | In favor | 2024-04-09 16:12:37.0 +00:00:00 |
| linsun | In favor | 2024-04-11 10:33:08.0 +00:00:00 |
| @mauilion | Pending | |
| @dzolotusky | Pending | |
| @kevin-wangzefeng | Pending | |
| @erinaboyd | Pending |
Non-binding votes (15)
| User | Vote | Timestamp |
|---|---|---|
| itpropro | In favor | 2024-04-09 16:29:31.0 +00:00:00 |
| rynowak | In favor | 2024-04-09 16:31:36.0 +00:00:00 |
| willtsai | In favor | 2024-04-09 16:33:27.0 +00:00:00 |
| Reshrahim | In favor | 2024-04-09 16:33:44.0 +00:00:00 |
| kachawla | In favor | 2024-04-09 16:33:58.0 +00:00:00 |
| alohaninja | In favor | 2024-04-09 16:35:01.0 +00:00:00 |
| vishwahiremat | In favor | 2024-04-09 16:36:33.0 +00:00:00 |
| josephaw1022 | In favor | 2024-04-09 16:38:25.0 +00:00:00 |
| ytimocin | In favor | 2024-04-09 16:38:29.0 +00:00:00 |
| superbeeny | In favor | 2024-04-09 16:38:43.0 +00:00:00 |
| willdavsmith | In favor | 2024-04-09 16:40:47.0 +00:00:00 |
| jonvsm | In favor | 2024-04-10 19:16:42.0 +00:00:00 |
| sk593 | In favor | 2024-04-10 20:22:18.0 +00:00:00 |
| ryanwaite | In favor | 2024-04-12 21:04:34.0 +00:00:00 |
| Philess | In favor | 2024-04-14 21:05:00.0 +00:00:00 |
Vote closed
The vote passed! 🎉
72.73% of the users with binding vote were in favor (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 8 | 0 | 0 | 3 |
Binding votes (8)
| User | Vote | Timestamp |
|---|---|---|
| @cathyhongzhang | In favor | 2024-04-09 16:12:37.0 +00:00:00 |
| @linsun | In favor | 2024-04-11 10:33:08.0 +00:00:00 |
| @nikhita | In favor | 2024-04-12 9:29:45.0 +00:00:00 |
| @dims | In favor | 2024-04-09 17:37:50.0 +00:00:00 |
| @rochaporto | In favor | 2024-04-09 18:40:44.0 +00:00:00 |
| @kgamanji | In favor | 2024-04-10 16:17:56.0 +00:00:00 |
| @dzolotusky | In favor | 2024-04-15 18:27:07.0 +00:00:00 |
| @TheFoxAtWork | In favor | 2024-04-09 21:49:40.0 +00:00:00 |
Non-binding votes (15)
| User | Vote | Timestamp |
|---|---|---|
| @itpropro | In favor | 2024-04-09 16:29:31.0 +00:00:00 |
| @rynowak | In favor | 2024-04-09 16:31:36.0 +00:00:00 |
| @willtsai | In favor | 2024-04-09 16:33:27.0 +00:00:00 |
| @Reshrahim | In favor | 2024-04-09 16:33:44.0 +00:00:00 |
| @kachawla | In favor | 2024-04-09 16:33:58.0 +00:00:00 |
| @alohaninja | In favor | 2024-04-09 16:35:01.0 +00:00:00 |
| @vishwahiremat | In favor | 2024-04-09 16:36:33.0 +00:00:00 |
| @josephaw1022 | In favor | 2024-04-09 16:38:25.0 +00:00:00 |
| @ytimocin | In favor | 2024-04-09 16:38:29.0 +00:00:00 |
| @superbeeny | In favor | 2024-04-09 16:38:43.0 +00:00:00 |
| @willdavsmith | In favor | 2024-04-09 16:40:47.0 +00:00:00 |
| @jonvsm | In favor | 2024-04-10 19:16:42.0 +00:00:00 |
| @sk593 | In favor | 2024-04-10 20:22:18.0 +00:00:00 |
| @ryanwaite | In favor | 2024-04-12 21:04:34.0 +00:00:00 |
| @Philess | In favor | 2024-04-14 21:05:00.0 +00:00:00 |
Heya @jonvsm!
Welcome aboard! We're very excited to get you onboarded as a CNCF sandbox project! Here's the link to your onboarding checklist: cncf/toc#1303
That issue is where you can communicate any questions or concerns you might have. Please don't hesitate to reach out!
"First, from a time perspective the RADIUS protocol was established in 1991 and was enormously popular during the dialup Internet connection era. It's 30 years later and Internet connectivity has evolved."
RADIUS is about as dead as IPv4, SAML, or Kerberos (read its derivative AD). That is to say, to think it is dead is to be very, very mistaken. Hundreds of millions of users use all of those every day still. I'd urge you to seriously rethink and reconsider your position.
With the onboarding issue created at: cncf/toc#1303
I'm going to go ahead and close this out. 👍
Thanks!