-
Notifications
You must be signed in to change notification settings - Fork 2
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
Scipian Customer Onboarding #3
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: nicklathe <n.lathe@sap.com>
Signed-off-by: nicklathe <n.lathe@sap.com>
0001-customer-onboarding.md
Outdated
# Motivation | ||
[motivation]: #motivation | ||
|
||
There is currently process for a new customer to be onboarded to Scipian. Having |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
currently no process?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, typo. Should be no process.
@@ -0,0 +1,122 @@ | |||
- Feature Name: `scipian_customer_onboarding` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this feature generic customer onboarding or is it specifically onboarding with existing terraform infrastructure?
The rest of the document seems to lean towards onboarding with existing terraform infrastructure. For teams that are looking to onboard and use the terraform controller to create their infrastructure, I imaging the process would be pretty similar, minus the terraform importing, but can teams onboard to Scipian for non-terraform or infrastructure management use cases? For example, if they just wanted to use Scipian to deploy to their existing infrastructure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This first RFC is meant to stay relatively generic, but focus on some internal needs for customers currently using scipctl
and stack
who will need to onboard to Scipian. This will include importing existing Terraform state, however this is not a requirement for Scipian, just a scenario we need to support in this first MVP.
0001-customer-onboarding.md
Outdated
|
||
Scipian customer onboarding will allow a seamless process for customers to | ||
onboard to the Scipian platform. At a high level, this includes creation of | ||
namespaces, RBAC rules, and importing Terraform state from a location external |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is not specific to onboarding with existing terraform infrastructure, then we might want to note that part is optional here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, it could say: "...creation of namespaces, RBAC rules, and optionally importing Terraform state..."
|
||
Scipian builds on and uses many Kubernetes primitives. Some of these include | ||
namespaces and RBAC rules. This allows multiple teams to use Scipian, while | ||
keeping each team's data and interactions with Scipian separated from eachother. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing space in eachother
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅
namespaces, RBAC rules, and importing Terraform state from a location external | ||
to Scipian. | ||
|
||
# Motivation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the motivation section here, we've covered why we're doing this, but we probably want to specifically layout the use cases (onboarding for deployments, onboarding without existing infra, onboarding with existing infra) and enumerate the expected outcomes. It seems like the outcomes should be:
- documented process for what a Scipian admin would need to do to onboard a new team (creating namespace and rbac roles)
- new scipian functionality to import existing terraform infrastructure (this might even require it's own separate rfc to really document out what the functionality will be and how it will be supported)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The steps to onboarding are laid out below, in the guide-level explanation. Should these steps be more explicit? I believe the guide-level section is the correct section to do this in.
0001-customer-onboarding.md
Outdated
- RBAC rules and Namespace will be created manually by a Scipian admin using | ||
yaml and `kubectl`. This could be automated later via an onboarding UI, but that | ||
is beyond the scope of this RFC. | ||
- Terraform state "puller" will be a Kubernetes job that runs a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section is part that I'm wondering if it should be it's own RFC.
Does this section need to include parts about how the onboarding team will need to provide their own docker container with the appropriate secret and terraform information inside in order to interact with their imported terraform?
We specified scipctl
here, but will this import be limited to infrastructure created by scipctl
and stack
or will it be open to any terraform infrastructure? What would supporting any terraform managed infrastructure mean for mapping the current Terraform state workspace structure to the Scipian expected structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that there's a line somewhere between getting Scipian ready for a new customer to use (RBAC, importing existing infra) and actually using Scipian. The latter will depend on good documentation, the former are steps we as Scipian developers/administrators need to have in place for a new customer.
I would have to check a version, but I believe we can take any version of Terraform after they introduced workspaces
and runs
. This should probably be documented as part of the using scipian documentation.
It should also be noted that this RFC is to support the onboarding of only a handful of internal customers we have right now. I expect more RFC's to follow as we iterate on this feature of Scipian in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically, this first RFC and onboarding process will focus on customers already using stack
, as that is the immediate need right now.
# Rationale and alternatives | ||
[rationale-and-alternatives]: #rationale-and-alternatives | ||
|
||
The onboarding outlined in this RFC will be an MVP level feature. Later, this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we should break this down even further. Maybe the most basic MVP should just be the RBAC rules and Namespace creation. That would be enough to allow a team to onboard to Scipian and start creating brand new infrastructure.
I think importing existing infrastructure is a really useful feature, but I'm concerned the cost will also be much higher to implement that feature and it might be worth having the first part done to unblock anyone who wants to get going with new infra.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The impact of not doing the RBAC rules and Namespace would be that multiple teams could not securely onboard onto a single Scipian cluster.
The impact of not doing the terraform importing would be that a team with existing infrastructure would need to create brand new infrastructure with Scipian.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I could do a better job of separating RBAC/Namespace creation and importing existing Terraform state, which is definitely an optional piece.
As for cost of implementing importing state, I'm not concerned about that. I wrote a quick proof of concept this week to test it out. Having a path for customers who don't want to tear down existing infra is an important piece of this onboarding process in my opinion.
# Prior art | ||
[prior-art]: #prior-art | ||
|
||
Because Scipian extends Kubernetes and utilizes many of Kubernetes' primitives, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't had time to really go through these two references yet, but I wanted to get them noted just to see if there's anything we should be looking into:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a look at these, but Scipian is a platform that extends much beyond infrastructure management (i.e. just Terraform). I haven't dug into these resources yet, but at a high level, these seem very focused on Terraform. Our goal is to iterate towards a place where we abstract Terraform away from the customer, and eventually even stop using it all together if it makes sense.
@nicklathe @ncronquist and I had a conversation in the last open office hours around splitting this up into two RFC's. Once RFC geared around the on-boarding process itself, also known as registration. Then the other RFC focusing on importing existing terraform state and etc. Let us know what you think? Thanks! |
I could see this being split into two RFC's. The importing existing Terraform is an optional component anyways, so I could see it being part of this or it's own. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good @nicklathe.
I know we talked about provider, but lets keep the scope of this RFC to just on-boarding. We'll create another RFC when capturing our thoughts for connecting scipian to a cloud provider like AWS.
This is the start to the RFC for Scipian customer onboarding.