How to organize raw request files?

[wchrisjohnson]

In the openstack project, there is a folder for requests which has sub-folders for Identity, Compute, etc. Inside these service level folders, requests are stored as individual files. In many services, there are tons of requests, and they can get quite hard to slog thru to find what you need.

It would be nice to be able to organize these under subfolders, based on the operational area. For example:

requests
--> identity
----> tenant
------> get_tenant.rb
------> list_tenants.rb
.....
----> token
------> get_token
------> validate_token
......
----> user
------> get_user_by_id
------> get_user_by_name
.............

In the Openstack Identity service, I found multiple examples where there were 2-3 requests that were exactly the same. Call me anal retentive, but this isn't clean.

Before I suggest a change to address this, what sort of options are there for organizing requests? Given the way that the "request" method/macro works within the context of the service.rb class, I suspect there isn't a clean solution to this without touching fog-core, but wanted to ask.

[tokengeek]

It's something else I've been meaning to look at.

Basically request adds something to the requests collection. Then when setup_requirements is called it requires the file. It then adds mock versions unless they have been defined.

So it's just syntactical sugar really.

I think the mock stuff should be method_missing on the Mock service frankly leaving the macro as only doing a) add to collection and b) requiring.

I'm thinking perhaps adding options for setup_requirements(:require => false, :mock => false) to disable this extra behaviour.

Less reliable is that it will not call any of this if @require == true so you could organise the files however you liked, require them in the service's version of setup_requirements (I think) then not worry about the macro.

I'd add them to requests just in case it's used in other places.

I've not written tests to confirm the current behaviour but I'm thinking of doing something along those lines for similar reasons.

[geemus]

I'm certainly open to iterating on this. @tokengeek summarizes well. A lot of the existing methodology is from a past in which you loaded everything at the outset and we wanted to slim it down. As we get nearer to a place where you can pick and choose it may be largely superfluous.

[wchrisjohnson]

I have a solution that would work and avoid any changes to fog. For my purposes, it would work just as well to consistently name the requests with a prefix for the operation area - for example:

requests
--> identity
----> tenant_get.rb
----> tenant_list.rb
.....
----> token_get.rb
----> token_validate.rb
......
----> user_get_by_id.rb
----> user_get_by_name.rb
......

I'm aware that the convention within fog is to lead with a verb, but this would go a long way toward providing the organization that I'm looking for in that folder, and still allow a flat folder structure. For the most part, the use of requests is an internal function of fog; the end user wouldn't ever care about the naming, except if/when they used IRB to interactively play with fog.

Conventions are a good thing.

Would this cause any other disruption in the use of fog from the perspective of the end user?

[geemus]

@wchrisjohnson hmm. Good question. The current naming convention is based at least roughly on trying to match the request names very closely with the name that the external API uses. In doing so, the hope is that it is much easier to cross-reference things in their documentation/etc. So to some extent the convention just follows that (perhaps influenced in part by AWS being the first services added and them having names that all are explicitly beginning with verbs). So, it is tricky. To some extent I think I would prefer grouping by folder, but obviously that involves more work/change to accommodate.

[stale]

This issue has been automatically marked stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.