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

Network provider: Refactor items to use API routes #737

Closed
5 tasks done
gildub opened this issue Mar 19, 2017 · 9 comments
Closed
5 tasks done

Network provider: Refactor items to use API routes #737

gildub opened this issue Mar 19, 2017 · 9 comments
Assignees
Labels

Comments

@gildub
Copy link
Contributor

gildub commented Mar 19, 2017

The new practice is to use API routes instead of dedicated controllers methods for feeding Angular forms. We need to re-align the network items to make use of it.

  • Network Router
  • Cloud Network
  • Cloud Subnet
  • Security Groups
  • Floating IPs
@gildub
Copy link
Contributor Author

gildub commented Mar 19, 2017

@h-kataria, could you please assign it to me?

@AparnaKarve
Copy link
Contributor

@gildub The main idea here would be to get rid of controller routes and actions that feed a json to the angular form, and replace those actions in the angular controller with REST API calls.

To give you an example, in your most recent PR #716, network_router_networks_by_ems needs to go away.
On the angular side, you should call a suitable API using API.get and populate the form based on the output of this API. We already have a couple of angular controllers that use API.get that you can refer to get you started.

Can you try the following API and see if it gets you the output that you need to replace network_router_networks_by_ems?

/api/cloud_networks?expand=resources&filter[]=ems_id=<id>&attributes=name

*Replace the <id> with the correct id appropriately.

@gildub
Copy link
Contributor Author

gildub commented Mar 22, 2017

@AparnaKarve,

The /api/cloud_networks?expand=resources&filter[]=ems_id=<id>&attributes=name works, I'm able to retrieve all the networks filtered by the ems.

That's great, I can get started.

Meanwhile, my initial wonder was about the other network resources available from the web service end.
For instance api/cloud_subnets is not implemented which is consistent with /api/ :collection.

I suppose I have to submit a patch to manageiq core repo in order to add app/controllers/api_controller/cloud_subnets.rb and others related files.

@AparnaKarve
Copy link
Contributor

I suppose I have to submit a patch to manageiq core repo in order to add app/controllers/api_controller/cloud_subnets.rb and others related files.

Yes, that is correct... and you'll find plenty of examples on how to add an API endpoint for a collection.
Also check out config/api.yml

@gildub
Copy link
Contributor Author

gildub commented Apr 21, 2017

The API provides for the resource for the Security Groups and related FW rules through the relationship.
The Cloud Subnet, Network Routers and Floating IPs don't have direct API resource.

@gildub
Copy link
Contributor Author

gildub commented Jun 5, 2017

Subnets need the REST API that was just added: ManageIQ/manageiq#15248

@miq-bot
Copy link
Member

miq-bot commented Apr 30, 2018

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

@miq-bot miq-bot added the stale label Apr 30, 2018
@JPrause
Copy link
Member

JPrause commented Jan 28, 2019

@gildub is this still a valid issue? If yes, lease remove the stale label. If not can you close.
If there's no update by next week, I'll be closing this issue.

@gildub
Copy link
Contributor Author

gildub commented Jan 28, 2019

@JPrause, no more need for it. Thanks.

@gildub gildub closed this as completed Jan 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants