Add more structure to our directories, and document it #4851

Activity

1. bgrant0607

   added

   kind/cleanupCategorizes issue or PR as related to cleaning up code, process, or technical debt.Categorizes issue or PR as related to cleaning up code, process, or technical debt.

   priority/awaiting-more-evidenceLowest priority. Possibly useful, but not yet enough support to actually get it done.Lowest priority. Possibly useful, but not yet enough support to actually get it done.

   sig/api-machineryCategorizes an issue or PR as relevant to SIG API Machinery.Categorizes an issue or PR as relevant to SIG API Machinery.

   priority/backlogHigher priority than priority/awaiting-more-evidence.Higher priority than priority/awaiting-more-evidence.

   and removed

   priority/awaiting-more-evidenceLowest priority. Possibly useful, but not yet enough support to actually get it done.Lowest priority. Possibly useful, but not yet enough support to actually get it done.

   on Feb 26, 2015
2. bgrant0607

   added this to the v1.0 milestone on Feb 26, 2015
3. lavalamp commented on Feb 26, 2015

   

   lavalamp

   on Feb 26, 2015

   Contributor

   More actions

   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.

   • master/
     • service/
     • resourcequota/
     • storage/
       • etcd/
     • ui/
   • node/
     • kubelet/
     • proxy/
   • plugin/
     • scheduler/
     • nodecontroller/
     • replicationcontroller/
   • cloudprovider/
   • kubectl/
   • common/
     • apischema/
       • internal/
       • public/
         • v1beta1/
         • v1beta2/
         • v1beta3/
     • apiserver/
     • apiframework/
       • api/: generic files from pkg/api
       • meta/
       • registry/ (generic CRUD)
       • runtime/
       • version/
       • watch/ (Maybe util/ is a better home? I need to see if this grew specific stuff.)
     • auth/ (what is this auth? how does it differ from the client/auth/?)
     • client/
       • auth/
       • config/
       • lib/
     • util/
       • labels/
       • probe/
       • resource/
       • types/
       • conversion/
4. smarterclayton commented on Feb 26, 2015

   

   smarterclayton

   on Feb 26, 2015

   Contributor

   More actions

   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)?

   On Feb 26, 2015, at 1:12 PM, Brian Grant notifications@github.com wrote:

   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:

   master/
   service/
   nodecontroller/
   replicationcontroller/
   resourcequota/
   scheduler/
   storage/
   etcd/
   ui/
   node/
   kubelet/
   proxy/
   cloudprovider/
   client/
   auth/
   config/
   lib/
   kubectl/
   common/
   apischema/
   internal/
   public/
   v1beta1/
   v1beta2/
   v1beta3/
   apiserver/
   apiframework/
   api/: generic files from pkg/api
   meta/
   conversion/
   registry/ (generic CRUD)
   runtime/
   version/
   watch/
   auth/
   util/
   labels/
   probe/
   resource/
   types/
   @smarterclayton @lavalamp @thockin

   —
   Reply to this email directly or view it on GitHub.
5. bgrant0607 commented on Feb 26, 2015

   

   bgrant0607

   on Feb 26, 2015

   MemberAuthor

   More actions

   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.
6. smarterclayton commented on Feb 27, 2015

   

   smarterclayton

   on Feb 27, 2015

   Contributor

   More actions

   I guess I had not viewed it as a problem so far. I don't object to it being "fixed".

   On Feb 26, 2015, at 5:20 PM, Brian Grant notifications@github.com wrote:

   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.

   —
   Reply to this email directly or view it on GitHub.
7. bgrant0607 commented on Feb 27, 2015

   

   bgrant0607

   on Feb 27, 2015

   MemberAuthor

   More actions

   Of course, the person who wrote all the code doesn't need help finding anything. :-)
8. satnam6502 commented on Feb 27, 2015

   

   satnam6502

   on Feb 27, 2015

   Contributor

   More actions

   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 contrib and cluster.
9. satnam6502 commented on Feb 27, 2015

   

   satnam6502

   on Feb 27, 2015

   Contributor

   More actions

   As someone who did not write all that code, I find it very hard to find anything. I too often end up running grep -Ri xxx or find . -name xxxx from the root directory.
10. bgrant0607 commented on Feb 27, 2015

    

    bgrant0607

    on Feb 27, 2015

    MemberAuthor

    More actions

    #2992 would also facilitate grepping.
11. smarterclayton commented on Feb 27, 2015

    

    smarterclayton

    on Feb 27, 2015

    Contributor

    More actions

    On Feb 26, 2015, at 2:23 PM, Daniel Smith notifications@github.com wrote:

    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.

    master/
    service/
    resourcequota/
    storage/
    etcd/
    ui/
    node/
    kubelet/
    proxy/
    plugin/
    scheduler/
    nodecontroller/
    replicationcontroller/
    cloudprovider/
    kubectl/
    common/
    apischema/
    internal/
    public/
    v1beta1/
    v1beta2/
    v1beta3/
    apiserver/
    apiframework/
    api/: generic files from pkg/api
    Hrm - I do think there are api consumption characteristics that don't cross over cleanly. Agree this whole package could do with some reorg.
    meta/
    registry/ (generic CRUD)
    runtime/
    version/
    watch/ (Maybe util/ is a better home? I need to see if this grew specific stuff.)
    auth/ (what is this auth? how does it differ from the client/auth/?)
    It's the server side as opposed to client. I think client auth is much more consumer focused, whereas this is almost all server, so very little common code.
    client/
    auth/
    config/
    lib/
    util/
    labels/
    probe/
    resource/
    types/
    conversion/
    —
    Reply to this email directly or view it on GitHub.
12. 27 remaining items

    Load more

13. thockin commented on Aug 20, 2015

    

    thockin

    on Aug 20, 2015

    Member

    More actions

    I'm far less concerned about hiding packages than I am about organizing
    them. :) internal/ is cute, but I don't think we've done a good enough job
    of breaking up the packages and grouping them into subtrees to do much with
    it yet.

    On Wed, Aug 19, 2015 at 3:50 PM, Mike Danese notifications@github.com
    wrote:

    go1.5 adds internal/ package visibility constraints so we can enforce
    private packages (at least as long as we, and our downstreams, are using go
    build)

    —
    Reply to this email directly or view it on GitHub
    #4851 (comment)
    .
14. smarterclayton commented on Aug 20, 2015

    

    smarterclayton

    on Aug 20, 2015

    Contributor

    More actions

    Also, anything you move to internal/ probably needs to be verified
    Openshift isnt using. Internal is cute but not our problem right now.
15. bgrant0607

    added this to the v1.2-candidate milestone on Sep 12, 2015
16. bgrant0607

    removed this from the v1.2-candidate milestone on Feb 19, 2016
17. bgrant0607

    added

    sig/nodeCategorizes an issue or PR as relevant to SIG Node.Categorizes an issue or PR as relevant to SIG Node.

    sig/api-machineryCategorizes an issue or PR as relevant to SIG API Machinery.Categorizes an issue or PR as relevant to SIG API Machinery.

    team/control-plane

    and removed

    team/none

    on Feb 19, 2016
18. bgrant0607

    added

    kind/technical-debt

    priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

    and removed

    priority/backlogHigher priority than priority/awaiting-more-evidence.Higher priority than priority/awaiting-more-evidence.

    on Nov 21, 2016
19. bgrant0607

    removed

    team/control-plane (deprecated - do not use)

    on May 31, 2017
20. smarterclayton commented on Jun 1, 2017

    

    smarterclayton

    on Jun 1, 2017

    Contributor

    More actions

    1.6 mostly completed the separation of these into better defined packages.
21. smarterclayton

    closed this as completedon Jun 1, 2017
22. sanyamk23

    added a commit that references this issue on Sep 1, 2026

    chore: fix author matching in Mergify configuration (kubernetes#4851)

    ...

    d5cefe8