[don't merge, just sample]test prometheus operator

[SamYuan1990]

Signed-off-by: Sam Yuan yy19902439@126.com

[SamYuan1990]

@jkneubuh , @mbwhite I made a CI testing with prometheus operator as this pr, and it looks good from CI.
https://github.com/SamYuan1990/full-stack-asset-transfer-guide/runs/7481689314?check_suite_focus=true
I tried to make a same thing in full-stack-asset-transfer-guide, but in CI of that repo, I received error as

error: timed out waiting for the condition on ibppeers/org2-peer2
Error: Process completed with exit code 1.

[mbwhite]

@SamYuan1990 I ran in to similar problems, trying to start the peers. Had to reduce what the gha workflow did.
No logs of the kind cluster being available, my guess would be that there just aren't the resources available.

Perhaps it's just too much to ask to start a cluster inside github actions workflow.

[SamYuan1990]

@SamYuan1990 I ran in to similar problems, trying to start the peers. Had to reduce what the gha workflow did. No logs of the kind cluster being available, my guess would be that there just aren't the resources available.

Perhaps it's just too much to ask to start a cluster inside github actions workflow.

one thing I want to confirm that when we use full-stack-asset-transfer-guide, will it start a kind cluster with local registry?
in fact, learn from performance sandbox github action.
I meet similar problems on minikube one day suddenly as CI running as schedule.
but if we have kind with local registry, then it will pass.
hence I am doubt that for any k8s running in github action without local registry, the pod may fail as it takes time to download the image to start the pod and which fails as timeout.

[mbwhite]

@SamYuan1990 yes correct;

[jkneubuh]

• Full stack asset transfer does NOT currently launch the localhost:5000 docker registry. (It should .... as we will need a way to demonstrate a build of a chaincode package for the k8s builder.)

• The prometheus / grafana monitors will NOT fit in to the GHA executor while running the sample network. The test machines have 7 GB of RAM, which is barely enough to run the network.

• The prometheus setup is very useful, and should be added to the network scripts and called from the CI test runs. (I have another PR coming up that will set up the prometheus-operator and ingress for prom/grafana.) If this lands, can we change this PR to just set up a cluster with prometheus, operator, and a single peer?

[SamYuan1990]

• The prometheus setup is very useful, and should be added to the network scripts and called from the CI test runs. (I have another PR coming up that will set up the prometheus-operator and ingress for prom/grafana.) If this lands, can we change this PR to just set up a cluster with prometheus, operator, and a single peer?

In my point of view, we don't need to merge this pr.(even if I am the author...)
back to the question how fabric working with prometheus?

• fabric enable some port and setting point to prometheus.
• prometheus part been configured and able to get data(pull) from fabric(peer/orderer)

hence, we need to support all kinds of prometheus,
For case below:

• prometheus is in same k8s cluster and it deployed by any tool, in this case prometheus operator just one of them.
• prometheus is not in same k8s cluster, maybe deployed even out side k8s. so ... in this case, works with ingress to get pod status for peer/orderer.

so I changed this pr with title as don't merge, just sample.

@jkneubuh , @mbwhite, I would like to make prometheus operator integration as a part of document.
but.. on the other hand, before we close this PR, I am not sure if we follow xAC(something as code), should we make a sample code/CI in fabric operator repo?