openservicemesh / osm-docs Goto Github PK

This GitHub issue is for fleshing out the OSM documentation around XYZ:

• Document Ingress -- save the doc in ./docs/wip/ingress.md (unless this already exists) (exact location is TBD - wip short term)

  • What is ingress?
  • Why do I need it on my cluster?
  • What types of ingress are supported by v0.8?
  • What are sample Ingress resources that would work with v0.8?
  • How does it work?
  • What's a sample Envoy configuration for a pod affected by Ingress?
  • What pods are affected by Ingress? (List Ingress, Service, Endpoints)
  • Are there different versions of the Ingress resource?
  • Which version of the k8s Ingress resource is supported by OSM Controller v0.8?
  • Point to docs w/ Nginx openservicemesh/osm#2827 and AGIC #75

• Create a small demo with sample apps and SMI showing how this feature works

• List Common Issues

  • See GitHub Issues for Nginx openservicemesh/osm#2827 and AGIC #75 for ideas on common issues and troubleshooting

• Create Troubleshooting Guide

  • List Ingress resources
  • List Services referenced by an Ingress resource
  • List the Endpoints for a given Service to discover the Envoys affected
  • What are the Pods / Envoys referenced by a given Ingress resource
  • Do the Envoys referenced by an Ingress resource have config indicating that they have been properly programmed?
  • What is the Envoy config we would expect to see on Envoys referenced by an Ingress resource?

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.

Add a v0.8 mirror of the docs as they existed in https://github.com/openservicemesh/osm/tree/release-v0.8/docs (available in a drop-down and not updated).

This GitHub issue is for fleshing out the OSM documentation around integration with Azure Monitor:

• Document how OSM can integrate with Azure Monitor -- save the doc in ./docs/wip/integrate_azure_monitor.md (exact location is TBD - wip short term)
• Create a small demo with sample apps and SMI showing how this feature works
• List Common Issues
• Create Troubleshooting Guide
• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.

This GitHub issue is for the reorganization of all newly written docs for v0.8, which we wrote as part of https://github.com/openservicemesh/osm/issues/2854

TBH: I'm not sure if its the documentation that is wrong or if its something in my environment or if there is an issue with the commands.

I have been following the "How to Run the OSM Manual Demo" and have encountered some issues

First, in the section "Create the Bookstore Application Namespaces" the following script is supplied

for i in bookstore bookbuyer bookthief bookwarehouse; do kubectl create ns $i; done

However this results in the following error:

Missing opening '(' after keyword 'for'.

I managed to get around this by creating the namespaces individually.

But then in the "Verify the Traffic Policy Mode" the following command is given:

kubectl get configmap -n osm-system osm-config -o json | jq -r '.data["permissive_traffic_policy_mode"]'

This produces the following error:

jq: error: permissive_traffic_policy_mode/0 is not defined at , line 1:
.data[permissive_traffic_policy_mode]
jq: 1 compile error

I again managed to get around this, by using the kubectl describe command on the config map to check the permissive_traffic_policy_mode value.

Then, in the section "Permissive Traffic Policy Mode" the following command is given to update the config map:

kubectl patch ConfigMap osm-config -n osm-system -p '{"data":{"permissive_traffic_policy_mode":"true"}}' --type=merge

But again this doesnt work and responds with the following error:

Error from server: Invalid JSON Patch

Is it the documentation that is wrong? Or have I missed something?

Some pages such as https://docs.openservicemesh.io/docs/ha/ have the title displayed twice. Address this.

**Please describe what should be documented

Currently docs and demos assume osm control-plane is installed in the osm-system namespace. We should make this more generic.

**Please suggest where in the repo the document should be located

In our demos we show observability with Jaeger.

This Github Issue is to write a document on:

• how we enable observability (how are Envoys configured)
• how we install Jaeger and what can be done with it
• what other software can be used to extend OSM (Zipkin, OpenTelemetry etc.)

As an aside, can you write some documentation somewhere for the zipkin stuff when you get a chance?

@draychev - Were you planning for some docs at some point? I can certainly help if needed.

Originally posted by @nojnhuh in openservicemesh/osm#907 (comment)

Please describe what should be documented
All the links on this page currently point to v0.3 of OSM documentation. https://github.com/openservicemesh/osm/blob/main/docs/content/docs/design_concepts/osm_components_interactions/_index.md

These should be updated to point to most recent docs. Some pages/lines linked to here no longer exist. Links should also work on the docs site:
https://docs.openservicemesh.io/docs/design_concepts/osm_components_interactions/

Need to consider relative linking and aliasing for this change as mentioned here (and explained by issue https://github.com/openservicemesh/osm/issues/2453)

• what are the benefits of an envoy-based service mesh
• scalability
• SMI compliant
• VM support

The work in openservicemesh/osm#1840 creates a site to hold the docs, but it does not reformat the existing docs into it.

That work is best separated and added in after openservicemesh/osm#1840 - (i) to avoid a bunch of conflicts with other in-flight pull requests and (ii) ideally carried out by the OSM team to ensure editorial accuracy.

I'm creating this issue to recommend some edits:

• create a proper welcome/landing page (currently a placeholder)
• add front matter (see readme notes)
• migrate the existing files into from docs/* to docs/content/* here
• review the current subsections (design, patterns) and organize the files for user flow (intro / getting started / install / examples / etc)
• review and fix links

https://docs.openservicemesh.io/ release tab not redirecting to correct pages of OSM releases.

https://docs.openservicemesh.io the docs website`s search box is not working

Need to illustrate process
@phillipgibson

**Please describe what should be documented

• How to use OSM for blue/green deployment
• A demo showing how TrafficSplit can be used for blue/green deployment

**Please suggest where in the repo the document should be located

As seen in the image below, the character > prefixed for topics on the sidebar can mislead the user to think there are sub-topics associated with the topic. When I see > and click it, I expected to see a preview of the sub-topic titles there, but the website redirects to the actual page corresponding to the topic.

Should we use a different character to denote the topics and have a navigation preview to explore sub-topics without redirecting to the parent page?

Bug description: For example, "enable" shows as blue in PR openservicemesh/osm#2941 and renders as red on the docs site: https://deploy-preview-2941--osm-docs.netlify.app/docs/tasks_usage/namespace_monitoring/#enable-metrics-for-a-namespace

Could be due to the theme being used per @flynnduism's comment: openservicemesh/osm#2941 (comment)

Affected area (please mark with X where applicable):

• Install [ ]
• SMI Traffic Access Policy [ ]
• SMI Traffic Specs Policy [ ]
• SMI Traffic Split Policy [ ]
• Permissive Traffic Policy [ ]
• Ingress [ ]
• Egress [ ]
• Envoy Control Plane [ ]
• CLI Tool [ ]
• Metrics [ ]
• Certificate Management [ ]
• Sidecar Injection [ ]
• Logging [ ]
• Debugging [ ]
• Tests [ ]
• Demo [ ]
• CI System [ ]

Expected behavior: Words are the same color

Steps to reproduce the bug (as precisely as possible):

How was OSM installed?:

Anything else we need to know?:

Environment:

• OSM version (use osm version):
• Kubernetes version (use kubectl version):
• Size of cluster (number of worker nodes in the cluster):
• Others:

Create a new section in front-page docs and list all possible demos we have created as part of this task

• TrafficSplit
• TCPRoute
• gRPC
• Ingress
  • Nginx
  • AGIC
• Egress

**Please describe what should be documented
Links should point to docs in main so they are up to date. When a release is cut, the links should be updated to point to a version of the documentation.

See example links in this section of the design doc

https://docs.openservicemesh.io/ has 2 links for same (https://docs.openservicemesh.io/) location do we need 2 links?

**Please describe what should be documented
Update links to be relative where possible in docs/content so that we don't have issues in the docs site where the link points to a document for a different version

**Please suggest where in the repo the document should be located
This applies to everything under docs/content

The *_demo.md files in content/docs/tasks_usage/traffic_management/demos/ are not displayed under the Traffic Management Demos section, but rather under the Traffic Management top level section.

Based on the folder structure, I would expect the *_demo.md files to show up under an intermediary Traffic Management Demos folder instead.

This GitHub issue is for fleshing out the OSM documentation around TCPRoute SMI policy and functionality:

• Document TCP Route and how OSM handles TCP traffic -- save the doc in ./docs/wip/tcp_traffic.md (exact location is TBD - wip short term)

  • Why is this needed? What scenarios does it enable? What are examples of these scenarios?
  • What does the SMI policy look like?
  • What would the resulting Envoy config look like?

• Create a small demo with sample apps and SMI showing how this feature works

• List Common Issues

  • What are the error messages when the destination service cannot be resolved?
  • What are the error messages when the source pod has no access to the destination pod?

• Create Troubleshooting Guide

  • What should we do if there's a DNS resolution error?
  • What should we do if there's no access to the remote service

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.

Please describe what should be documented

The anchor of "application requirements" in https://docs.openservicemesh.io/docs/tasks_usage/onboard_services/, 404 not found was returned.

Please suggest where in the repo the document should be located

The topics sidebar on docs.openservicemesh.io should make the hierarchy of topics more discernible. Refer to the following images as an example.

Due to multiline headings, it's not obvious which heading is what without trying to reason it. For example, is Pod and Lifecycle 2 separate topics or 1 topic named Pod Lifecycle?

The problem is exacerbated with longer headings:

Above, it's not evident whether Azure Application Gateway and Demo are 2 topics or 1 topic named Azure Application gateway Demo

**Please describe what should be documented
SMI traffic split uses an apex service, with the apex service being a Kubernetes Service resource. The apex service needs to be configured correctly (have the right namespace, port, selectors etc.) to be able to split traffic to leaf services.

**Please suggest where in the repo the document should be located
https://github.com/openservicemesh/osm/tree/main/docs/patterns

Demo OSM with existing services.

ref openservicemesh/osm#102

A number of images are linked from elsewhere. If we can make the canonical location be the website, and store them in the website repo, we can prevent duplication and the inevitable drift into inconsistency.

Example: #39

To do: find all such examples in this repo.

Verified with @phillipgibson that the Manual Install is missing service deployments for both the bookbuyer and bookthief applications. https://docs.openservicemesh.io/docs/install/manual_demo/

I have successfully followed the steps for the manual demo till below the link:

[https://github.com/openservicemesh/osm/blob/136d902c61b6c0fc2d4eb98215fe3aff0d0e73f7/docs/content/docs/install/manual_demo/_index.md#create-Pods-Services-ServiceAccounts]

where the Kubectl command to create the service accounts fails with this error message:

<< was unexpected at this time.

Is there a missing step at this point in the doc or is there an incorrect syntax in the command?

Document the following when the OSM CLI and the installed Chart version are different:

• expected experience
• known issues
• workarounds

See openservicemesh/osm#2293 for prior discussion and code.

This GitHub issue is for fleshing out the OSM documentation around Certificates and Rotation.

We already have documentation around certs. We should augment these docs and make sure they reflect latest v0.8 version of OSM.

• Document Certificate creation and rotation

  • Why are certificates needed? What are they used for?
  • How many types of certificates we have - this is already documented - ensure it is correct
  • How are certificates created?
  • What's in the cert's CN?
  • When are certs rotated?
  • Can this be changed?
  • Why rotate fast?
  • What are the downsides of rotating too soon? What are the upsides?
  • How are certificates sent to proxies?
  • Would a proxy know when a cert expires? Would the Envoy proxy ask the OSM Control plane for a new cert when the cert has expired?
  • Does OSM preemptively send certs to Envoys before they expire? Should it?
  • Are certificates cached?
  • Are these caches cleaned at some point? When?
  • Is there a particular order we need to follow when sending SDS responses? What happens if you send SDS first, before CDS, LDS etc. for a brand new Envoy w/ blank config state.
  • Where is the root cert?
  • How do you rotate the root cert? What would it take? Do you have to restart the OSM control plane?

• Create a small demo with sample apps and SMI showing how this feature works

  • Show how the Envoy is bootstrapped
  • Show what certs are sent to the Envoy

• List Common Issues

  • Expired certs?
  • Rotating too fast?

• Create Troubleshooting Guide

  • How do you know what Certs an envoy needs? (Check CDS, LDS etc)
  • How do you check whether an Envoy has a needed cert?
  • How do you know whether the cert has expired?
  • What tooling do we have to check certs (both OSM and other - openssl etc.)
  • Make a script available to go through all proxies, check their certs?
  • Are there proxies with expired certs? (Not renewed?)
  • Are there proxies with missing certs? (How do we know a cert is missing?)
  • Are there proxise with certs that are present in the Proxy but not linked to / required by any other *DS component?
  • Scan OSM Controller for cert related errors?
  • Check OSM for creating/rotating certs -- are these taking too long? (Timing should be in the logs -- add it if not) Is rotation happening too fast? Are these counters/metrics exposed via OSM's Prometheus endpoints - could be another GitHub issue if this is the case.
  • Check the certs for the Validating Webhook Configuration and the Mutating WC
    • Are they signed by the expected root?
    • Are they expired/expiring soon?
  • Check the certs on each proxy - do they have the expected CN - does it match the Service Account etc of the Pod they are on?

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.

**Please describe what should be documented
There is a duplicate title for the OSM Manual Demo Guide page https://docs.openservicemesh.io/docs/install/manual_demo/

**Please suggest where in the repo the document should be located
Remove the title markdown and keep the Hugo front matter title instead.

This GitHub issue is to document the caveats and peculiarities of container startup sequencing

• what happens if the payload container starts before the Envoy is configured and it needs to check connection to the outside world
• What tools do we have at our disposal to control the sequence of containers starting?
• What could be expected in logs and Kubernetes events etc when payload container starts before Envoy is ready?
• point to the Kubernetes issue, which may resolve this in Kubernetes eventually
• point to the OSM GitHub Issue, which could tackle this within OSM

For folks using OSM on Azure (AKS or not) - the Application Gateway Ingress Controller would be a great option for Ingress. This is already available as an AKS addon and well documented.

This GitHub issue is for creating documentation on how to use AGIC and OSM together:

• Document the creation of Ingress resource and bringing in AGIC -- save the doc in ./docs/wip/ingress_agic.md (exact location is TBD - wip short term)

  • What traffic is currently working with v0.8 of OSM Controller? Would mTLS work? Would HTTPS work?

• Create a small demo with sample apps and SMI showing how this feature works

  • Create Ingress resource
  • Bring in AGIC (install via Helm or use AKS addon)

• List Common Issues

  • External traffic through Nginx shows an error (point to external docs where possible)
    • 503 - is there a service backing this? Is traffic from ingress to backends HTTP? Would any other traffic work?
    • 502 Bad Gateway - are there endpoints; Are they healthy? Are there custom health checks? Any health checks at all?
    • 404 - check Ingress spec's routes, backends
    • Point to external (AGIC) documentation on common ingress errors: 404, 502, 503

• Create Troubleshooting Guide

• Check Ingress resource for correctness and annotations (point to AGIC docs for this)

• Does the Ingress resource reference an existing Service?

• Does the Service referenced by the Ingress resource have Pods backing it - list the Endpoints

• Check Envoy configuration of one/all of the Endpoints referenced in the Ingress - to these Envoys have an HTTP ingress inbound opened?

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.

This GitHub issue is for fleshing out the OSM documentation around Permissive Traffic Mode.

• Document Permissive Traffic Mode -- save the doc in ./docs/wip/permissive_traffic_mode.md (exact location is TBD - wip short term)

  • Why do we need Permissive Traffic Mode? What value does it add?
  • What is the alternative? (What's the anti-permissive traffic mode?)
  • How do you switch to Permissive Traffic Mode? How do you switch to SMI mode? Are there more than one way to switch?
  • How does it work?
  • What is a sample Envoy config with Permissive Traffic Mode on and off?

• Create a small demo with sample apps and SMI showing how this feature works

  • Is there a common app (2 apps) where we can show a minimal configuration w/ permissive traffic mode works and without it does not work - without SMI policies?

• List Common Issues

  • Are pods not wrapped in a k8s service going to have access to a destination service they connect to?

• Create Troubleshooting Guide

  • Is the right config map changed?
  • Is the key in the config map connect?
  • Is the value in the config map correct?
  • What if the Validation Webhook fails? What's the error one could see? How do we work around it?
  • Has the OSM Controller picked up the change? (Is this visible in logs? Is this visible in events? Is this visible via some HTTP debug API? Should we create a task for this state to be exposed via the debug APIs?)

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create another GitHub issue with a sample function signature - what could it check to see if things are working ok?

**Please describe what should be documented
Various links in the repo are broken either in the website or on Github. We should standardize how we link to docs to ensure they work both in the repo and on the site.

Links should:

1. Maintain the tree when switching between docs in the Github site
2. Maintain the version when switching between docs on the website
   3. Work for both the site and the Github repo

**Please suggest where in the repo the document should be located

This GitHub issue is for fleshing out the OSM documentation around OSM's dynamic iptables configuration:

• Document how OSM Controller constructs dynamically iptables configuration for new pods joining the mesh, for the init container -- save the doc in ./docs/wip/iptables.md (exact location is TBD - wip short term)

  • Documentation on this topic exists - we need to augment it if we need to and ensure it is till up to date for v0.8
  • How do we create additional rules? Are there CLI options?
  • Once a port has been opened via an iptable rule can it be changed? How?
  • Is AKS with AAD a good example for this feature? openservicemesh/osm#1670
  • Does this / Can this affect Dapr?
  • What are sample iptable configurations with and without the CLI option?

• Create a small demo with sample apps and SMI showing how this feature works

• List Common Issues

• Create Troubleshooting Guide

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.

The docs site needs some follow-up css adjustments to clean up and improve the appearance of menus, text layout and overall spacing. Currently the site is responsive, but needs optimizing so that viewers using mobile, tablet and other devices, can comfortably view the use the site.

footer of docs.openservicemesh.io wrapping awkwardly at this size, spotted by @bridgetkromhout

Edit: can someone assign this to me?

**Please describe what should be documented
The different supported application traffic types should be documented. Currently, HTTP, TCP, and gRPC applications have been tested. Document how the application protocol is inferred by OSM to allow traffic filtering and routing.

**Please suggest where in the repo the document should be located
Possibly: https://docs.openservicemesh.io/docs/tasks_usage/traffic_management/

However, this could also be under a folder that describes application requirements and feature support.

The section titles seem off when rendered on the website.

For example, note the size of the title Configuring mesh-wide Egress:
https://github.com/openservicemesh/osm-docs/blob/main/content/docs/tasks_usage/traffic_management/egress.md

On Github (correct):

On the website (wrong):

This GitHub issue is for fleshing out the OSM documentation around Traffic Split SMI policy:

• Document Traffic Split (review existing docs) -- save the doc in ./docs/wip/traffic_split.md (?)

  • What are the various Traffic Split scenarios available?
  • What version of the Traffic Split SMI Spec is supported by v.08? What are all the options enabled by this version?
  • How should the Kubernetes Services be labeled?
  • What's the role of the apex/root service?
  • What are acceptable ranges for the weights?
  • Are there other services that integrate w/ OSM via TrafficSplit?

• Create a small demo with sample apps and SMI showing how this feature works -- we already have a decent Traffic Split demo - create something small within this doc to show what the relevant SMI CRDs should look like

  • Pointers to other services' docs that work with SMI (Argo + SMI comes to mind)

• List Common Issues

• Create Troubleshooting Guide

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.

Please describe the Improvement and/or Feature Request
Currently OSM supports k8s versions >= 1.18 && <= 1.20.2.

This issue pertains to defining the following:

• Min and max k8s versions to support
• Duration of support for a particular version
• Deprecation policy
• Breaking change policy

Scope (please mark with X where applicable)

• New Functionality [ ]
• Install [ ]
• SMI Traffic Access Policy [ ]
• SMI Traffic Specs Policy [ ]
• SMI Traffic Split Policy [ ]
• Permissive Traffic Policy [ ]
• Ingress [ ]
• Egress [ ]
• Envoy Control Plane [ ]
• CLI Tool [ ]
• Metrics [ ]
• Certificate Management [ ]
• Sidecar Injection [ ]
• Logging [ ]
• Debugging [ ]
• Tests [ ]
• CI System [ ]
• Demo [ ]
• Project Release [ ]
• Support [X]

Possible use cases
Support policy for k8s versions.

I closed openservicemesh/osm#2523 but let's determine if that work is needed in this repo.

Task: choose item from https://github.com/openservicemesh/osm/issues/2854

Item chosen: Uninstalling OSM: #2880

Importing the checklist from openservicemesh/osm#2880

Current task: carefully read and test https://docs.openservicemesh.io/docs/install/uninstallation_guide/ and see if it satisfied all the checklist for fleshing out the OSM documentation around uninstalling Open Service Mesh and removing all of its components from a cluster.

• Document the OSM CLI tool and process of uninstalling OSM -- save the doc in ./docs/wip/uninstall_osm.md (exact location is TBD - wip short term)

  • How do you uninstall OSM? What CLI command does that?
  • What is expected to be deleted by using the CLI?
  • What is expected to remain on the cluster by using the OSM CLI?
  • Does the OSM CLI also remove Envoy sidecars from existing pods?
  • How do we remove the sidecars from existing pods?
  • Could this cause downtime?
  • How do we prevent downtime during removal of OSM from the cluster?
  • What happens to the CA?
  • Are there alternatives?

• Create Troubleshooting Guide

  • How do you manually delete Mutating WebhookConfig, Validating WHc, OSM ConfigMap - removed by cleanup hook
  • How do you backup SMI CRDs and delete Custom Resource Definitions (SMI) from the cluster - per openservicemesh/osm#3760 these are no longer to be deleted as part of uninstall. How to delete manually is documented in the uninstall guide
  • How do you remove the CA? - osm-ca-bundle removed by cleanup hook
  • Are there any other artifacts that need to be manually removed?
  • List all artifacts related to OSM and provide a command to remove them
  • How do you manually perform rolling restart to remove Envoy sidecars?
  • How do you remove annotations from namespaces?
  • What namespaces are annotated? What are the annotations that need to be removed (monitor, inject, metrics)
  • How can we remove OSM Controller with 0-downtime?
    • Change MutatingWebhook first? Change to Ignore
    • Shutdown / delete controller?

This is no longer needed, but requires a CNCF Projects admin to delete:
https://app.netlify.com/sites/gifted-pasteur-0dd2d9/overview

Relevent discussion here.

The current three column layout is a lot of squishyness, it's worth looking at a simpler layout where we drop the right-hand-side summary menu (part of the Docsy default) and give the menu and contents more breathing room.

Release v0.8.4 of OSM was released on 5/18/2021. The docs for release-v0.8 should not be marked as archived. We should only mark a version of documentation as archived when we are no longer supporting it.

The banner reads as follows, but a user using release-v0.8.x of OSM should not use the latest docs pointing to the main branch because main docs might not be compatible with the code in release-v0.8.x.

Document how to configure tracing and how it works with OSM.

Document should be located (existing doc): ./docs/patterns/observability/tracing.md

This GitHub issue is for fleshing out the OSM documentation around Egress:

• Document Egress -- save the doc in ./docs/wip/egress.md (exact location is TBD - wip short term)

  • What is Egress?
  • What value does it add? Why do we need it?
  • How does it work?
  • Is it on or off by default? Why?
  • How do you change the value? are there more than one ways to toggle this on off?
  • Is it possible to have fine-grained egress control with v0.8?
  • What's sample Envoy config for a pod w/ egress enabled? What's w/ egress disabled.
  • How does SMI affect egress?

• Create a small demo with sample apps and SMI showing how this feature works

• List Common Issues

• Create Troubleshooting Guide

  • Is egress enabled or disabled?
  • What's the namespace / name of the Configmap that toggles egress?
  • Does the config map have the right key?
  • Does the config map have the right value?
  • Does the OSM Controller realize it is in the right egress mode? How do we know that? Is this reflected in a debug endpoint?
  • Are all pods egress=on/egress=off

• Automate Troubleshooting Guide in pkg/troubleshooter (create appropriate functions) - alternatively create a GitHub Issue with the stub of the function that could be eventually created within pkg/troubleshooter package to automatically troubleshoot this feature.