Murano

Dynamic fields on a Service Details page

Registered by Alexander Tivelkov

Currently, service details page (murano/%env_id%/%service_id%/) displays a fixed set of fields: ID, name, type, status etc, most of them are hardcoded (in a poor, pseudo-dynamic coding style, using 'if hasattr()' statements).

As we have added a dynamic UI for service definitions, it should be also used for displaying the details of the already deployed services. Theoretically, all the data which was entered by the user during the env configuration, should be displayable for the deployed service.

In practice, there may be some fields which should remain hidden in both definition and details, and some fields may be hidden on definition but should be visible on details.
For example, the details page may return the floating ip address which was assigned to the instance, while this address definitely is not user-editable at the design time.

This feature may be used to inform the user about the important deploy-time computed data.

Blueprint information

Status:
Started
Approver:
Alexander Tivelkov
Priority:
Medium
Drafter:
Alexander Tivelkov
Direction:
Approved
Assignee:
Timur Sufiev
Definition:
Approved
Series goal:
None
Implementation:
Blocked
Milestone target:
None
Started by
Timur Sufiev

Related branches

Sprints

Whiteboard

It's not clear which params user will set and whitch are not beacause some of them are optional (domain, unit_naming_pattern, floating_ip) If we tell user to set such outputs in advance (in a service definition form as an example) user will do redundent work to fill the same information in forms.
Also some parametes will be available after deployment - so we will need to check env-t status anyway (for now we are checking attributte presense)
So for me it will be almost the same amount of if closures only in different format - do we need that?

How it could be done in my opinion (@tsufiev):
1. Currently every service field has a 'hidden' True|False attribute which determines whether this field is shown in the Service Creation form or not. This attribute may be superseded with a 'visibility' attribute with possible values read|write|both|none, having 'both' value by default. Read-visible fields will be shown on the Service Details page, but will be hidden during Service creation. Write-visible fields have the opposite visibility. Both-visible fields are shown both during Service Creation and on Service Details page, while none-visible fields are shown nowhere (used for system purposes).
2. If a read|both-visible field was not specified in Service Creation form (and no value was automatically calculated during deployment), then even if such attribute exists for a given service, its value is None - so it shouldn't be shown in Service Details.

Gerrit topic: https://review.openstack.org/#q,topic:bp/dynamic-fields-on-service-details,n,z

Addressed by: https://review.openstack.org/87264
    Fix 'Name' field in Environment -> Services table

Addressed by: https://review.openstack.org/93341
    Refactor dynamic UI field parsing a bit

Addressed by: https://review.openstack.org/93342
    WIP

[tsufiev 2015/02/03] I have abandoned it was decided that this feature should be added once a more general mechanism for translation MuranoPL classes into Dynamic UI layout is developed.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.
Edit subscription

Subscribers

No subscribers.