[openstack-dev] [Quantum] Data constaraints are defined 3 times in Quantum / Quantum UI
Avishay Balderman
AvishayB at Radware.com
Wed Jan 23 08:49:58 UTC 2013
Hi
I think we violate the DRY principal quite heavily when we define the data constraints in 3 different locations.
Here is an example: (focusing on the 'type' field of 'HealthMonitor')
1- DB layer:
class HealthMonitor(model_base.BASEV2, models_v2.HasId, models_v2.HasTenant):
"""Represents a v2 quantum loadbalancer healthmonitor."""
type = sa.Column(sa.Enum("PING", "TCP", "HTTP", "HTTPS",
name="healthmontiors_type"),
nullable=False)
delay = sa.Column(sa.Integer, nullable=False)
timeout = sa.Column(sa.Integer, nullable=False)
max_retries = sa.Column(sa.Integer, nullable=False)
http_method = sa.Column(sa.String(16))
url_path = sa.Column(sa.String(255))
expected_codes = sa.Column(sa.String(64))
status = sa.Column(sa.String(16), nullable=False)
admin_state_up = sa.Column(sa.Boolean(), nullable=False)
2- API layer:
'health_monitors': {
'id': {'allow_post': False, 'allow_put': False,
'validate': {'type:uuid': None},
'is_visible': True},
'tenant_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:string': None},
'required_by_policy': True,
'is_visible': True},
'type': {'allow_post': True, 'allow_put': False,
'validate': {'type:values': ['PING', 'TCP', 'HTTP', 'HTTPS']},
'is_visible': True},
3- The UI layer:
In the UI the developer will probably will define this 'type' field as a combo box and will hard code the possible values (there is no other way since there is no {API | Config file} to get the constraints of an entity)
What can we do?
The idea is to be able to define the constraints once and consume those constraints in the layers mentioned above.
#option 1: define a "config" file that will contain the constraints in Quantum. The API layer and the DB layer will consume this configuration. The UI will have to get a copy of this file (since it a different project)
#option 2: define a "config" file that will contain the constraints in Quantum. The API layer and the DB layer will consume this configuration. The UI will consume it remotely through REST API.
#option 3: do nothing ... and keep duplication the constraints :(
It is obvious that option 2 is much "cleaner" but it requires extending the REST API.
Please let me know what do you think.
Thanks
Avishay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/f7300d24/attachment.html>
More information about the OpenStack-dev
mailing list