Monorepo project with operator sdk
54 views
Skip to first unread message
Sayak Mukhopadhyay
Jun 12, 2022, 11:06:30 AM6/12/22
to Operator Framework
Hello folks
I am building an application that consists of 3 parts, an operator, a server and a UI. I was planning to build these 3 in a monorepo but struggling to decide how to structure them. One way, I have considered is as follows:
project-folder
|---operator
| |---api
| |---config...etc.
|---ui
| |---package.json...etc
|---server
|---go.mod...etc
But this situation seems like that of a typical multi repo one and doesn't feel right in a monorepo.
The other way I have considered is
project-folder
|---api
|---config...etc.
|---ui
| |---package.json...etc
|---server
|---go.mod...etc
But this seems to me like it indicates that the server and UI are subcomponents of the operator.
Moreover, I can't just willy-nilly move the operator files as that would break it.
Do you folks have any opinions on how such a project could be structured?
I am building an application that consists of 3 parts, an operator, a server and a UI. I was planning to build these 3 in a monorepo but struggling to decide how to structure them. One way, I have considered is as follows:
project-folder
|---operator
| |---api
| |---config...etc.
|---ui
| |---package.json...etc
|---server
|---go.mod...etc
But this situation seems like that of a typical multi repo one and doesn't feel right in a monorepo.
The other way I have considered is
project-folder
|---api
|---config...etc.
|---ui
| |---package.json...etc
|---server
|---go.mod...etc
But this seems to me like it indicates that the server and UI are subcomponents of the operator.
Moreover, I can't just willy-nilly move the operator files as that would break it.
Do you folks have any opinions on how such a project could be structured?
jesus m. rodriguez
Jun 12, 2022, 11:22:21 PM6/12/22
to Sayak Mukhopadhyay, Operator Framework
Hello Sayak,
Are the server and ui related to each other? If so, I would probably put the server
and ui in their own repo and the operator in its own.
But if you can't have 2 repos, I would probably go with your first option which
separates the items by directory. I've done this with other projects in the past (not
operators).
You mention that option 1 "doesn't feel right in a monorepo". What are you trying to
accomplish with a "monorepo"?
I agree with your sentiment about option 2, it does seem that the ui and server are
subcomponents of the operator which is not what you want.
Sincerely,
jesus
Sayak Mukhopadhyay
Jun 13, 2022, 3:26:09 AM6/13/22
to Operator Framework
Hi Jesus
The number of repos is not really a technical constraint for me, more like a design one. This is because I have noticed that almost everyone in the k8s community tends to use monorepos (I am aware of the pros and cons of monorepos vs multirepo arguments and am pretty much on the fence) and wanted to follow in their footsteps. That's pretty much my motivation for using monorepos.
Moreover, I have been taking ideas from some projects like https://github.com/argoproj/argo-cd/ and although it seems like they don't use OSDK/Kubebuilder at all, I have noticed how many of the components, which generate separate binaries, are all mashed up in the same repo side by side along with the operator code. I have noticed this in some other projects like traefik too. So, I was thinking that maybe there is some unwritten project design pattern that I am missing here.
The number of repos is not really a technical constraint for me, more like a design one. This is because I have noticed that almost everyone in the k8s community tends to use monorepos (I am aware of the pros and cons of monorepos vs multirepo arguments and am pretty much on the fence) and wanted to follow in their footsteps. That's pretty much my motivation for using monorepos.
Moreover, I have been taking ideas from some projects like https://github.com/argoproj/argo-cd/ and although it seems like they don't use OSDK/Kubebuilder at all, I have noticed how many of the components, which generate separate binaries, are all mashed up in the same repo side by side along with the operator code. I have noticed this in some other projects like traefik too. So, I was thinking that maybe there is some unwritten project design pattern that I am missing here.
Simon Baumer
Jun 14, 2022, 3:11:10 AM6/14/22
to Operator Framework
Hey Sayak,
at StackRox we've added the operator under a `operator/` directory [1] in the same repo to have access to internal libraries. It uses the monorepo's go modules file because of several replace directives within the repo.
I like the separate directory approach because it also separates all things related to testing and building the operator.
at StackRox we've added the operator under a `operator/` directory [1] in the same repo to have access to internal libraries. It uses the monorepo's go modules file because of several replace directives within the repo.
I like the separate directory approach because it also separates all things related to testing and building the operator.
Reply all
Reply to author
Forward
0 new messages