Bug 1435235
| Summary: | containers: identical volume name for different volumes in different pods is not useful for users (at least not admin) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Dafna Ron <dron> | ||||||
| Component: | UI - OPS | Assignee: | Nimrod Shneor <nshneor> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | juwatts | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 5.7.0 | CC: | dajohnso, epacific, fbladilo, fsimonce, hkataria, jhardy, mpovolny, obarenbo, simaishi | ||||||
| Target Milestone: | GA | Keywords: | TestOnly, ZStream | ||||||
| Target Release: | 5.10.0 | Flags: | nshneor:
needinfo+
nshneor: needinfo- |
||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | container | ||||||||
| Fixed In Version: | 5.10.0.0 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 1552889 (view as bug list) | Environment: | |||||||
| Last Closed: | 2019-02-11 13:55:24 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | Container Management | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 1594567 | ||||||||
| Bug Blocks: | 1552889 | ||||||||
| Attachments: |
|
||||||||
|
Description
Dafna Ron
2017-03-23 12:37:33 UTC
Franco, keep me honest here. The reason that the above volumes are shown this way in the UI is that in the 5.7 template released the name of the volume is hardcoded to "cfme-app-volume", although this name only applies in the project itself, I see the point that it is confusing. But this is actually not a bug. However for 5.8 we have changed the behavior a bit, And the template $NAME is used as a part of the Volume names (and PVCs) in the template, meaning that if you want to install multiple times podified cfme you probably want to change the name of the template to differentiate the different instances, and there for the volume names will change accordingly. I tend to CLOSE NOTABUG this bug. Franco ? (In reply to Barak from comment #1) > I tend to CLOSE NOTABUG this bug. In addition: all volume names are scoped by Pod and I am sure there are othere repeating over and over again in multiple Pods (e.g. volumes for secrets, etc.) I assigned this to Zahi to check if there was anything we could do to improve the situation (I can't think of anything, but I didn't dedicate any time to think about this). Maybe if it's a persistent volume we should also mention the name of the persistent volume? (which is unique) Anyway we should evaluate if it's worth the trouble. Barak,
Yes, in 5.8 we use ${NAME} as part of the PVCs and volume name, this is parametized, it holds the naming for all frontend objects, and can be used to obtain the effect that I believe is being requested.
oc new-app .... -p NAME=miq_xxx
Relevant template declaration :
volumes:
- name: ${NAME}-region
persistentVolumeClaim:
claimName: ${NAME}-region
...
volumeClaimTemplates:
- metadata:
annotations: null
name: ${NAME}-server
...
The naming of the backend PVs is entirely up to the admin.
One thing we can do to improve the Pod page is adding a link to the Persistent Volumes the pod uses in the relationships table. There is currently an ongoing work on adding Persistent Volume => Pods direction in https://github.com/ManageIQ/manageiq/pull/14231. So I suggest we start with adding the other direction too. Please assess the importance of this issue and update the priority accordingly. Somewhere it was missed in the bug triage process. Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#priority for a reminder on each priority's definition. If it's something like a tracker bug where it doesn't matter, please set it to Low/Low. Created attachment 1382844 [details]
Pod Summary PV
Verified on 5.9.0.16.20180109204148_7ac9852 From my point of view i didn't see improvement on the UI that solve this issue. 1. On Pod summary view, on Volume table, the volume name is not identical to what i get on OCP, for example: oc get pv -n openshift-metrics NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE metrics-volume 10Gi RWO Retain Bound openshift-infra/metrics-cassandra-1 20d prometheus-alertbuffer-volume 10Gi RWO Retain Bound openshift-metrics/prometheus-alertbuffer 20d prometheus-alertmanager-volume 10Gi RWO Retain Bound openshift-metrics/prometheus-alertmanager 20d prometheus-volume 10Gi RWO Retain Bound openshift-metrics/prometheus 20d registry-volume 5Gi RWX Retain Bound default/registry-claim 20d On UI , see attach Pod summary Image. 2. From Pod Summary , Relationships table, there is no link to the PV. see attach Pod summary Image. There is an open isse on manageiq-ui-classic (specifically on GTL) which prevents the UI side of this bug from being solved.. (https://github.com/ManageIQ/manageiq-ui-classic/issues/18) Barak, what do you think would be a good way to continue with this? Currently this is stuck on UI. So I was able to solve this and there is a new PR for this bug: https://github.com/ManageIQ/manageiq-ui-classic/pull/3299 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |