Refactor packages

[pleshakov]

After provisioner mode related code was merged 1df6bcd , we have 2 components in the internal package:

• provisioner mode
• static mode

Additionally, we have shared "framework" code that both provisioner and static mode use.

What do you think about reorganizing packages like below?

- internal
  - provisonermode
     - manager.go
     ... other files
  - staticmode
     - manager.go
     - nginx
     - state
     - status // status-related code, only relevant for static mode
- pkg
  - framework
    - events
    - controller
    - helpers
    - status // general purpose status-related code, both relevant for provisioner and static mode

I also suggest we refactor the status package into two package, so that the one in pkg/framework/status doesn't depend on the graph.

[sjberman]

I agree with the approach of having common code available in the pkg directory. We would have to be very cognizant of the quality/export-ability of that code because it then becomes importable by the public. Not that we would necessarily have anything useful in there just yet as a public library, but it must be considered.

[pleshakov]

Not that we would necessarily have anything useful in there just yet as a public library, but it must be considered.

does it mean we need provide backward compatibility guarantees? or we can be more relaxed about that

[sjberman]

does it mean we need provide backward compatibility guarantees? or we can be more relaxed about that

The more I think about it, and reading this blog and this README, maybe it's best if we create something like internal/common (or similar) to house code until we know it's stable enough (or even worth) exporting to the public. Personally, since we aren't distributing a library, I would've been okay with the pkg directory and not keeping backwards compatibility, but I realize that pkg really is meant for anyone to use, and so there is an expectation that things wouldn't break.

I was basing my original thoughts off of the fact that we did this with NSM because we had to, but maybe isn't the best approach here.

[kate-osborn]

I agree with @sjberman but would prefer internal/framework.

[pleshakov]

created an issue #709 based on this discussion. closing the discussion