Skip to content
This repository has been archived by the owner on Nov 20, 2023. It is now read-only.

add daemon or watch mode equivalent of tye run #13

Open
rynowak opened this issue Mar 1, 2020 · 6 comments
Open

add daemon or watch mode equivalent of tye run #13

rynowak opened this issue Mar 1, 2020 · 6 comments
Labels

Comments

@rynowak
Copy link
Member

rynowak commented Mar 1, 2020

The idea is that we can leave the host and dashboard running, and services can drop in and out.

@rynowak rynowak added the idea label Mar 1, 2020
@rynowak rynowak added this to the backlog milestone Mar 1, 2020
@ChadJessup
Copy link
Contributor

Just a thought, but could the dashboard be in a container that is automatically added to a tye.yaml?

It'd be useful to have a preexisting and non-trivial working component in a new tye project by default. Especially one that uses some of the newer goodies like Blazor, and potentially uses the very features that tye offers for microservices...

@davidfowl
Copy link
Member

What does the dashboard being in a container gain you?

@ChadJessup
Copy link
Contributor

What does the dashboard being in a container gain you?

No must-haves, but aside from the built-in sample I mentioned above, I think it'd also be useful to a user of tye for a few other reasons:

  • Bootstrap: Bellwether service showing that everything is working (docker/dotnet core/kubernetes/tye/permissions/registry)
  • Bootstrap: A built-in dashboard is a great bootstrapping tool.
  • Decouples tye CLI from a web page - this has confused me a few times, as closing a terminal window rarely impacts a web page in my experience.
  • Can restart/shutdown the dashboard directly if it's not needed.
  • Can deploy the dashboard to k8s as well with deploy, which could keep the same experience as local dev, and give immediate access to logs, health (Add heathcheck support #19), metrics after deployment. Potentially even use k8s's downward APIs to help manage things if something like replication, and lifecycle control is planned from the dashboard itself (shutdown, restart, spin up five of these, etc).
  • I imagine tye CLI could be used to point to different hosts like kubectl's --context flag. But, I'm not sure how intertwined the dashboard and hosting functionality are.

Cool thing is tye already knows how to create containers and helm charts, could be like an embedded resource thing that turns into a container...but, just thinking out loud on that 🤔.

@davidfowl
Copy link
Member

Decouples tye CLI from a web page - this has confused me a few times, as closing a terminal window rarely impacts a web page in my experience.

Yes I think that's one of the reasons for making that kind of experience in the first place. We'll have to do something like this anyways to make it run in the cluster.

I'm hesitant to rely on docker for core functionality but it might be fine as a mode.

@staff0rd
Copy link
Contributor

staff0rd commented May 6, 2020

Presume this would watch tye.yaml for changes and recreate containers based on changes to the .yml, rather than currently having to kill/restart tye run

@rynowak
Copy link
Member Author

rynowak commented May 6, 2020

Yes, we super want this 👍

The work that I did this milestone with diagnostics integration makes it even more important because those things are slow to start.

@philliphoff philliphoff removed this from the backlog milestone Sep 29, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants