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

Update Docs #49

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

fitzthum
Copy link
Member

@fitzthum fitzthum commented Nov 8, 2024

Lots of changes with the docs; just a draft for now.

Copy link

netlify bot commented Nov 8, 2024

Deploy Preview for frolicking-manatee-96c0c8 ready!

Name Link
🔨 Latest commit 702efa4
🔍 Latest deploy log https://app.netlify.com/sites/frolicking-manatee-96c0c8/deploys/67379bfc27c1760008bd0dd9
😎 Deploy Preview https://deploy-preview-49--frolicking-manatee-96c0c8.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@fitzthum fitzthum marked this pull request as draft November 8, 2024 22:13
Rethink the structure of the docs as something that will be more useful
to users. As such, get rid of outdated internal details on guest
components, kata, and CAA.

This commit leaves many of these new sections mostly empty. They will be
extended in future commits.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
@fitzthum fitzthum force-pushed the docs-overhaul-1 branch 4 times, most recently from 42910ed to e805be1 Compare November 12, 2024 21:04
Platform-specific setup will be added separately.

Sample workload guide will be simplified with tabbed codeboxes.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
@fitzthum fitzthum force-pushed the docs-overhaul-1 branch 5 times, most recently from 214a080 to 16f8148 Compare November 13, 2024 17:39
This is a much cleaner way to handle the configurations
for different platforms.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
Add an overview of the hw that we support.
This might be too much information for the top page,
but at least it gives poeple a sense that the project
has a broad scope.

We can consider creating a separate hw section later.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
@fitzthum fitzthum force-pushed the docs-overhaul-1 branch 3 times, most recently from e542f74 to b932784 Compare November 13, 2024 20:27
Add our existing trouble-shooting guide to the website.

There are some improvements we could make to this doc,
but for now let's just get it on the website

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
Let's get all of our features outlined before we add
detailed material for each.

Here we add authenticated registries and local registries.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
@fitzthum fitzthum force-pushed the docs-overhaul-1 branch 2 times, most recently from dbf4efa to d6fe4b5 Compare November 13, 2024 21:46
Move contributor guide to website.

The website is mostly aimed at users, but our contributor guide
is pretty good, so let's put it up here.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
@fitzthum fitzthum force-pushed the docs-overhaul-1 branch 4 times, most recently from 710715f to b31df10 Compare November 14, 2024 22:17
This is mostly new content covering the design of CoCo.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
Placeholder with some common use cases.

Update with content later

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
Remove incomplete threat vectors page.
We can add this back once there is some content,
but I don't quite see how it fits.

Rename personas to cloud-native-personas.

Update main trust model document to include a plain description
of the trust model rather a more generic definition of a trust model
and goals for the trust model.

The new text is mainly an overview. We may want to add something
more empirical in the future, but this should help users understand
what's going on.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
@fitzthum fitzthum marked this pull request as ready for review November 15, 2024 19:10
@fitzthum
Copy link
Member Author

@confidential-containers/tsc @surajssd @mkulke

Docs overhaul is ready for review. There are lots of changes here.

  • structural changes; reorganize things to focus on users trying to understand the project
  • move stuff from github like the quickstart guide and troubleshooting guide (these will be removed from gh next to avoid sync issues)
  • add lots of architecture information and rework trust model

This is only the start. I have left a number of TODOs around. Most notably in the following sections

  • hardware prerequisites. we need platform owners to describe the setup of their platforms.
  • features. most of the features have no content yet. we need devs who worked on them to dig up guides.
  • use cases. let's get some people working on the use cases to add content

I think this PR provides a good base for contributions to the docs. There are probably lots of things we can improve about this PR and I am happy to take feedback but I also want to get the ball rolling so consider fixing suggestions in a follow-up.

@portersrc
Copy link
Member

I went through the trust model docs, and those sections look great.

Copy link
Collaborator

@mkulke mkulke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the reorganization very much. However, with this change the Instructions for Peerpods has been removed. Was this intentionally? at least for Azure this was where the end-user focussed documentation was being maintained.

image

@fitzthum
Copy link
Member Author

with this change the Instructions for Peerpods has been removed. Was this intentionally? at least for Azure this was where the end-user focussed documentation was being maintained.

Generally I want to try to converge the peer pods directions with the bare metal directions, but I didn't mean to delete the Azure docs.

One place this could potentially live in the new layout is getting started -> pre-requisites -> hardware -> cloud -> azure
Is that too deeply nested?

Also is it valid separate out this stuff as pre-requisites? I'd like it if we just had setup steps and then people moved onto generic steps to install the operator and runt he workload. It seems like that can probably work if we add a cloud tab to the operator setup step. wdyt? I understand if you want to keep the full end-to-end instructions in place somewhere. Maybe we could add an examples section?

@mkulke
Copy link
Collaborator

mkulke commented Nov 18, 2024

One place this could potentially live in the new layout is getting started -> pre-requisites -> hardware -> cloud -> azure Is that too deeply nested?

Also is it valid separate out this stuff as pre-requisites? I'd like it if we just had setup steps and then people moved onto generic steps to install the operator and runt he workload. It seems like that can probably work if we add a cloud tab to the operator setup step. wdyt? I understand if you want to keep the full end-to-end instructions in place somewhere. Maybe we could add an examples section?

putting it under pre-requisites feels a bit odd. Can we put it below getting started / installation / Azure? We could have similar instructions for other CSPs as siblings, or possibly a non-TEE qemu entry that covers everything from local k8s cluster installation to coco runtimeclass (in a similar copy/paste fashion as the azure docs). the installation page could still keep the more generic, brief installation instructions.

@fitzthum
Copy link
Member Author

fitzthum commented Nov 18, 2024

@mkulke yeah seems tricky for the installation page that I currently have to capture everything in tab boxes. It can accommodate switching to different CRDs and CRs but the earlier steps where you download CAA don't really fit.

For this PR can I just move the azure page as-is to a new top-level example section and then we think about how to handle peer pods? I don't really know how peer pods installation works.

I suspect we probably want to add a cloud page to the installation section. Do we split it into two pages: cloud, and bare-metal (that are mutually exclusive)? Do we add another step for peer pods that is optional (before installation but after per-requisites)?

I think after we get the peer pods stuff added some of the Azure stuff can go in pre-requisites; everything before installing CAA? wdyt?

@mkulke
Copy link
Collaborator

mkulke commented Nov 18, 2024

For this PR can I just move the azure page as-is to a new top-level example section and then we think about how to handle peer pods? I don't really know how peer pods installation works.

I suspect we probably want to add a cloud section to the installation section. Do we split it into two pages: cloud, and bare-metal (that mutually exclusive)? Do we add another step for peer pods that is optional (before installation but after per-requisites)?

I think some of the Azure stuff can go in pre-requisites; everything before installing CAA? wdyt?

What I would suggest is to move the azure folder as-is from cloud-api-adaptor into the getting_started/installation folder, it'll appear as a subpage there. next to subpages for bare metal, non-tee, aws, ...

I would not recommend chopping up the documentation in generic and specific steps and leaving it to reader to puzzle it together (even if that means some redundancy)

@fitzthum
Copy link
Member Author

I feel pretty strongly about making the docs as generic as possible. Not doing so with the existing docs has created nothing but problems. With siloed docs maintainers only focus on their own sections which decreases quality and everybody ends up doing more work because individual sections are longer and more complex. This gets worse as we add more platforms and features. Let's not underestimate how painful redundancy can be. We've really struggled with this in the github docs.

More fundamentally, we've struggled with making the project generic since day 1. If we keep the docs separate we enable ourselves to continue not really worrying about convergence which I think is a big mistake. Putting everything together is a good way to push in the other direction. It will definitely show us where we need to do some more work.

That said, I understand that you guys have put time into the az doc in particular and that it is proven to work. That's why I suggest keeping it around in examples or some other place (even though that does also create some redundancy). I don't think it will be too puzzling for users to figure out the prerequisite steps. If it is then we probably need to make the project itself simpler. I don't want to put the az doc under the installation section as-is. It would be odd to have a pre-requisites and installation section next to another doc that also contains those steps.

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

Successfully merging this pull request may close these issues.

3 participants