Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

admin story: versions management #20

Open
jackfrancis opened this issue Apr 6, 2016 · 6 comments
Open

admin story: versions management #20

jackfrancis opened this issue Apr 6, 2016 · 6 comments

Comments

@jackfrancis
Copy link
Member

As a deis cluster admin I need to be able to easily determine if the cluster components are up-to-date so that I can keep the cluster current with the latest stable versions.

@jackfrancis
Copy link
Member Author

This issue should track a simple HTTP interface (e.g., a route handler) that exposes the complete set of installed deis components in a deis cluster, and whether or not those components have a newer version available to download/install. I.e., an implementation of types.ComponentVersion with a populated UpdateAvailable property.

@arschles
Copy link
Member

note that we may want to add commands in workflow-cli to access this API. may need an issue in that repo to accompany this

@bacongobbler
Copy link
Member

bacongobbler commented May 18, 2016

Yeah I'd like to see something like this implemented, but I wonder what our UX story is for this. Do we need to create a separate admin client that creates an SSH tunnel so the administrator can access these APIs (revive deisctl?), or would the admin have to SSH into the cluster to consume this API? I don't think we'd want to expose workflow-manager out to the public unless it was backed by auth, for example.

@arschles
Copy link
Member

@slack mind commenting here about the questions that @bacongobbler brought up above? Added context would be helpful here

@bacongobbler
Copy link
Member

bacongobbler commented May 18, 2016

One way to tackle this would be to add an API endpoint to the controller that proxies the request over to workflow-manager (similar to deis logs) and checks that the user making the request is an administrator, but at that point we might also want to consider breaking out the authentication module into its own in-cluster SSO, and that is a bit too much to chew off for a release candidate.

@slack
Copy link
Member

slack commented May 18, 2016

Since we don't yet have a workflow admin tool, the original thought was to use kubectl proxy to access workflow-manager on their k8s cluster. That follows the pattern for k8s dashboard, etc.

After authentication issues are sorted out, we could use deis-router to expose an interface. But that is well down the road, for now.

Back to the original design doc, the user stories here are:

As a Workflow Manager User I should:

  • be able to view a simple web UI that I can reach through the kubernetes proxy
    • I should not have to authenticate to this UI
  • be able to view a list of services, replication controllers and pods that are installed or running in the Deis namespace
    • so that I can quickly, at a glance, know if all the components are installed
  • be able to see the versions of installed workflow components, and be notified if they are out of date
    • annotations, container images, (whatever makes sense here)
  • see a large banner if deis workflow components are out of date
  • poll a hosted releases API off-cluster for release information at least every 12 hours

So a data API and a simple web page that cluster admins can view to see installed components, versions and know if things are out of date.

At this point, I'd even be happy with workflow-manager sending version information to stdout so you could get at it with kd get logs workflow-manager.

arschles added a commit that referenced this issue May 18, 2016
This commit hooks up the `data.AvailableVersionsFromAPI` `Refresh` function to the workflow-manager versions API (i.e. `versions.deis.com` in production deployments), so that running instances of workflow-manager can compare the latest available versions of each component with the versions running currently in the cluster. This functionality sets the stage for features such as those described in #20 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants