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

Mechanism to Query for Channels #171

Closed
sferich888 opened this issue Oct 16, 2019 · 26 comments
Closed

Mechanism to Query for Channels #171

sferich888 opened this issue Oct 16, 2019 · 26 comments
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. triage/support Indicates an issue that is a support question.

Comments

@sferich888
Copy link

sferich888 commented Oct 16, 2019

As a user of the graph, how do I know what channels are available or presented by my Cincinnati service?

@steveeJ
Copy link
Contributor

steveeJ commented Oct 17, 2019

This depends entirely on the configuration. A channel is not a first-class element in the Cincinnati protocol, and is implemented only in the openshift specifics built on top and through the channel filter plugin which expects certain metadata being available in each release to indicate the channels, and filters according to a request parameter sent by the client.

We've been configuring the graph-builder to expose the unfiltered graph. The policy-engine engine points to the graph-builder builder as its upstream, and does the filtering on each user request. If a user wanted to know all the available channels (read: have access to an unfiltered graph on which it can investigate the metadata), they would need access to the graph-builder endpoint, or to a policy-engine which doesn't have the channel-filter plugin configured.

@steveeJ steveeJ added the triage/support Indicates an issue that is a support question. label Oct 17, 2019
@sferich888
Copy link
Author

sferich888 commented Oct 17, 2019

You require a parameter of channel, to query the graph. I don't know how you can get an unfiltered graph.

So if this is required to get updates shouldn't we expose a way to list the channels, or as you say list the unfiltered graph?

@steveeJ
Copy link
Contributor

steveeJ commented Oct 17, 2019

So if this is required to get updates shouldn't we expose a way to list the channels, or as you say list the unfiltered graph?

Yes, it will allow you to examine the available channels by looking at all release metadata.
Though, this depends entirely on the configuration of the instance we're talking about and doesn't require a new feature or code change in here. It requires a configuration in the API gateway, or whatever sits in front of the graph-builder instance we're talking about.

@sferich888
Copy link
Author

sferich888 commented Oct 17, 2019

With OpenShift as an example how do we pull the full graph?

@kbsingh
Copy link

kbsingh commented Oct 17, 2019

@jhernand for visibility for anything we need at api layer

@crawford
Copy link
Contributor

crawford commented Nov 6, 2019

We will never expose the full graph, since that may contain embargoed builds. Eventually, we should expose a safe graph (bonus points for providing a way to visualize the raw data) so that customers can understand the broader landscape and plan their upgrade path.

@sferich888 what use case did you have in mind for needing a list of channels?

@sferich888
Copy link
Author

sferich888 commented Nov 13, 2019

@sferich888 what use case did you have in mind for needing a list of channels?

As a user (admin) of a cluster, how do I list or view the graph or path my cluster can take between tow versions.

This is fairly simple to do if you know the you want to get updates from. However, we don't really provide a way to list or query for the available channels, so that graphs or path diagrams can be built.


As a developer, of the console, it would be nice to not have to hard code into the UI, JS, what channels a user can select. Being able to dynamic build a list of channels is a better solution.

  • this may help with a disconnect story, if we ever let users mirror or sync graphs between Cincinnati instances.

@sferich888
Copy link
Author

sferich888 commented Nov 13, 2019

(bonus points for providing a way to visualize the raw data) so that customers can understand the broader landscape and plan their upgrade path.

We already do/have this! https://github.com/openshift/cincinnati/blob/master/hack/graph.sh

This can be rendered with: https://visjs.org/, so it's simple a matter of exposing this to users not making (application/json requests to the Cincinnati endpoint /graph).

@steveeJ
Copy link
Contributor

steveeJ commented Nov 14, 2019

This can be rendered with: https://visjs.org/, so it's simple a matter of exposing this to users not making (application/json requests to the Cincinnati endpoint /graph).

I'm not opposed to serving the graph as image/svg, so the console could render it. Is that what you're proposing?

@steveeJ
Copy link
Contributor

steveeJ commented Nov 14, 2019

I'm not opposed to serving the graph as image/svg, so the console could render it. Is that what you're proposing?

That would be best discussed in a separate issue. We actually have a ticket on our (still internal) jira instance.

WRT to the issue being discussed here, it's fairly simple to build a list of channels and expose it in Cincinnati. It would also be fairly simple to have the CVO compile this list after it fetches the graph from Cincinnati and expose this list in the cluster. @sferich888 Would you be opposed to the latter?

@sferich888
Copy link
Author

sferich888 commented Nov 14, 2019

I think external clients also need to be able to pull the list of channels.

@crawford
Copy link
Contributor

crawford commented Nov 14, 2019

As a user (admin) of a cluster, how do I list or view the graph or path my cluster can take between tow versions.

This is fairly simple to do if you know the you want to get updates from. However, we don't really provide a way to list or query for the available channels, so that graphs or path diagrams can be built.

Even if you have the list of channels, this is difficult to answer at a glance. You would have to fetch one graph for each channel and then reconstruct the pieces. It's certainly possible, but I think I'd rather we just showed the entire graph (which could then be parsed or rendered).

As a developer, of the console, it would be nice to not have to hard code into the UI, JS, what channels a user can select. Being able to dynamic build a list of channels is a better solution.

I'm not convinced that it is a better solution. We were very successful with Container Linux and Core Update without this functionality and I'm a little worried that this added complexity has land mines (e.g. what if an end user with an on-prem Cincinnati changes the channel name? how do we ensure that the list of channels served to clusters is actually applicable?).

Can you elaborate a bit on why you think we need to be able to dynamically update the list of channels?

@sferich888
Copy link
Author

sferich888 commented Nov 15, 2019

I don't think we need to update I think we need the ability to query.

@steveeJ
Copy link
Contributor

steveeJ commented Nov 15, 2019

I don't think we need to update I think we need the ability to query.

I don't understand what you mean by updating in this context, especially when opposed to being able to query.

Besides, would you mind addressing the question I asked in #171 (comment)?

@sferich888
Copy link
Author

sferich888 commented Nov 16, 2019

I think things outside of the cluster (other clients) need to be able to query for the channels. Not just the cvo.

@steveeJ
Copy link
Contributor

steveeJ commented Nov 18, 2019

I think to really be able to help you I need a comprehensive use-case description. I'm trying to put the pieces together but it's still not entirely clear to me what the motivation here is.

In the original issue description you wrote "as a user of the graph". How did that user retrieve the graph in question?

@wking
Copy link
Member

wking commented Nov 19, 2019

You can get channels now:

$ curl -sH 'Accept:application/json' 'https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.2' | jq -r '.nodes[] | select(.version == "4.2.4").metadata["io.openshift.upgrades.graph.release.channels"] | split(",")[]'
candidate-4.2
fast-4.2
stable-4.2

To use that from the console, we need to give ClusterVersion a place to store it, which we don't have now.

As a user (admin) of a cluster, how do I list or view the graph or path my cluster can take between [two] versions.

I'd rather handle this with a "I'd like to be on channel" property on ClusterVersion, after which the CVO and Cincinnati would transparently suggest update targets to walk you towards your target channel without leaving your current channel. But that sounds like a separate issue from "Query for Channels".

@sferich888
Copy link
Author

sferich888 commented Nov 20, 2019

@wking this command still requires a version (major.minor) input. We should be able to ask for 'all channels' without any input.

@steveeJ we can discuss on slack if it would help in understanding the use case[s]. I feel the two I have given should be sufficient to understand the basis of the request.

@wking
Copy link
Member

wking commented Nov 21, 2019

We should be able to ask for 'all channels' without any input.

What is your use-case for this? You don't need it for the console's channel-selector spinner.

@rjhowe
Copy link

rjhowe commented Dec 9, 2019

It just would be nice to be able to know what channels are available and currently have published content on them in case one wants test running a cluster using that channel.

@admiyo
Copy link

admiyo commented Jan 4, 2020

The ability to query for a specific form of data, priviledged or otherwise, is an access control decision, and should not be built into the structure of the application.

The ability to query for all channels may well provide too much information for a user to be able to parse realistically. Instead, there should be a way for a user to navigate to the set of information they require.

Imagine a future where there are 1000 channels. A user might be subscribed to 10 of them. If they wish to request access to more channels, the service needs a way to expose this information in a scalable manner. Typically, this is done using a directed acyclic graph (DAG) of categories. Essentially, this is the same kind of logic that Graph builder is already managing, just applied to the the channel abstraction as well as the individual images (IIUC).

When a user makes a request like:
https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.2
They are requesting a specific subgraph. The query requested would make more sense to be something like:

https://api.openshift.com/api/upgrades_info/v1.1/channels

Which would list the set of available channels, with a link from each node to the query for that channel. The set of channels available would be limited based on the users access control. A channel would be in one of 3 states: subscribed, available, or invisible. Only the first two states would be returned.

Note that requiring a parameter like ?channel=a breaks discoverability; it makes it impossible to learn an API from direct queries.

https://api.openshift.com/api/upgrades_info/v1.1/ should return:

{
channels: "https:..."
graph: "https:..."
}

@sferich888
Copy link
Author

sferich888 commented Jan 4, 2020

@admiyo this would work for my or supports needs to communicate available graphs (channels) to customers. +1 for this proposal.

@openshift-bot
Copy link

openshift-bot commented Sep 24, 2020

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 24, 2020
@openshift-bot
Copy link

openshift-bot commented Oct 25, 2020

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 25, 2020
@openshift-bot
Copy link

openshift-bot commented Nov 24, 2020

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 24, 2020

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. triage/support Indicates an issue that is a support question.
Projects
None yet
Development

No branches or pull requests

9 participants