Hi @irbekrm , I have used cert-manager that was cool, and I have still researched cli tools before. I would like to apply this feature as my GSoC 2022. Could you give me some advice？

Hi @lonelyCZ

Thanks for your interest in working on this as GSoC project, glad to hear you've used cert-manager already!

I would like to apply this feature as my GSoC 2022. Could you give me some advice?

The first thing to do would be to familiarize yourself with the GSoC timeline and contributor docs (that you may have already done)

I'd recommend that you get involved with the cert-manager community, say hi on Slack and see if you have a chance to join some of our meetings, see the details for how to join in our contributing docs

We usually recommend that folks who are interested in applying to our GSoC project also try to work with cert-manager a bit, picking up a good first issue or finding some other way how to contribute is a great way to get started and helps you to understand if the project is suits your interests and helps us to see whether we work well together :). Again, do reach out to us on Slack if you want to contribute and have questions about how to get started!

In terms of deadlines, I understand that 19th of April is the deadline for submitting the proposal.
Between now and then is a period for students to discuss proposal ideas with mentoring organizations. As a mentor I am happy to review a draft proposal and some of cert-manager team may also be able to give advice, do reach out on Slack :)
There is also a discussion board set up in CNCF Github with some interesting discussions https://github.com/cncf/mentoring/discussions/categories/google-summer-of-code-2022

Does this make sense?

Thanks for your reply. :) @irbekrm

I will familiarize the community as soon as possible, and actively participate in the draft proposal. Looking forward to work with community members.

I understand the purpose of this feature is easily to recreate the installation of cert-manager with external dependencies for maintainers or members. There are two opinions:

1. If there have been a cert-manager environment only lacking external dependencies, we should only deploy external dependencies, so should we separate cert-manger from externally dependent installations. For example, providing a option for script to certain install mode.
2. Because each external dependency is configured differently, we may need to be flexible in configuring these options, so we can separate the configuration file from the installation file. Such as vault, we provide a default configuration file that users can modify as needed, as shown in the figure below.

If there have been a cert-manager environment only lacking external dependencies, we should only deploy external dependencies, so should we separate cert-manger from externally dependent installations. For example, providing a option for script to certain install mode.

Whatever installation mechanism you choose, it should be able to deploy different combinations of cert-manager + some external tools, i.e cert-manager + Vault, cert-manager + some ingress implementation etc.
It would be nice to consider how the installation mechanism you choose could be made further configurable so that the user can install just the dependencies and not cert-manager or perhaps you implement the mechanism in such a way that it already works for MVP.

Because each external dependency is configured differently, we may need to be flexible in configuring these options, so we can separate the configuration file from the installation file. Such as vault, we provide a default configuration file that users can modify as needed, as shown in the figure below.

This will really depend on what installation mechanism you choose and how much abstraction you build on top. For example, you could have chosen to implement this as a Go CLI and pass each configuration option as a CLI flag and then in your code translate those into the format suitable to configure each dependency. Or you can have configuration templates for each dependency as you say, they are all valid options and each has its pros and cons.
It would be good if your proposal would show how you expect the configuration options can be passed. It can also be good to have a 'Questions' section for things that are not clean yet at this point. You could also add a 'Constraints' section if you can think of any constraints for this particular installation mechanism.

Thank you! :)

they are all valid options and each has its pros and cons.

Yes, I consider their pros and cons as follows

1. If we implement this as a Go CLI, it is easy to use, but not easy to extend. Each extension of a dependency requires redevelopment and compilation, which is not conducive to sharing knowledge.
2. If we implement this as configuration templates, implementing a configuration framework, which facilitates scaling, but we need to design a friendly way to use it.
3. If we were using Terraform, we might need to ask members to learn a new build language.

I tend to option 2 or option 3 because developing a command-line tool can be complex and difficult to maintain, especially considering that it can install multiple dependencies.

What do you think, or what do you think of Terraform and how many members use this tool?@irbekrm I think the implementation ideas of scheme 2 and 3 are similar.

Hi @lonelyCZ

Yes, I consider their pros and cons as follows

Good work on considering those, I think you can even include that in the proposal as I think it's always valuable to show that you've considered alternatives 👍🏼

I don't want to influence which option you choose in the proposal 😄 The point of the proposal is for you to choose an implementation mechanism that you think is best and describe how you will solve the problem with it.

Some thoughts though

If we implement this as a Go CLI, it is easy to use, but not easy to extend. Each extension of a dependency requires redevelopment and compilation, which is not conducive to sharing knowledge.

I think if the solution was a CLI, it should be built in such a way that there is some sort of 'framework' that makes adding a new extension easy, i.e adding a new extension should not require touching too many unrelated parts of code (redevelopment). I would argue that having to compile it (most likely this would mean making a new release for the tool) is not a big problem. There could be other maintentance related cons though and agree that it might be more complex than just scripts.

What do you think, or what do you think of Terraform and how many members use this tool

I think all of us are familiar with Terraform

Thanks for your response @irbekrm

I will write a proposal as soon as possible, including all of my consideration.

Thanks @lonelyCZ

Good luck with the proposal!

To add, the actual GSoC work includes working on a design doc and discussing it with the cert-manager team, so the actual implementation might differ from what you will describe in the proposal. I'd just encourage you to choose the implementation mechanism you think is best suited and describe that.

Hi, @irbekrm , I have submited a proposal, there is a replica at https://docs.google.com/document/d/1wZ5ia0j4-5UVWN24xgj25UaYffPaTlBtpmerr5Uw8Io/edit#, looking forward to your comments, thanks :)

If possible, I would like to discuss the feasibility of the proposal with the community to determine the final practical proposal.

Thanks @lonelyCZ! I will take a look now.

discuss the feasibility of the proposal with the community to determine the final practical proposal

Once a student gets accepted, there will be a period of time to discuss the final design with the whole team following the same process as we usually do when discussing a design document, so you should not worry about smaller details at this stage I think (The alternative would have been to have the whole of the team involved in working with each candidate on their proposal, which would not be feasible).
Also, CNCF org admin will have the final say about which projects get accepted.
Does this make sense?

Yes, thanks for your reply. @irbekrm During this period, I will try my best to implement some demos to verify the feasibility of the proposal.

Also, CNCF org admin will have the final say about which projects get accepted.

Regardless of the results, we hope to complete the project in a better way and bring more convenience to the community.

Thanks for you comments @irbekrm , I will improve it as soon as possible.

/priority important-soon

Assigned during triage party. Seems like this will be embarked on during the next few months of GSoC.

/priority important-soon

Hi, @irbekrm. I'm excited to tell you that I have implemented an easy demo that can deploy and setup Cert-manager and Vault with Terraform at this repository https://github.com/lonelyCZ/terraform-cm.

It currently supports the deployment of Cert-manager and Vault, configures the PKI engine for Vault by default, and generates a ClusterIssuer object named vault-issuer. However, the current implementation is simple, lacks some necessary dependency checking, and may not be stable.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close

@jetstack-bot: Closing this issue.