[Engine-devel] Using config values
by Kanagaraj
This is a multi-part message in MIME format.
--------------050008020702070900040001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi All,
The are some issues arising in configurations whenever we move up on the
versions(3.3 => 3.4), because of the way we store and interpret them.
Whenever there is a new cluster level, you will need to add a new entry
for all(most) of the configuration. Mostly a copy paste if you see from
3.2 to 3.3, except some CPU/PM type related configurations.
Better option would be to have the defaul config value in
ConfigValues.java and the overrides will go to config.sql. In this
approach you don't need a new entries to config.sql when there is a new
cluster level.
Lets take an exmaple, "SupportForceCreateVG" - This is supported from
3.1 onwards,
If you look at config.sql, you will see following entries
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
And in ConfigValues.java
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute("false")
SupportForceCreateVG,
Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which
i feel is redundant.
Instead we can make
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute("true")
SupportForceCreateVG,
and have only the following in config.sql
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
if a particular value(for a specific cluster level) is not found in
Config.sql, the fallback is to use the value available in ConfigValues.java.
Please share your thoughts on this.
Thanks,
Kanagaraj
--------------050008020702070900040001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi All,<br>
<br>
The are some issues arising in configurations whenever we move up on
the versions(3.3 => 3.4), because of the way we store and
interpret them.<br>
<br>
Whenever there is a new cluster level, you will need to add a new
entry for all(most) of the configuration. Mostly a copy paste if you
see from 3.2 to 3.3, except some CPU/PM type related configurations.<br>
Better option would be to have the defaul config value in
ConfigValues.java and the overrides will go to config.sql. In this
approach you don't need a new entries to config.sql when there is a
new cluster level.<br>
<br>
Lets take an exmaple, "SupportForceCreateVG" - This is supported
from 3.1 onwards,<br>
<br>
If you look at config.sql, you will see following entries <br>
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
<br>
select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
<br>
select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
<br>
select fn_db_add_config_value('SupportForceCreateVG','true','3.3');<br>
<br>
And in ConfigValues.java<br>
<br>
@TypeConverterAttribute(Boolean.class)<br>
@DefaultValueAttribute("false")<br>
SupportForceCreateVG,<br>
<br>
Now if there is 3.4 and 3.5, the user needs to add 2 more entries,
which i feel is redundant.<br>
<br>
Instead we can make <br>
<br>
@TypeConverterAttribute(Boolean.class)<br>
@DefaultValueAttribute("true")<br>
SupportForceCreateVG,<br>
<br>
and have only the following in config.sql<br>
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');<br>
<br>
if a particular value(for a specific cluster level) is not found in
Config.sql, the fallback is to use the value available in
ConfigValues.java.<br>
<br>
Please share your thoughts on this.<br>
<br>
Thanks,<br>
Kanagaraj<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</body>
</html>
--------------050008020702070900040001--
11 years
[Engine-devel] Adding users and assigning roles in Ovirt
by Ramesh
Hi All,
We have 'Add' action under 'Users' main tab to add users in Ovirt .
It looks slightly different from the "Add user" option of the Configure
option. Actually, this one is missing the "Role to Assign" option. I
think without assigning any role, adding a user is not meaningful and it
didn't complete the flow.
Currently to assign any role to the user, either we have to use
'Configure' option ( to add system permission) or we have to go to the
specific entity and add permission for that entity. It will be nice if
we can assign roles( system level permissions) while adding users in
'Users' tab itself. It will be a clear user flow where one can add user
and assign role in the same place.
I have attached both the screen shots.
please share your thoughts.
Regards,
Ramesh
11 years
[Engine-devel] Remove Comment column in main tabs
by Mike Kolesnik
------=_Part_40758794_854245147.1385448274314
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi,
When the comment RFE was added (in 3.3), there was also a column added to many main tabs.
I would like to propose to get rid of the column (which can only house one icon or no icon),
and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name.
In this case the icon should probably be scaled down a bit since its huge.
I think this would be a good alternative and save us some valued screen real estate.
Thoughts, opinions?
Regards,
Mike
------=_Part_40758794_854245147.1385448274314
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div>When the comment RFE was added (in 3.3), there was also a column added to many main tabs.<br></div><div><br></div><div>I would like to propose to get rid of the column (which can only house one icon or no icon),</div><div>and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name.<br></div><div><br></div><div>In this case the icon should probably be scaled down a bit since its huge.<br></div><div><br></div><div>I think this would be a good alternative and save us some valued screen real estate.<br></div><div><br></div><div>Thoughts, opinions?<br></div><div><br></div><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><div><br></div></div></body></html>
------=_Part_40758794_854245147.1385448274314--
11 years
