Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: route group #431

Closed
2 of 5 tasks
liuxiran opened this issue Aug 31, 2020 · 12 comments
Closed
2 of 5 tasks

Feature: route group #431

liuxiran opened this issue Aug 31, 2020 · 12 comments
Assignees

Comments

@liuxiran
Copy link
Contributor

liuxiran commented Aug 31, 2020

Please answer these questions before submitting your issue.

  • Why do you submit this issue?
  • Question or discussion
  • Bug
  • Requirements
  • Feature or performance improvement
  • Other

Question

  • What do you want to know?

Bug

  • Which version of Apache APISIX Dashboard, OS, and Browser?

  • What happened?
    If possible, provide a way to reproduce the error.


Requirement or improvement

  • Please describe your requirements or improvement suggestions.

When multiple projects coexist, it is not convenient if I want to manage all the routes under this project, or to monitor these routes relative to the project in the future. So I think it would be better to add a route group ,when create a route , associate it with this group. it would be convenient to find routes, to manage routes` resources or to do monitor.

@moonming
Copy link
Member

@liuxiran cool, that will be very useful for hundreds of routes.
How about add tag for route, service? which is more flexible, a route can have multiple tags

@liuxiran
Copy link
Contributor Author

@liuxiran cool, that will be very useful for hundreds of routes.
How about add tag for route, service? which is more flexible, a route can have multiple tags

tag would be a more flexible and more fine-grained solution👍, user can it`s also useful for other modules like upstream and so on.

And above tag, group would be closer to management, especially when there many users of different roles(dashboard could not have users only with one role), and many projects in this gateway, group would conveniently help us complete the division of route permissions.

In fact, group + tag would be more perfectly, but tag may heavly reliance on database,as you have plane to replace the mysql,I think group may go first...

@moonming
Copy link
Member

moonming commented Aug 31, 2020 via email

@liuxiran
Copy link
Contributor Author

k8s supports tag too, so I think APISIX supports tag is easy:) Thanks, Ming Wen Twitter: _WenMing liuxiran notifications@github.com 于2020年8月31日周一 下午4:44写道:

@liuxiran https://github.com/liuxiran cool, that will be very useful for hundreds of routes. How about add tag for route, service? which is more flexible, a route can have multiple tags tag would be a more flexible and more fine-grained solution, user can it`s also useful for other modules like upstream and so on. And above tag, group would be closer to management, especially when there many users of different roles(dashboard could not have users only with one role), and many projects in this gateway, group would conveniently help us complete the division of route permissions. In fact, group + tag would be more perfectly, but tag may heavly reliance on database,as you have plane to replace the mysql,I think group may go first... — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#431 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGJZBK635TFDDZ2N45FN7LLSDNPF5ANCNFSM4QQDJJTA .

wow~ It would be better that APISIX can supports tag~!! At the same time, we commit prs which enable apisix-dashboard to support group.
BTW If you plan to add tag functionality to APISIX, my partners and I would like to contribute to it :)

@moonming
Copy link
Member

moonming commented Aug 31, 2020 via email

@imjoey
Copy link
Member

imjoey commented Sep 1, 2020

@moonming tags/labels would be very helpful for users easily to get the wanted routes/services/upstreams. Besides, the feature of route grouping we are working on aims at adding support for multi-tenant management for routes, at the top of the hierarchy, which is necessary for enterprise users. The kubernetes you mentioned above is also supporting namespace for isolating resources, as well as labels for quick selection. So how about borrow the designs from kubernetes, both namespace and labels. Any feedback is much appreciated. Thanks.

@moonming
Copy link
Member

moonming commented Sep 1, 2020 via email

@imjoey
Copy link
Member

imjoey commented Sep 1, 2020

cool, that will be great if we can support both namesapce and labels. Thanks, Ming Wen Twitter: _WenMing Joey

@moonming yeah, that's really awesome for your support. Thank you.

@moonming
Copy link
Member

moonming commented Sep 1, 2020

@imjoey you are welcome :)
I have a concern, will namesapce increase the cost of using and learning for open source users?

@imjoey
Copy link
Member

imjoey commented Sep 1, 2020

@moonming yep, that's true and will surely bring some sort of complexity, especially if there are only several routes. While in contrast, if users need to manage a large number of routes, the benefits would be pretty valuable for users.

How about we allow the existence of ungrouped routes. Users can both enjoy the simplicity and this mature management method?

Aha~ The ungrouped routes sounds very much like cluster level resources which has no namespace limit in kubernetes.

@liuxiran
Copy link
Contributor Author

liuxiran commented Sep 3, 2020

Our solution now(refer to existing pr):

  1. create a data table of routeGroup, realize CRUD of routeGroup

  2. associate the ID and Name of routeGroup in the route to connect the two.

The changes to the route:

  • user needs to specify a group when creating a route (or create a new group along with it)

How about we allow the existence of ungrouped routes. Users can both enjoy the simplicity and this mature management method?

If you think the above suggestion is more user-friendly, we will also modify the implementation plan @moonming :)

@juzhiyuan
Copy link
Member

merged and closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants