-
Notifications
You must be signed in to change notification settings - Fork 40.4k
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
Add more structure to our directories, and document it #4851
Comments
Hm, I'd actually instead consider putting the controllers under plugin along with scheduler. client/ is used by multiple packages, so I think it should go in common. conversion/ is meant to be generic, so that should go under util.
|
Possible counter strawman - send people to the godoc page, which should display nice paragraph summaries of each package (and flog folks to add nice descriptions where there aren't)?
|
godoc is also necessary, but I don't see how it solves the problem of needing to look at the godoc for a zillion directories to find something. |
I guess I had not viewed it as a problem so far. I don't object to it being "fixed".
|
Of course, the person who wrote all the code doesn't need help finding anything. :-) |
Where can we put source (Dockerfiles etc.) for the images we create (e.g. for logging)? It would be good to have one place where all the sources for our images are located. Currently for logging they are under |
As someone who did not write all that code, I find it very hard to find anything. I too often end up running |
#2992 would also facilitate grepping. |
|
@lavalamp While we have many components that are also clients, and we want users to be able to write similar components, I don't want to nest client code with server code in common. I want users who want to use the client to be able to easily find the relevant code without wading through our internals. Imagine we had build visibility. Also, I've said this before, but I'd like to ensure that the general-purpose client functionality of kubectl to be usable as a client library, not just as a command-line tool. I guess the node controller could be a plugin, though I'm not sure I find that case compelling. |
After taking a look at the code structure again, I withdraw my hasty assertion. Definitely could benefit from a good clean up. Registry as a term needs to be yanked and replaced by storage or rest (or reststorage) consistently, and Dans master node structures would be good. We should make a decision on structure by type (things to do with pods, nodes, scheduling) or by function (master, node, controllers, scheduling, storage).
|
Good point: #1744. |
We should define exactly what we are optimizing for. Is it maximum Proposed: optimize for obviousness, grouping by publicness and grouping by To Daniel: as much as I agree that scheduler and controllers operate as Random questions about choices herein. Will cmd/* continue as-is? I would maybe offer:
On Thu, Feb 26, 2015 at 10:12 AM, Brian Grant notifications@github.com
|
grep works fine for me regardless of the directory structure. On Thu, Feb 26, 2015 at 9:01 PM, Tim Hockin notifications@github.com
|
The great organizers vs searchers debate - let it begin. I have a folder with every file I've ever used in it and do a search/find whenever I need something :) ----- Original Message -----
|
One of the things I miss from my tenure at Microsoft (and many years beforehand) is Visual Studio which let me easily navigate vast swathes of C++ and have some clue about what was going on. I switched to vim yesterday with go-vim and YCM and tagbar but I still feel like a caveman. |
Re. searching vs. organizing: People new to the project don't know what to search for, and some search terms get hits everywhere. As the project grows, we'll need to pay attention to both -- neither will be sufficient on its own. |
I agree with Brian, this is a real problem, and grep doesn't help unless you know what to search for. As a random aside, I think it's unfortunate that people don't comment at the file level (in addition to at the function and and package level). Code is not randomly distributed into files; it's helpful to know what is the organizing principle behind each file. Having Github directory listings show these file descriptions instead of the much less useful last commit description in the directory listings would be the icing on the cake... Anyway, I think the directory structure Brian proposed at the beginning seems basically reasonable. As for plugin/ I think we should get rid of it. Just have directories for controllers, schedulers, auth, etc. directly under master. |
I don't think that this makes the v1.0 cut. |
The lack of any obvious structure is causing new code to be put into random places. With the ongoing API group work, we also desperately need a home for common API infrastructure that's independent of any particular API group. Another stab at API-related directories (not exhaustive, probably some incorrect categorizations):
We don't have to move all the directories at once. |
I guess since I/we want to use the type machinery for component configuration (similar to scheduler config, kubeconfig) as well as for the API, it would be worth making that another subdirectory under apiframework, distinct from the other random stuff in common. |
I'd love to see pkgs that are used by one component live under that pkg/* should be things that are plausibly used across more than one cmd/* On Mon, Aug 17, 2015 at 7:09 PM, Mike Danese notifications@github.com
|
go1.5 adds |
I'm far less concerned about hiding packages than I am about organizing On Wed, Aug 19, 2015 at 3:50 PM, Mike Danese notifications@github.com
|
Also, anything you move to internal/ probably needs to be verified |
1.6 mostly completed the separation of these into better defined packages. |
Our code is hard to navigate, and github search isn't the greatest. It would help if the directory structure weren't so flat. I'm also not sure it makes sense for plugin to not be under pkg. #2306 is related, but separate.
Strawman:
@smarterclayton @lavalamp @thockin
The text was updated successfully, but these errors were encountered: