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

Kubebuilder v2 Checklist #1604

Closed
17 of 32 tasks
anyasabo opened this issue Aug 21, 2019 · 3 comments
Closed
17 of 32 tasks

Kubebuilder v2 Checklist #1604

anyasabo opened this issue Aug 21, 2019 · 3 comments

Comments

@anyasabo
Copy link
Contributor

anyasabo commented Aug 21, 2019

Related #1188

This is just to start formalizing a checklist of items that need to be completed. It's more a personal to do list for now and will be actively edited, it might be useful later if we end up needing to break things out

  • Update dockerfile
  • Move from operators dir
  • Update project (v2, multiproject etc). Each type must be listed now
    • APM
  • Update makefile
    • Update generate
  • Update Gopkg.toml manually (since v2 uses modules the cli doesn't touch this any longer)
  • Update APM types structure in apis dir
    • no longer group.go, doc.go, register.go, adds groupversion_info.go
  • Update assn types structure in apis dir - This is problematic, see below
  • Update ES types structure in apis dir
  • Update kibana types structure in apis dir
  • Convert APM controller
  • Convert Elasticsearch controller
  • Convert Kibana controller
  • Move dirs out of pkg (up to decide)
  • Remove cmd dir (logic is now mostly in main.go)
    • This will need to happen sooner than later because it contains webhook info that is deprecated, so it just can't build as is.
    • In the meantime, update existing cmd pkg calls in place
  • Update CI to account for go modules
  • Determine webhook course of action
    • Options
      • Delete it, reintroduce later
      • allow manual deployment with user generating certificate and configuring
      • adopt new method to auto deploy (perhaps introducing dependency on cert manager?)
      • something else?
  • Update main.go for our specific paths (e.g. controller vs controllers, pkg) paths
  • Update wrapped k8s client to new signatures
    • Update calls to wrapped client
  • Remove webhook dir temporarily
    • Move webhook Aggregate() call temporarily
  • Move Associations package outside of apis dir or figure out how controller-gen works with interface types, because now it seems to be breaking
    • Update import paths for associations package
  • Remove outdated markers
  • Add new rbac markers
  • Add new rest mapper to watches
  • [ ]

For each controller:

  • Follow steps here to set up new controller (we cannot use scaffolding after the first controller): https://book.kubebuilder.io/migration/multi-group.html
  • Update kubebuilder tags
    • NOTE: make sure you have // +kubebuilder:object:root=true on the main obj structs, e.g. apmserver and apmserverlist
    • TODO: is +kubebuilder:subresource:status still needed? it is not in the deprecated markers list or in the new scaffolding, even though the new scaffolding has a status type

Outstanding questions

  • Is it worth it to adopt the new directory structure, and have it be a pain to a) compare changes in this PR, and b) have it be challenging to view past commits for given files?

The new directory structure moves everything from the pkg dir up a level, see here for what it looks like after scaffolding is run for one type:
https://github.com/anyasabo/cloud-on-k8s/tree/8b6aa9581c93f9a1b796f8462a40ae43353deb2c/operatorsv2

My inclination is probably not. It might be a pain to update some of the the tools that have assumptions about their layout. Right now I cannot enumerate those though. If it's just a few things, that seems worth it to make this PR easier to review.

  • operators dir

Does it still make sense to have the operators dir? It seems like we can move everything up one directory. We might be able to do that prior to this change to make it easier to review. I don't really understand, but I think there's something weird where it expects go.mod to be in the root of the repo. Having it just in a sub directory was causing ambiguous import errors that went away when I moved the go.mod file to the root and changed the module path accordingly. I don't have a good enough grasp of gomod right now though to clearly explain the reason.

@artemnikitin
Copy link
Member

Update CI to account for go modules

👏

@artemnikitin
Copy link
Member

I created an issue for infra team to clarify if our Artifactory instance is supporting Go modules. If yes, then we can set GOPROXY=https://artifactory.elstc.co to use it. It's like https://proxy.golang.org/ but hosted inside company

@anyasabo
Copy link
Contributor Author

We moved everything out of the operators dir:
#1616
#1618
#1626

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants