[WIP][DOCS]: We need to align the `Makefile` and `readme.md` together

[MRGuziX]

Right now I believe there is a misalign with readmie.md files and Makefile commands.

Right now I have made some refactor for Makefile and readme.md file for google adk agent
#39

If you could take a look on what I introduced in those two files.
I believe we need to do some changes in other agents and readme.
So user with a use of make... commands going one by one with them will be able to make agent working locally or deploy on openshift cluster.

---

When we start llama server in terminal we need to keep it and then open new at root folder.
Then we do:

cd agents/google/adk
make run-app

So we go in the folder then make run-app:

run-app: ## Run agent locally with hot-reload
	@source .venv/bin/activate && set -a && source .env && set +a && \
	  lsof -ti:$${PORT:-8000} | xargs kill -9 2>/dev/null; true && \
	  uv run uvicorn main:app --host 0.0.0.0 --port $${PORT:-8000} --reload --reload-exclude .venv

in which we activate venv then set .env variables, next kill the process so we will not spawn another one, and then run agent.
and that process follow other commands and steps.

added information to login to OC and DOCKER:

---

Command:

make deploy

Mby it should delete previous agent before deploying new one?

[MRGuziX]

@mpk-droid @tarun-etikala @Wojciech-Rebisz

Lets make some discussion about that. Any thoughts ?

[tarun-etikala]

The setup for Ollama and llama-server was moved to local-development.yaml as it was an infrastructure setup and common across agents. But if duplicating it in the agent readme gives visibility and ease for a user, I am okay with having at the agent level. (We also need to provide option to user to select the model in make ollama )

[tarun-etikala]

• I agree with adding oc login, docker login steps in readme
• In make run-app venv activation might not be needed as uv run handles it.
• For make ollama/llama-server as well we could use uv to handle the venv
• I like the kill-before-run approach but it might be aggressive as it might kill a different app and might cause data loss(could probably use some softer approach like a warning/ approval from user)
• for make deploy helm can patch if a deployment already exists but we can do a delete before deploying for a cleaner setup

[MRGuziX]

@tarun-etikala
readme gives visibility and ease for a user
I believe it is not too long. And what is more user will not jump around like a bunny in repository.

We also need to provide option to user to select the model in make ollama
Thats interesting idea, but in the same way I am not sure. We could add information that we will be using model X and Y by default if you want to change the pulled models you can do it by yourself in makefile. There are many models to be pulled, and if those are "starter" kits then user should have some possibilities but changing stuff should be not too wide.

In make run-app venv activation might not be needed as uv run handles it.
hmm uv run do activate .venv in that dir. Will take that into consideration.

I like the kill-before-run approach but it might be aggressive as it might kill a different app and might cause data loss(could probably use some softer approach like a warning/ approval from user)
Yea i like it too. I mean we can show some warning, but when user will fire many times those commands without clearing stuff there will be spawned deamons that sometimes are hard to deal with. Mby add some flag -hard or -kill to that command and if it is passed then we kill the processes if not we spawn new?

for make deploy helm can patch if a deployment already exists but we can do a delete before deploying for a cleaner setup
TBH yesterday i had a situation that I deployed agent with apikey X -> then that apikey lost its functionality -> and after I do the deploy agan with new apikey it still do not work. I needed to undeploy and then do deploy again to make it work. What is more this mechanism (If this repo is pointed towards people that is starting theirs adventures with agents) will be guarding from trashing and overpopulating clusters with deployments.

[tarun-etikala]

Agree with the points.
We can have make deploy to delete previous agent before deploying a new one