portworx / katacoda-scenarios

Examples for illustrating Portworx installation and operation

Visit http://docs.portworx.com for more documentation on installing and running Portworx.

Contributing

1. Fork https://github.com/portworx/katacoda-scenarios
2. Sign up at https://katacoda.com using your github ID
3. Link katacoda and your github repo using: https://www.katacoda.com/profile/create-first-scenario/git
4. Learn basics about creating scenarios: https://www.katacoda.com/docs/create-first-scenario/git
5. Add/Update Portworx scenarios, trigger the webhook in your github repo and observe changes in https://katacoda.com/your-user-id

katacoda-scenarios's Issues

Project missing LICENSE file

px-helm-mongo images are inaccessible

The images on px-helm-mongo are inaccessible. It looks like you need permissions to access the published document.

https://docs.google.com/a/portworx.com/drawings/d/e/2PACX-1vSvx983Y0q1B6gZY-4BzFNKQ_u7hdIAw25hDDQpbVaobR9ny17ZsbWgsGFTsMehrKXVxFSqaSTfzpvv/pub?w=574&h=316

Katacoda supports hosting images:

1. Create an "assets" folder.
2. Upload images (png)
3. Update URLs to use path, for example: https://www.katacoda.com/portworx/scenarios/px-helm-mongo/assets/image1.png

in px-minio scenario, using mc via endpoint addr (per-pod) instead of just using the svc addr?

on the px-minio scenario, i notice that on step 5, you are defining the MINIO_ENDPOINT env variable directly-based on the service's endpoint, which is the backend the service proxies.

it's unclear to me why you aren't just using the service's (clusterIP) address directly?

you're in-effect by-passing the svc's very load-balancing nature (granted you're only load "balancing" that one available pod since your replicacount is exactly 1).

but if you instead if in that step you grep for "IP:" instead of "Endpoint", you wouldn't need on step 7 to re-define the MINIO_ENDPOINT again for the new end-point since a new pod was launched.

in effect, you're defeating the whole point of having a kubernetes service front-end'ing the back-end pods..

katakoda fails with with capacity error as below

Is this a BUG REPORT or FEATURE REQUEST?: Its bug

What happened:

What you expected to happen: katakoda fails with "We are currently at capacity with no additional nodes available. Please check back in 10 minutes."

How to reproduce it (as minimally and precisely as possible): every time we can try and reproduce it

Anything else we need to know?: NO

Environment:

• Container Orchestrator and version:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:
  

use split screen for autopilot

• allow active IO in one and AutoPilot events in another.

update deploy-px-k8s to internal etcd