search

openshiftio / openshift.io

Red Hat OpenShift.io is an end-to-end development environment for planning, building and deploying modern applications.
https://openshift.io
97 stars 66 forks source link

how should we deal with Pipelines/Resources not labelled with a space? #892

Open joshuawilson opened 7 years ago

joshuawilson commented 7 years ago

From @jstrachan on June 21, 2017 7:51

Its possible to have kubernetes/openshift resources created without a label for the space. e.g. old projects created before the wizard associated the current space as a label have no space label. Folks can create resources or pipelines in multiple ways (openshift console, templates, oc CLI) which don't have the space label.

So how can we view the spaceless resources? Do we need a special space called none? Or have an All space where we don't filter at all?

Maybe an All space might be handy for the Create tab to look at all of your codebases/pipelines/resources across all spaces anyway?

@catrobson @pmuir

Copied from original issue: fabric8-ui/fabric8-ui#1557

joshuawilson commented 7 years ago

From @maxandersen on June 22, 2017 13:58

As comment on the "all spaces" then that is a great idea but assumes (I reckon) we can query across possible multiple clusters somehow efficiently - also Che workspaces and some aspects of planner aren't really well fitted inside a "all space view"

For this specific item of "non-labelled" items I would think it would make more sense to have them on a separate tab or checkbox within a single space's overview of jobs/pipelines. So you can just easily toggle on/off "Include detached/orphaned pipelines" without having to leave.

Then you could have a "Attach to space" action on them which would add a label.

joshuawilson commented 7 years ago

From @jstrachan on June 22, 2017 14:4

@maxandersen the UI only works on one OpenShift cluster at once so we don't need multi-cluster queries any time soon. One day federation may make multiple clusters look like 1 (and provide a single API to multiple physical clusters); but I'd expect there to be a single development cluster really.

The entire Create/Codebases/Pipelines/Apps/Environments UI is designed around going into a Space first; then filtering those resources by that space. So I'm not sure the checkbox thing or separate tab works from a UX perspective; I think having a different kind of space/group/area might be the simplest thing; so you can switch between your recent Spaces or All - then the navigation & UI is consistent everywhere and stays clean. Maybe one day a Group Spacecould represent a collection of other spaces too?

Anyways I think its best we leave this to UX; whichever way we go is pretty trivial to implement; its more about the right UX really

joshuawilson commented 7 years ago

@jstrachan 1) Do you want to associate "resource" with a space? 2) Do you want to view/work with non-labeled "resources" and leave them "non-labeled?

joshuawilson commented 7 years ago

From @jstrachan on June 22, 2017 15:37

  1. we already do, via a label of space: nameOfSpace in OpenShift (Pipelines, Deployments, Services etc)
  2. be able to view resources using a space filter; or view all resources whether they are associated with a space or not
joshuawilson commented 7 years ago

Let's have @fabric8io/uxd look at it.

joshuawilson commented 7 years ago

From @catrobson on June 23, 2017 1:27

While I think this is a valid use case for users converting their apps over into OpenShift.io, I don't think this was a primary concern for MVP. I agree we need to put some UX thought into the use case of migrating apps into OpenShift.io, but feel it should go from that use case instead of just adding a page that shows a set of resources that might not make much sense to the user.

Can we postpone this until we consider migration/importing existing projects a priority?

joshuawilson commented 7 years ago

From @dgutride on June 26, 2017 13:57

@jstrachan @catrobson - from looking at the code, it seems that our current behavior means we include items that are not labeled so my rogue pipelines are always visible.

In my environment, it means my spaceship pipelines (that didn't get labeled somehow) show up in all of my space dashboards instead of filtering unlabeled items out by default.

joshuawilson commented 7 years ago

From @catrobson on June 26, 2017 14:6

@dgutride Thanks. I think that is probably not the behavior we desire at this point. I think we don't want to show any pipeline or other artifacts which are not labeled. If it is not labeled, my assumption is that there is some migration path we need to build to allow people to import these items, rather than surprising a user by showing them without any context.

joshuawilson commented 7 years ago

From @maxandersen on July 10, 2017 17:43

@jstrachan how about we for now limit to show only what is in the space explicitly and for any "orphaned" builds users will go directly to jenkins and browse ?

joshuawilson commented 7 years ago

From @sbose78 on July 10, 2017 19:54

Here's a way to manually fix the problem https://github.com/openshiftio/openshift.io/wiki/FAQ#my-pipelines-are-not-being-properly-filtered-by-my-space

On Jul 10, 2017 11:14 PM, "Max Rydahl Andersen" notifications@github.com wrote:

@jstrachan https://github.com/jstrachan how about we for now limit to show only what is in the space explicitly and for any "orphaned" builds users will go directly to jenkins and browse ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fabric8-ui/fabric8-ui/issues/1557#issuecomment-314181052, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhSAPRlW5VabpklcVMBGR8JSEHbd-uGks5sMmLdgaJpZM4OAlMv .

joshuawilson commented 7 years ago

From @jstrachan on July 11, 2017 6:6

@maxandersen its not just BuildConfigs / Builds we use the same logic for all kubernetes resources too (Deployments / Services / Pods / ConfigMaps etc). Having an 'All Space' seems more consistent and avoids having a mostly broken UI where stuff goes invisible.

Remember in OpenShift folks can create BCs via the CLI or OpenShift console which don't know to add a magic space label to work well inside the openshift.io console. I'd rather not make a weird and confusing UI

qodfathr commented 6 years ago

I'm going to restate this issue is a slightly less technical, less implementation-specific way. @joshuawilson please correct me if I am wrong.

"How should OpenShift.io handle artifacts within a connected environment which were not created by OpenShift.io."

Absent of some better word-smithing, is that effectively correct?

I'm going to assign this to myself, as it needs a top-level Scenario. Also, removing the SEV3 because it's not a bug.

joshuawilson commented 6 years ago

@qodfathr that sounds right to me.

dgutride commented 6 years ago

@qodfathr @joshuawilson - there is a design we are trying to move toward that would look at the Openshift environment on application load to see if there are resources in there that were created outside of openshift.io: https://redhat.invisionapp.com/share/WRE22FA2B#/screens/260370530 -

We had requested an API that could detect suitability of the environment to be used on this page: https://github.com/openshiftio/openshift.io/issues/1748 - it seems to be all related to this issue.