Re: [ovirt-devel] Unable to create ovirtmgmt network on node
Thanks Edy for the help. Could this related to some firewall issues or
something?
Any specific firewalld configuration required here?
Regards,
Shubhendu
- Original Message -
From: "Edward Haas" <eh...@redhat.com>
To: "Shubhendu Tripathi" <shtri...@redhat.com>
Cc: "engine-de...@ovirt.org" <devel@ovirt.org>
Sent: Wednesday, July 19, 2017 5:13:34 PM
Subject: Re: [ovirt-devel] Enable to create ovirtmgmt network on node
Hi,
Looks like you are not getting a response from the dhcp on VLAN 802 @em3
interface.
Thanks,
Edy.
On Wed, Jul 19, 2017 at 12:46 PM, Shubhendu Tripathi <shtri...@redhat.com>
wrote:
> While creating a cluster, on one of the nodes creation of ovirtmgmt fails
> and node is not in active state.
> Looking at supervdsm.log, below are few snippets of errors-
>
> ===
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,665::supervdsmServer::116::SuperVdsm.ServerCallback::(wrapper)
> call setupNetworks with ({'ovirtmgmt': {'ipv6autoconf': False, 'nic':
> 'em3', 'vlan': '802', 'mtu': 1500, 'switch': 'legacy', 'dhcpv6': False,
> 'bridged': 'false', 'defaultRoute': True, 'bootproto': 'dhcp'}}, {},
> {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {}
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,665::api::887::setupNetworks::(setupNetworks)
> Setting up network according to configuration: networks:{'ovirtmgmt':
> {'ipv6autoconf': False, 'nic': 'em3', 'vlan': '802', 'mtu': 1500, 'switch':
> 'legacy', 'dhcpv6': False, 'bridged': 'false', 'defaultRoute': True,
> 'bootproto': 'dhcp'}}, bondings:{}, options:{'connectivityCheck': 'true',
> 'connectivityTimeout': 120}
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,666::api::891::root::(setupNetworks) Validating configuration
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31 14:54:57,670::
> libvirtconnection::161::root::(get) trying to connect libvirt
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,690::netinfo::503::root::(_getNetInfo) Obtaining info for net
> ovirtmgmt.
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
> _getNetInfo
> data.update({'ports': ports(iface),
> File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in
> ports
> return os.listdir('/sys/class/net/' + bridge + '/brif')
> OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/
> brif'
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,708::api::901::setupNetworks::(setupNetworks)
> Applying...
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31 14:54:57,708::
> netconfpersistence::73::root::(setBonding) Adding bond0({'nics': [],
> 'options': 'mode=0'})
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,709::api::926::setupNetworks::(setupNetworks)
> Removing broken network 'ovirtmgmt'
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,717::netinfo::503::root::(_getNetInfo) Obtaining info for net
> ovirtmgmt.
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
> _getNetInfo
> data.update({'ports': ports(iface),
> File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in
> ports
> return os.listdir('/sys/class/net/' + bridge + '/brif')
> OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/
> brif'
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,726::api::463::root::(_delNetwork) Removing network ovirtmgmt
> with vlan=None, bonding=None, nics=[u'em3'],keep_bridge=False options={}
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,727::ifcfg::335::root::(_atomicNetworkBackup) Backed up ovirtmgmt
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,729::api::496::root::(_delNetwork) Removing network entity
> ovirtmgmt
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,729::models::188::root::(remove) Removing bridge
> Bridge(ovirtmgmt: Nic(em3))
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,729::utils::671::root::(execCmd) /usr/bin/taskset --cpu-list 0-5
> /usr/sbin/ifdown ovirtmgmt (cwd None)
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,760::utils::689::root::(execCmd) FAILED: = 'usage: ifdown
> \n'; = 1
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,760::__init__::144::root::(_removeSourceRoute) Removing source
> route for device ovirtmgmt
> MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
> 14:54:57,761::utils::140::root::(rmFile) File:
> /etc/sysconfig/network-scripts/rule-ovirtmgmt
> already removed
Re: [ovirt-devel] Unable to create ovirtmgmt network on node
Corrected the Subject line.
- Original Message -
From: "Shubhendu Tripathi" <shtri...@redhat.com>
To: "engine-de...@ovirt.org" <devel@ovirt.org>
Sent: Wednesday, July 19, 2017 3:16:07 PM
Subject: Enable to create ovirtmgmt network on node
While creating a cluster, on one of the nodes creation of ovirtmgmt fails and
node is not in active state.
Looking at supervdsm.log, below are few snippets of errors-
===
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,665::supervdsmServer::116::SuperVdsm.ServerCallback::(wrapper) call
setupNetworks with ({'ovirtmgmt': {'ipv6autoconf': False, 'nic': 'em3', 'vlan':
'802', 'mtu': 1500, 'switch': 'legacy', 'dhcpv6': False, 'bridged': 'false',
'defaultRoute': True, 'bootproto': 'dhcp'}}, {}, {'connectivityCheck': 'true',
'connectivityTimeout': 120}) {}
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,665::api::887::setupNetworks::(setupNetworks) Setting up network
according to configuration: networks:{'ovirtmgmt': {'ipv6autoconf': False,
'nic': 'em3', 'vlan': '802', 'mtu': 1500, 'switch': 'legacy', 'dhcpv6': False,
'bridged': 'false', 'defaultRoute': True, 'bootproto': 'dhcp'}}, bondings:{},
options:{'connectivityCheck': 'true', 'connectivityTimeout': 120}
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,666::api::891::root::(setupNetworks) Validating configuration
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,670::libvirtconnection::161::root::(get) trying to connect libvirt
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,690::netinfo::503::root::(_getNetInfo) Obtaining info for net
ovirtmgmt.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
_getNetInfo
data.update({'ports': ports(iface),
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in ports
return os.listdir('/sys/class/net/' + bridge + '/brif')
OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/brif'
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,708::api::901::setupNetworks::(setupNetworks) Applying...
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,708::netconfpersistence::73::root::(setBonding) Adding bond0({'nics':
[], 'options': 'mode=0'})
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,709::api::926::setupNetworks::(setupNetworks) Removing broken network
'ovirtmgmt'
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,717::netinfo::503::root::(_getNetInfo) Obtaining info for net
ovirtmgmt.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
_getNetInfo
data.update({'ports': ports(iface),
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in ports
return os.listdir('/sys/class/net/' + bridge + '/brif')
OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/brif'
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,726::api::463::root::(_delNetwork) Removing network ovirtmgmt with
vlan=None, bonding=None, nics=[u'em3'],keep_bridge=False options={}
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,727::ifcfg::335::root::(_atomicNetworkBackup) Backed up ovirtmgmt
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,729::api::496::root::(_delNetwork) Removing network entity ovirtmgmt
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,729::models::188::root::(remove) Removing bridge Bridge(ovirtmgmt:
Nic(em3))
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,729::utils::671::root::(execCmd) /usr/bin/taskset --cpu-list 0-5
/usr/sbin/ifdown ovirtmgmt (cwd None)
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,760::utils::689::root::(execCmd) FAILED: = 'usage: ifdown
\n'; = 1
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,760::__init__::144::root::(_removeSourceRoute) Removing source route
for device ovirtmgmt
MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
14:54:57,761::utils::140::root::(rmFile) File:
/etc/sysconfig/network-scripts/rule-ovirtmgmt already removed
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,761::ifcfg::292::root::(_removeFile) Removed file
/etc/sysconfig/network-scripts/rule-ovirtmgmt
MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
14:54:57,761::utils::140::root::(rmFile) File:
/etc/sysconfig/network-scripts/route-ovirtmgmt already removed
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,762::ifcfg::292::root::(_removeFile) Removed file
/etc/sysconfig/network-scripts/route-ovirtmgmt
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,762::utils::671::root::(execCmd) /usr/bin/taskset --cpu-list 0-5
/usr/sbin/brctl delbr ovirtmgmt (cwd None)
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,769::utils::689::root::(execCmd) FAILED: = "bridge ovir
[ovirt-devel] Enable to create ovirtmgmt network on node
While creating a cluster, on one of the nodes creation of ovirtmgmt fails and
node is not in active state.
Looking at supervdsm.log, below are few snippets of errors-
===
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,665::supervdsmServer::116::SuperVdsm.ServerCallback::(wrapper) call
setupNetworks with ({'ovirtmgmt': {'ipv6autoconf': False, 'nic': 'em3', 'vlan':
'802', 'mtu': 1500, 'switch': 'legacy', 'dhcpv6': False, 'bridged': 'false',
'defaultRoute': True, 'bootproto': 'dhcp'}}, {}, {'connectivityCheck': 'true',
'connectivityTimeout': 120}) {}
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,665::api::887::setupNetworks::(setupNetworks) Setting up network
according to configuration: networks:{'ovirtmgmt': {'ipv6autoconf': False,
'nic': 'em3', 'vlan': '802', 'mtu': 1500, 'switch': 'legacy', 'dhcpv6': False,
'bridged': 'false', 'defaultRoute': True, 'bootproto': 'dhcp'}}, bondings:{},
options:{'connectivityCheck': 'true', 'connectivityTimeout': 120}
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,666::api::891::root::(setupNetworks) Validating configuration
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,670::libvirtconnection::161::root::(get) trying to connect libvirt
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,690::netinfo::503::root::(_getNetInfo) Obtaining info for net
ovirtmgmt.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
_getNetInfo
data.update({'ports': ports(iface),
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in ports
return os.listdir('/sys/class/net/' + bridge + '/brif')
OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/brif'
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,708::api::901::setupNetworks::(setupNetworks) Applying...
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,708::netconfpersistence::73::root::(setBonding) Adding bond0({'nics':
[], 'options': 'mode=0'})
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,709::api::926::setupNetworks::(setupNetworks) Removing broken network
'ovirtmgmt'
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,717::netinfo::503::root::(_getNetInfo) Obtaining info for net
ovirtmgmt.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
_getNetInfo
data.update({'ports': ports(iface),
File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in ports
return os.listdir('/sys/class/net/' + bridge + '/brif')
OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/brif'
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,726::api::463::root::(_delNetwork) Removing network ovirtmgmt with
vlan=None, bonding=None, nics=[u'em3'],keep_bridge=False options={}
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,727::ifcfg::335::root::(_atomicNetworkBackup) Backed up ovirtmgmt
MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
14:54:57,729::api::496::root::(_delNetwork) Removing network entity ovirtmgmt
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,729::models::188::root::(remove) Removing bridge Bridge(ovirtmgmt:
Nic(em3))
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,729::utils::671::root::(execCmd) /usr/bin/taskset --cpu-list 0-5
/usr/sbin/ifdown ovirtmgmt (cwd None)
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,760::utils::689::root::(execCmd) FAILED: = 'usage: ifdown
\n'; = 1
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,760::__init__::144::root::(_removeSourceRoute) Removing source route
for device ovirtmgmt
MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
14:54:57,761::utils::140::root::(rmFile) File:
/etc/sysconfig/network-scripts/rule-ovirtmgmt already removed
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,761::ifcfg::292::root::(_removeFile) Removed file
/etc/sysconfig/network-scripts/rule-ovirtmgmt
MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
14:54:57,761::utils::140::root::(rmFile) File:
/etc/sysconfig/network-scripts/route-ovirtmgmt already removed
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,762::ifcfg::292::root::(_removeFile) Removed file
/etc/sysconfig/network-scripts/route-ovirtmgmt
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,762::utils::671::root::(execCmd) /usr/bin/taskset --cpu-list 0-5
/usr/sbin/brctl delbr ovirtmgmt (cwd None)
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,769::utils::689::root::(execCmd) FAILED: = "bridge ovirtmgmt
doesn't exist; can't delete it\n"; = 1
MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
14:54:57,770::utils::140::root::(rmFile) File:
/etc/sysconfig/network-scripts/ifcfg-ovirtmgmt already removed
MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
14:54:57,770::ifcfg::292::root::(_removeFile) Removed file
Re: [ovirt-devel] Fedora 22
I had to do this at least for fedora 21. Worst part is Firefox as we cannot use anything greater than 25 for gwt debugging. Sent from Samsung Mobile Original message From: Greg Sheremeta gsher...@redhat.com Date:01/06/2015 20:15 (GMT+05:30) To: devel@ovirt.org Subject: [ovirt-devel] Fedora 22 Anyone upgrade to F22 yet? Looking for tips on running engine after I upgrade. I assume I'll still have to install JDK 1.7 and JBoss 7. Thanks. Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gsher...@redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [oVirt 3.6 Localization Question #10] Gluster snapshot info failed
The error
ACTION_TYPE_FAILED_REMOVE_BRICK_FROM_DISTRIBUTED_DISPERSE_VOLUME_NOT_SUPPORTED
is not mapped to string Gluster snapshot info failed.
Its actually mapped to a string Cannot ${action} ${type}. Removal of
bricks from distributed disperse volume is not supported.. You can
verify the same in AppErrors.properties.
This is used to error out if removal of bricks tried from distributed
disperse volume.
Regards,
Shubhendu
On 05/13/2015 02:16 PM, Yuko Katabami wrote:
Hello all,
I would like to ask for your help in the following question.
*
File:***VdsmErrors
*Resource
ID:***ACTION_TYPE_FAILED_REMOVE_BRICK_FROM_DISTRIBUTED_DISPERSE_VOLUME_NOT_SUPPORTED
*String:*** Gluster snapshot info failed
*Question:* Could anyone please explain if this means Failed to
*fetch* Gluster snapshot info or Failed to *verify* Gluster snapshot
info or failed in some other action?
Kind regards,
Yuko
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [oVirt 3.6 Localization Question #8] VAR__ACTION__VOLUME_SNAPSHOT_CONFIG_UPDATE
Hope this is resolved as Einav already sent a patch for the same.
Thanks Einav for the patch [1]. Copy paste errors :(
Regards,
Shubhendu
[1] https://gerrit.ovirt.org/#/c/40887/
On 05/13/2015 08:31 PM, Einav Cohen wrote:
@Shubhendu(/others) - can you please assist with the $type-related question?
@Yuko: as for the double-quotation marks - these indeed are not needed.
same for the following string (in the same file):
Resrouce ID: VALIDATION_DATA_CENTER_DESCRIPTION_INVALID
String: Data Center description must be formed of ASCII charis only
please instruct the translators to ignore the double-quotation marks,
i.e., to not include the double-quotation marks in their translations
for those two strings.
I will make sure that the source (English) strings are fixed.
Thanks,
Einav
- Original Message -
From: Yuko Katabami ykata...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, May 13, 2015 3:43:44 AM
Subject: Re: [ovirt-devel] [oVirt 3.6 Localization Question #8]
VAR__ACTION__VOLUME_SNAPSHOT_CONFIG_UPDATE
Hi all,
I am reposting this question.
Could anyone able to answer it?
Kind regards,
Yuko
On 05/11/2015 10:08 PM, Yuko Katabami wrote:
Hello again and sorry for increasing email traffic.
Here is another question I would like to ask:
File: AppErrors
Resource ID: VAR__ACTION__VOLUME_SNAPSHOT_CONFIG_UPDATE
String: $action gluster volume snapshot config update
Question: Does this string need to be enclosed in double quotation marks,
unlike other $action?
What $type is this likely to be combined with? (in Cannot ${action}
${type}.) It is a bit tricky to make translation to work when this is used
as a variable, so I would like to check the usage examples.
Kind regards,
Yuko
___
Devel mailing list Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [oVirt 3.6 Localization Question #8] VAR__ACTION__VOLUME_SNAPSHOT_CONFIG_UPDATE
Sorry Yuko,
I overlooked.
The value of $type here in this case would be replaced with Gluster
Volume Snapshot.
Regards,
Shubhendu
On 05/14/2015 09:41 AM, Yuko Katabami wrote:
Hi Shubhendu,
Thank you very much for that.
Actually a part of my question is still not answered yet, which is:
What $type is this likely to be combined with? (in Cannot ${action}
${type}.) It is a bit tricky to make translation to work when this is
used
as a variable, so I would like to check the usage examples.
Could you please provide me an example?
Kind regards,
Yuko
On 05/14/2015 02:07 PM, Shubhendu Tripathi wrote:
Hope this is resolved as Einav already sent a patch for the same.
Thanks Einav for the patch [1]. Copy paste errors :(
Regards,
Shubhendu
[1] https://gerrit.ovirt.org/#/c/40887/
On 05/13/2015 08:31 PM, Einav Cohen wrote:
@Shubhendu(/others) - can you please assist with the $type-related
question?
@Yuko: as for the double-quotation marks - these indeed are not needed.
same for the following string (in the same file):
Resrouce ID: VALIDATION_DATA_CENTER_DESCRIPTION_INVALID
String: Data Center description must be formed of ASCII charis only
please instruct the translators to ignore the double-quotation marks,
i.e., to not include the double-quotation marks in their translations
for those two strings.
I will make sure that the source (English) strings are fixed.
Thanks,
Einav
- Original Message -
From: Yuko Katabami ykata...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, May 13, 2015 3:43:44 AM
Subject: Re: [ovirt-devel] [oVirt 3.6 Localization Question #8]
VAR__ACTION__VOLUME_SNAPSHOT_CONFIG_UPDATE
Hi all,
I am reposting this question.
Could anyone able to answer it?
Kind regards,
Yuko
On 05/11/2015 10:08 PM, Yuko Katabami wrote:
Hello again and sorry for increasing email traffic.
Here is another question I would like to ask:
File: AppErrors
Resource ID: VAR__ACTION__VOLUME_SNAPSHOT_CONFIG_UPDATE
String: $action gluster volume snapshot config update
Question: Does this string need to be enclosed in double quotation
marks,
unlike other $action?
What $type is this likely to be combined with? (in Cannot ${action}
${type}.) It is a bit tricky to make translation to work when this
is used
as a variable, so I would like to check the usage examples.
Kind regards,
Yuko
___
Devel mailing list Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [oVirt 3.6 Localization Question #9] distributed disperse volume vs disperse volume
Disperse volume is nothing but erasure encoded volume which is another
way to achieve replication of data with lesser space utilization.
Refer URL:
http://www.gluster.org/community/documentation/index.php/Features/disperse
for more details.
On 05/12/2015 03:54 PM, Yuko Katabami wrote:
Hi all,
Could anyone help me with the following question?
*File:***AppErrors
*Resource
ID:***ACTION_TYPE_FAILED_REMOVE_BRICK_FROM_DISTRIBUTED_DISPERSE_VOLUME_NOT_SUPPORTED
*String:***Cannot ${action} ${type}. Removal of bricks from
distributed disperse volume is not supported.
*Question:* Sorry to ask you a basic question but could anyone explain
the difference between distributed disperse volume and disperse
volume? These words are synonymous and a bit difficult to
differentiate in my language. I would like to have some extra
information/context in order to translate them accurately.
Thank you,
Yuko
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Proposing Sahina Bose as oVirt core maintainer
+1 Sent from Samsung Mobile Original message From: Oved Ourfali ov...@redhat.com Date: 01/03/2015 17:27 (GMT+05:30) To: engine-de...@ovirt.org devel@ovirt.org Subject: [ovirt-devel] Proposing Sahina Bose as oVirt core maintainer Hi all! I would like to propose Sahina Bose as an engine-core maintainer, with regards to Gluster related code. Sahina joined the oVirt project two years ago, and has since contributed over 150 patches, and has been instrumental in reviews of all Gluster patches. Will appreciate your response! Thanks, Oved ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 01/01/2015 10:36 PM, Einav Cohen wrote: - Original Message - From: Shubhendu Tripathi shtri...@redhat.com Sent: Thursday, January 1, 2015 10:05:48 AM On 12/31/2014 11:42 PM, Einav Cohen wrote: Thanks, Shubhendu. Additional comments: ... Yes, attempt to create second snapshot schedule is actually an override option. Of course spot creation is allowed in addition to the scheduled. ... ... If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. ... From your latest responses, I conclude the following. via the New dialog, you can: (1) create a one-time snapshot (2) create a new snapshot schedule (3) override (and practically, edit) an existing snapshot schedule via the Schedule dialog, you can: (a) create a one-time snapshot (by selecting the 'None' recurrence) (b) create a new snapshot schedule (by selecting something other than 'None' in the recurrence field, given that no schedule exists yet) (c) edit an existing snapshot schedule (which is what this dialog is actually meant to do). I am not sure about (a), but it doesn't matter much for my point: New and Schedule have the exact same functionality. To be more accurate: New contains all of the needed functionality; Schedule is not really needed. The only thing that New is potentially missing is showing the values of the already-existing snapshot schedule, if one exists. I think that this may confuse to the user; I recommend to either unite both of these actions/dialogs to a single action/dialog, or separate completely some functionalists. So my recommendation is to do one of the following: (a) unite: Have a single action (Create / Schedule) which will display a dialog very similar to the New dialog, with the option to see the values of the already-existing snapshot schedule, if one exists. In this case, I would actually recommend to go with something more similar to option 2 in http://i.imgur.com/4j7hvRY.png, rather than option 3 (so the separation between *creating new* *one-time* snapshot and *editing an existing* *scheduled* snapshot is clearer). see http://i.imgur.com/ZgCp9Tz.png for an updated suggestion. - or - (b) separate: Have two completely separate actions: Create Now and Schedule. - The Create Now dialog will look like the 'General' side-section of the New dialog (i.e. without the Schedule side-section; it will allow only one-time immediate snapshot creation. - The Schedule dialog will look like the New dialog (with both 'General' and 'Schedule' side-sections) without the None recurrence, and will allow only creating a new recurring snapshot schedule (if one doesn't exist yet) or editing the existing schedule (in this case, the dialog would be pre-populated with the values of the existing schedule). I am more in favor of (b) - it seems simpler and more user-friendly in my view. Option (b) is something which we had started with, then at later stage it was discussed that scheduling as well should be in the flow of creation of snapshot so merged with New Snapshot option. After this as we need Edit option for snapshot schedule, so introduced Schedule option. But still, as you suggest I feel option (b) is no doubt a clearer and user friendly way. Alok, need a point of view from PMs on this. Thanks, Shubhendu. @Alok (and all): the main pain-point in the current design that I am trying to address is the fact that in the 'New' dialog, you have the option to create a one- time snapshot, and within the same dialog, with a very small (too small IMO) change, you have the option to edit (override) an already-existing schedule, without even realizing necessarily that you are editing something (since you are in a 'New' dialog) and without seeing the values of the object that you are editing. From a UX perspective, this may be confusing and misleading. if it is imperative to combine the one-time creation functionality with the scheduling functionality, you have option (a). here is another option (c) that will allow you to create a one-time snapshot and *create* a new schedule in the same dialog. it is also probably the closest option to the original design in the wiki, so I encourage you to consider it: (c) Have two options, New and Schedule, like today. - New will be *only* for creating new objects, not editing/overriding existing ones. It will look very
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Thanks Einav for the detailed review and your comments. Find below the comment inline. Will update the wiki accordingly and circulate. Team, please provide your thoughts (if conflicting) on this. Thanks and Regards, Shubhendu On 12/30/2014 05:33 AM, Einav Cohen wrote: Hi Shubhendu, First of all - very detailed wiki pages (I focused mainly on the User Experience part) - nicely done. I have a couple of comments / suggestions regarding the GUI: Snapshot action-group: - from the wiki page: A new action-group Snapshot would be introduced under actions for a volume. I assume that you will implement it similarly to the Power Management action-group (on Hosts main tab) or the Profiling action-group (on the Volumes tab), i.e. with a drop-down-like styling [http://i.imgur.com/eWRg6o8.png]? Yes. That's correct. - If the Snapshot-related actions are expected to be core/critical in the Volumes-related workflows, it makes sense to put them in the main- tab, but please consider adding them to the Snapshots sub-tab as well, in order to be consistent with other similar oVirt workflows. Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. New Snapshot dialog - Schedule section: - I suggest to implement the time-interval selection with a drop-down, rather than a radio-button group; it is more consistent with e.g. event-repeat scheduling in a calendar [http://i.imgur.com/y9Gn3wq.png], it will save real-estate within the dialog and it will be more easily readable for the user. That's a good suggestion. Will do this. - to my understanding, the New Snapshot functionality doesn't have to be recurrent; however, there isn't any way to disable the recurring aspect. Here are some suggestions to how this should be added: http://i.imgur.com/4j7hvRY.png Once scheduled the only way to stop snapshot creation is to provide an end date. Option 3 is my personal favorite - it is the simplest, and is consistent with Calendear-scheduling UI. Option 1 is my least favorite, however it is consistent with e.g. the Enable Power Management UI within the New Host dialog. Option-3 looks good to me as well. Should be doable I feel. Snapshots - Options: - I think that there are a couple of problematic issues with this dialog: * the different functionality of this dialog when a Volume is selected vs. when no Volume is selected may be unclear to the user. Agree * the fact that we can update Cluster-related parameters (which potentially affects *all* volumes in that Cluster) within a specific Volume-context dialog is a bit risky - and we don't have anything similar to that anywhere in the application today IIRC. my recommendations: * have separate Options - Cluster and Options - Volume actions; Options - Cluster should always be enabled. Options - Volume should be enabled only when a Volume is selected. Accept * Seehttp://i.imgur.com/pfRpjrH.png for my suggestion for Cluster Options vs. Volume Options. Note that from the Volume Options dialog, you may allow editing the Cluster Options by clicking on the link-button, which will either (a) open the Cluster Options dialog on top or (b) allow editing the Cluster Values inline within the already-open dialog - this should be accompanied with a clear note to the user that he is editing Cluster-related parameters from the current (Volume) context, which may affect *all* Volumes in that Cluster. Also note that in my suggestion, the user can conveniently see both the Volume values and the Cluster Values side-by-side at once, for reference. Accept Snapshots - Schedule: - to my understanding, this should be very similar (or identical) to the New Snapshot functionality? if so, we may want to simply open the New Snapshot dialog focused on the Schedule side-section (rather than the 'General' side-section, maybe already pre-populated with some values in the 'General' side-section (which will still be editable by the user) and something already pre-selected in the (focused) Schedule section. please let me know whether you think these can/should be incorporated into the design, and/or if you have any comments or questions. Accept. The snapshot create dialog itself can be used here. thanks. Regards, Einav - Original Message - From: Shubhendu Tripathishtri...@redhat.com To:de...@linode01.ovirt.org,jhern...@redhat.com, Michael Pasternakmpast...@redhat.com Sent: Monday, November 10, 2014 1:52:40 AM Subject: [ovirt-devel] Gluster Volume Snapshots - Feature review Hi All, Please help us to review the design of Gluster Volume Snapshots in oVirt, Here are two design on wiki page General Feature Design http://www.ovirt.org/Features/GlusterVolumeSnapshots Detailed Design http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots We target it in ovirt 3.6 release. Marked Juan/Michael specifically for REST review. Best Regards, Shubhendu Tripathi
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
will be pre-populated with the most common/reasonable recurrence schedule, in case the user will not touch it. BTW, if this is indeed the case, then there is probably no need for both 'New' and 'Schedule' buttons - only 'Schedule' is sufficient. Accept. The snapshot create dialog itself can be used here. Just need to make sure to change its title accordingly (to 'Schedule Snapshot' or something similar; right now it says New Snapshot in the wiki). I assume that this dialog can be used for: (a) creating a New snapshot schedule (which should look very similar to the 'New Snapshot' dialog, maybe with some pre-populated values, maybe without the 'None' option in the Recurrence drop-down). If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. - and/or - (b) editing the already-existing schedule (in this case, fields that cannot be edited should be disabled). As above. I hope I was clear - please let me know if you have any questions or comments. Thanks again! Regards, Einav - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Tuesday, December 30, 2014 7:09:51 AM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review Thanks Einav for the detailed review and your comments. Find below the comment inline. Will update the wiki accordingly and circulate. Team, please provide your thoughts (if conflicting) on this. Thanks and Regards, Shubhendu On 12/30/2014 05:33 AM, Einav Cohen wrote: Hi Shubhendu, First of all - very detailed wiki pages (I focused mainly on the User Experience part) - nicely done. I have a couple of comments / suggestions regarding the GUI: Snapshot action-group: - from the wiki page: A new action-group Snapshot would be introduced under actions for a volume. I assume that you will implement it similarly to the Power Management action-group (on Hosts main tab) or the Profiling action-group (on the Volumes tab), i.e. with a drop-down-like styling [http://i.imgur.com/eWRg6o8.png]? Yes. That's correct. - If the Snapshot-related actions are expected to be core/critical in the Volumes-related workflows, it makes sense to put them in the main- tab, but please consider adding them to the Snapshots sub-tab as well, in order to be consistent with other similar oVirt workflows. Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. New Snapshot dialog - Schedule section: - I suggest to implement the time-interval selection with a drop-down, rather than a radio-button group; it is more consistent with e.g. event-repeat scheduling in a calendar [http://i.imgur.com/y9Gn3wq.png], it will save real-estate within the dialog and it will be more easily readable for the user. That's a good suggestion. Will do this. - to my understanding, the New Snapshot functionality doesn't have to be recurrent; however, there isn't any way to disable the recurring aspect. Here are some suggestions to how this should be added: http://i.imgur.com/4j7hvRY.png Once scheduled the only way to stop snapshot creation is to provide an end date. Option 3 is my personal favorite - it is the simplest, and is consistent with Calendear-scheduling UI. Option 1 is my least favorite, however it is consistent with e.g. the Enable Power Management UI within the New Host dialog. Option-3 looks good to me as well. Should be doable I feel. Snapshots - Options: - I think that there are a couple of problematic issues with this dialog: * the different functionality of this dialog when a Volume is selected vs. when no Volume is selected may be unclear to the user. Agree * the fact that we can update Cluster-related parameters (which potentially affects *all* volumes in that Cluster) within a specific Volume-context dialog is a bit risky - and we don't have anything similar to that anywhere in the application today IIRC. my recommendations: * have separate Options - Cluster and Options - Volume actions; Options - Cluster should always be enabled. Options - Volume should be enabled only when a Volume is selected. Accept * Seehttp://i.imgur.com/pfRpjrH.png for my suggestion for Cluster Options vs
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Small typo error corrected. On 12/31/2014 11:26 AM, Shubhendu Tripathi wrote: Hi Einav, Find the comments inline. Thanks and Regards, Shubhendu On 12/30/2014 11:13 PM, Einav Cohen wrote: Thank you, Shubhendu! I have a few more comments: Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. I think that if a user already got to the Snapshots sub-tab of a specific Volume, it would seem strange that not all Snapshots-related actions for that Volume are available from there - but I will leave it to your discretion; I think that New is indeed the most important one to have also in the sub-tab. We may have the New option available under sub tab as well. Setting configuration options would only be available in Volumes main tab. Once scheduled the only way to stop snapshot creation is to provide an end date. let me try and understand what are the exact snapshot creation capabilities. consider the following use-cases (which may make absolutely no sense, just giving these as examples in order to understand the capabilities): (1) let's say that I want to do two recurring snapshots schedules in parallel for a single volume: one Monthly, and another one Weekly. Can I do that? We can have only one schedule for a volume at a time. I am assuming that I can't, i.e. there can only be one recurring-snapshot- creation schedule per volume (which you create via New and edit via Schedule) - is that correct? If so: are you blocking an attempt to create a New recurring snapshot schedule when one already exists for this Volume (e.g. disable the New button, fail a CanDoAction with a message such as Cannot create snapshot scheduling. A snapshot scheduling already exists for this Volume, etc.) or allowing override of the already- existing schedule (with a proper warning)? Even if a volume snapshot creation is scheduled user can still opt for onetime spot snapshot creation and New would be available. If my assumption is wrong, and I can have two (or more) recurring- snapshot-creation schedules per volume: how do I *edit* these schedules? what happens when I click on Schedule? which one of the two schedules will I edit? The Weekly one? The Monthly one? As there is only one schedule for a volume at a time, so this is not valid scenario. Exiting single instance of schedule can be edited using the option Volumes - Snapshots - Schedule. May be if you suggest this option can be renamed to Edit Schedule. If I am comparing the terminology to the one of Calendar meeting schedule (see http://i.imgur.com/xvf5w30.png): I don't have any series objects that I can 'edit', I can see only instances, and I can edit only one global 'series' object via the Schedule button. [again: if there can only be one recurring-snapshot-creation schedule per volume, then the current design is OK, assuming the attempt to create a second snapshot-schedule for a volume is properly blocked/overridden/...] Yes, attempt to create second snapshot schedule is actually an override option. Of course spot creation is allowed in addition to the scheduled. (2) let's say that I want to do a weekly recurring snapshot scheduling for a certain volume. In addition to that weekly recurring snapshots, I want to take a one-time snapshot of this volume right now. Can I do that? Yes, as discussed above stop one time creation in addition to the scheduled is allowed. %s/stop/spot/g If so: then my suggestion [http://i.imgur.com/4j7hvRY.png, option 3] is indeed valid; I am assuming that the user can create, per volume: one recurring snapshot schedule + unlimited one-time snapshots. Yes. That's correct. [If the user can create two (or more) recurring snapshot schedules - see (1) above]. need to make sure that the user is able to create a New snapshot with the Weekly recurrence schedule, and then another New snapshot(s) with the None recurrence schedule, which will create the one-time snapshot(s) immediately, and that the schedule of the Weekly snapshot can be edited via the Schedule option. So it goes like this. Say a Weekly snapshot is scheduled for certain volume and later user wants to create single on-spot snapshot. For this he/she need to select the option Volumes - Snapshots - New and not Volumes - Snapshots - Schedule. By default the option None is selected as Recurrence type and it creates a one time snapshot. Still the schedule stands valid in the system and if the user wants to edit the schedule he/she need to select the option Volumes - Snapshots - Schedule. Hope this clarifies. If not (i.e. the user can create only one recurring snapshot schedule, and that's it - no additional recurring snapshot schedules, no one-time immediate snapshots, etc.), then my suggestion is invalid, and a 'None' recurrence is not needed. As said above, one time snapshot creation is still allowed in addition to the scheduled. (Using Volumes
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Hi Juan,
Incorporated the comments in the wiki.
Kindly do have a look.
Thanks and Regards,
Shubhendu
On 12/18/2014 06:38 PM, Shubhendu Tripathi wrote:
Hi Juan,
Thanks for the detailed comments.
My comments inline.
Thanks and Regards,
Shubhendu
On 12/11/2014 08:56 PM, Juan Hernández wrote:
On 12/11/2014 05:36 AM, Shubhendu Tripathi wrote:
Hi Juan,
Incorporated the review comments.
Kindly have a look and let us know if everything looks well and good.
Thanks and Regards,
Shubhendu
Thanks for making the changes. I have some additional comments:
1. URL segments shouldn't have underscores. For example, you are
proposing URLs like this:
/clusters/{cluster:id}/glustervolumes/{volume:id}/volume_snapshots
The last component should be volumesnapshots, without the underscore.
Note that on the other hand XML element should have underscores, like in
volume_snapshots, that is correct.
Sure. Will do the changes accordingly.
2. Try to avoid abbreviations. For example, instead of whatever_params
use whatever_parameters, and instead of scheduling_det use
scheduling_details, use cron_expression instead of cronexpr, so
on.
Sure. Will do the changes accordingly.
3. If possible the action to delete a snapshot shouldn't receive any
parameters, not even an empty action/ element.
Sure. Will do the changes accordingly.
4. The schedulesnapshot action should be modeled using REST style, not
an action. My understanding is that you plan to have for each volume a
set of rules that define when the snapshots will be created. This should
be implemented as a sub-collection of the volume, so that these rules
can be queried, added, modified and deleted:
To query:
GET ...{volume:id}/snapshotrules
snapshot_rules
snapshot_rule id=... href=...
crontab_expression.../crontab_expression
/snapshot_rule
...
/snapshot_rules
To add:
POST ...{volume:id{/snapshotrules
snapshot_rule
crontab_expression.../crontab_expression
/snapshot_rule
To modify:
PUT ...{volume:id}/snapshotrules/{snapshotrule:id}
snapshot_rule
crontab_expression.../crontab_expression
/snapshot_rule
To delete (note that there is no body):
DELETE ...{volume:id}/snapshotrules/{snapshotrule:id}
If there will be only one of these rules per volume then you can model
them as attributes of the volume itself, without the sub-collection.
At a time there would be only one rule for a volume, so as suggested
it could be a volume attribute. Will model accordingly.
5. The snapshotconfigs should be modeled as an attribute of the
volume, not as an action.
As above.
On 12/09/2014 07:23 PM, Shubhendu Tripathi wrote:
Thanks Juan for the comments. I would update the wiki accordingly
and send for confirmation.
Regards
Shubhendu
Sent from Samsung Mobile
Original message
From: Juan Hernández jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi
shtri...@redhat.com,devel@ovirt.org,Michael Pasternak
mpast...@redhat.com
Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
Hi Juan/Michael,
This is a gentle reminder for the review of the REST api design
for the
below feature.
We would be starting the REST development for the same soon
(probably by
Dec 2014 end).
If there are specific comments, please pass it on. If no comments we
would go ahead with the current design and implement accordingly.
Request your time for this.
Thanks and Regards,
Shubhendu
On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
Hi All,
Please help us to review the design of Gluster Volume Snapshots
in oVirt,
Here are two design on wiki page
General Feature Design
http://www.ovirt.org/Features/GlusterVolumeSnapshots
Detailed Design
http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
We target it in ovirt 3.6 release.
Marked Juan/Michael specifically for REST review.
Best Regards,
Shubhendu Tripathi
My comments about the RESTAPI:
1. You can't use the snapshot and snapshots XML elements, as those
are already in use for disk snapshots, and we don't have name space
support in the RESTAPI. You will have to use something different, for
example gluster_volume_snapshots and gluster_volume_snapshot.
2. When adding a volume snapshot the name of the volume shouldn't be a
parameter, as that is implicit. Only the name and description of the
snapshot should be provided.
3. The operation to delete a snapshot should be performed on the
snapshot resource, not on the collection:
DELETE
/clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
Ideally this operation shouldn't receive any parameters (thus no
body).
If it does require parameters then they should be contained inside an
action element.
4. The operation to update the snapshot configuration should be the
PUT
operation of the volume, not a new snapshotconfig sub-resource, as
these kind of sub
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Hi Juan,
Thanks for the detailed comments.
My comments inline.
Thanks and Regards,
Shubhendu
On 12/11/2014 08:56 PM, Juan Hernández wrote:
On 12/11/2014 05:36 AM, Shubhendu Tripathi wrote:
Hi Juan,
Incorporated the review comments.
Kindly have a look and let us know if everything looks well and good.
Thanks and Regards,
Shubhendu
Thanks for making the changes. I have some additional comments:
1. URL segments shouldn't have underscores. For example, you are
proposing URLs like this:
/clusters/{cluster:id}/glustervolumes/{volume:id}/volume_snapshots
The last component should be volumesnapshots, without the underscore.
Note that on the other hand XML element should have underscores, like in
volume_snapshots, that is correct.
Sure. Will do the changes accordingly.
2. Try to avoid abbreviations. For example, instead of whatever_params
use whatever_parameters, and instead of scheduling_det use
scheduling_details, use cron_expression instead of cronexpr, so on.
Sure. Will do the changes accordingly.
3. If possible the action to delete a snapshot shouldn't receive any
parameters, not even an empty action/ element.
Sure. Will do the changes accordingly.
4. The schedulesnapshot action should be modeled using REST style, not
an action. My understanding is that you plan to have for each volume a
set of rules that define when the snapshots will be created. This should
be implemented as a sub-collection of the volume, so that these rules
can be queried, added, modified and deleted:
To query:
GET ...{volume:id}/snapshotrules
snapshot_rules
snapshot_rule id=... href=...
crontab_expression.../crontab_expression
/snapshot_rule
...
/snapshot_rules
To add:
POST ...{volume:id{/snapshotrules
snapshot_rule
crontab_expression.../crontab_expression
/snapshot_rule
To modify:
PUT ...{volume:id}/snapshotrules/{snapshotrule:id}
snapshot_rule
crontab_expression.../crontab_expression
/snapshot_rule
To delete (note that there is no body):
DELETE ...{volume:id}/snapshotrules/{snapshotrule:id}
If there will be only one of these rules per volume then you can model
them as attributes of the volume itself, without the sub-collection.
At a time there would be only one rule for a volume, so as suggested it
could be a volume attribute. Will model accordingly.
5. The snapshotconfigs should be modeled as an attribute of the
volume, not as an action.
As above.
On 12/09/2014 07:23 PM, Shubhendu Tripathi wrote:
Thanks Juan for the comments. I would update the wiki accordingly and send for
confirmation.
Regards
Shubhendu
Sent from Samsung Mobile
Original message
From: Juan Hernández jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi shtri...@redhat.com,devel@ovirt.org,Michael Pasternak
mpast...@redhat.com
Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
Hi Juan/Michael,
This is a gentle reminder for the review of the REST api design for the
below feature.
We would be starting the REST development for the same soon (probably by
Dec 2014 end).
If there are specific comments, please pass it on. If no comments we
would go ahead with the current design and implement accordingly.
Request your time for this.
Thanks and Regards,
Shubhendu
On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
Hi All,
Please help us to review the design of Gluster Volume Snapshots in oVirt,
Here are two design on wiki page
General Feature Design
http://www.ovirt.org/Features/GlusterVolumeSnapshots
Detailed Design
http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
We target it in ovirt 3.6 release.
Marked Juan/Michael specifically for REST review.
Best Regards,
Shubhendu Tripathi
My comments about the RESTAPI:
1. You can't use the snapshot and snapshots XML elements, as those
are already in use for disk snapshots, and we don't have name space
support in the RESTAPI. You will have to use something different, for
example gluster_volume_snapshots and gluster_volume_snapshot.
2. When adding a volume snapshot the name of the volume shouldn't be a
parameter, as that is implicit. Only the name and description of the
snapshot should be provided.
3. The operation to delete a snapshot should be performed on the
snapshot resource, not on the collection:
DELETE
/clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
Ideally this operation shouldn't receive any parameters (thus no body).
If it does require parameters then they should be contained inside an
action element.
4. The operation to update the snapshot configuration should be the PUT
operation of the volume, not a new snapshotconfig sub-resource, as
these kind of sub-resources aren't well supported by the SDKs and the CLI.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Thanks Juan for the comments. I would update the wiki accordingly and send for
confirmation.
Regards
Shubhendu
Sent from Samsung Mobile
Original message
From: Juan Hernández jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi shtri...@redhat.com,devel@ovirt.org,Michael Pasternak
mpast...@redhat.com
Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
Hi Juan/Michael,
This is a gentle reminder for the review of the REST api design for the
below feature.
We would be starting the REST development for the same soon (probably by
Dec 2014 end).
If there are specific comments, please pass it on. If no comments we
would go ahead with the current design and implement accordingly.
Request your time for this.
Thanks and Regards,
Shubhendu
On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
Hi All,
Please help us to review the design of Gluster Volume Snapshots in oVirt,
Here are two design on wiki page
General Feature Design
http://www.ovirt.org/Features/GlusterVolumeSnapshots
Detailed Design
http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
We target it in ovirt 3.6 release.
Marked Juan/Michael specifically for REST review.
Best Regards,
Shubhendu Tripathi
My comments about the RESTAPI:
1. You can't use the snapshot and snapshots XML elements, as those
are already in use for disk snapshots, and we don't have name space
support in the RESTAPI. You will have to use something different, for
example gluster_volume_snapshots and gluster_volume_snapshot.
2. When adding a volume snapshot the name of the volume shouldn't be a
parameter, as that is implicit. Only the name and description of the
snapshot should be provided.
3. The operation to delete a snapshot should be performed on the
snapshot resource, not on the collection:
DELETE
/clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
Ideally this operation shouldn't receive any parameters (thus no body).
If it does require parameters then they should be contained inside an
action element.
4. The operation to update the snapshot configuration should be the PUT
operation of the volume, not a new snapshotconfig sub-resource, as
these kind of sub-resources aren't well supported by the SDKs and the CLI.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Certain questions about Quartz based scheduling in oVirt
Hi All, We are in a requirement where we need to schedule jobs at certain time interval, hourly, daily, weekly and monthly (i.e. repetitive and cron kind of scheduling). I was trying to understand quartz based scheduling mechanism in oVirt to achieve the scenarios. Have some basic questions regarding the same - 1. Is there is mechanism to persist the scheduling data in oVirt ? 2. How to tackle edit and rescheduling of jobs ? Kindly guide on how to achieve these. Thanks and Regards, Shubhendu ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Error while building ovirt upstream
On 11/13/2014 12:54 PM, Sandro Bonazzola wrote: Il 13/11/2014 06:16, Shubhendu Tripathi ha scritto: Hi, Today I rebased with master and getting below error while building the engine. [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ vdsbroker --- [INFO] Compiling 312 source files to Home/work/ovirt-engine/backend/manager/modules/vdsbroker/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] error: error reading Home/.m2/repository/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/vdsm-jsonrpc-java-client-1.1.0-SNAPSHOT.jar; error in opening zip file [INFO] 1 error Kindly help resolving the same. Looks like your jar file got corrupted. Can you try removing ~/.m2/repository/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/vdsm-jsonrpc-java-client-1.1.0-SNAPSHOT.jar and rebuild? Sandro, I removed the whole dir ~/.m2 and tried again, but still the issue. I did one more analysis where I took latest master and reset to the state one patch below change-id Ib69768ab2b384136308e16624a365c98583fba63 (jsonrpc: json version bumped). Then the build went through. If I apply the above mentioned patch again, build fails. So I guess this issue is specific to some packages (though a weird guess). Regards, Shubhendu Regards, Shubhendu ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Error while building ovirt upstream
On 11/13/2014 02:19 PM, Piotr Kliczewski wrote: On Thu, Nov 13, 2014 at 9:26 AM, Shubhendu Tripathi shtri...@redhat.com wrote: On 11/13/2014 12:54 PM, Sandro Bonazzola wrote: Il 13/11/2014 06:16, Shubhendu Tripathi ha scritto: Hi, Today I rebased with master and getting below error while building the engine. [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ vdsbroker --- [INFO] Compiling 312 source files to Home/work/ovirt-engine/backend/manager/modules/vdsbroker/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] error: error reading Home/.m2/repository/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/vdsm-jsonrpc-java-client-1.1.0-SNAPSHOT.jar; error in opening zip file [INFO] 1 error Kindly help resolving the same. Looks like your jar file got corrupted. Can you try removing ~/.m2/repository/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/vdsm-jsonrpc-java-client-1.1.0-SNAPSHOT.jar and rebuild? Sandro, I removed the whole dir ~/.m2 and tried again, but still the issue. Is the build failing with the same issue: error opening zip or something else? Even after deleting the whole dir it was failing with same. So explicitly I downloaded the JAR from https://oss.sonatype.org/content/repositories/snapshots/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/. After this build works fine. Not sure how come during build some wrong jar is getting downloaded which is corrupt. I did one more analysis where I took latest master and reset to the state one patch below change-id Ib69768ab2b384136308e16624a365c98583fba63 (jsonrpc: json version bumped). Then the build went through. If I apply the above mentioned patch again, build fails. So I guess this issue is specific to some packages (though a weird guess). Regards, Shubhendu Regards, Shubhendu ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Error while building ovirt upstream
On 11/13/2014 03:53 PM, Piotr Kliczewski wrote: On Thu, Nov 13, 2014 at 11:12 AM, Shubhendu Tripathi shtri...@redhat.com wrote: On 11/13/2014 02:19 PM, Piotr Kliczewski wrote: On Thu, Nov 13, 2014 at 9:26 AM, Shubhendu Tripathi shtri...@redhat.com wrote: On 11/13/2014 12:54 PM, Sandro Bonazzola wrote: Il 13/11/2014 06:16, Shubhendu Tripathi ha scritto: Hi, Today I rebased with master and getting below error while building the engine. [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ vdsbroker --- [INFO] Compiling 312 source files to Home/work/ovirt-engine/backend/manager/modules/vdsbroker/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] error: error reading Home/.m2/repository/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/vdsm-jsonrpc-java-client-1.1.0-SNAPSHOT.jar; error in opening zip file [INFO] 1 error Kindly help resolving the same. Looks like your jar file got corrupted. Can you try removing ~/.m2/repository/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/vdsm-jsonrpc-java-client-1.1.0-SNAPSHOT.jar and rebuild? Sandro, I removed the whole dir ~/.m2 and tried again, but still the issue. Is the build failing with the same issue: error opening zip or something else? Even after deleting the whole dir it was failing with same. So explicitly I downloaded the JAR from https://oss.sonatype.org/content/repositories/snapshots/org/ovirt/vdsm-jsonrpc-java/vdsm-jsonrpc-java-client/1.1.0-SNAPSHOT/. After this build works fine. Not sure how come during build some wrong jar is getting downloaded which is corrupt. What is the mirror that is configured in your settings.xml? Once I deleted ~/.m2 and executed build again I dont have a settings.xml explicitly. I did one more analysis where I took latest master and reset to the state one patch below change-id Ib69768ab2b384136308e16624a365c98583fba63 (jsonrpc: json version bumped). Then the build went through. If I apply the above mentioned patch again, build fails. So I guess this issue is specific to some packages (though a weird guess). Regards, Shubhendu Regards, Shubhendu ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Gluster Volume Snapshots - Feature review
Hi All, Please help us to review the design of Gluster Volume Snapshots in oVirt, Here are two design on wiki page General Feature Design http://www.ovirt.org/Features/GlusterVolumeSnapshots Detailed Design http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots We target it in ovirt 3.6 release. Marked Juan/Michael specifically for REST review. Best Regards, Shubhendu Tripathi ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[Engine-devel] Gluster volume capacity feature
Hi All, A new wiki has been published for feature Gluster Volume Capacity http://www.ovirt.org/Features/Gluster_Volume_Capacity Please review the same and provide your comments. Added Michael and Ori specifically for review of REST apis. Thanks, Shubhendu Tripathi ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [jenkins] dao tests broken
The class VdcUserTest does not exist in master. Whereas it is present in all other branches like ovirt-engine-3.3, ovirt-engine-3.3.0, ovirt-engine-3.3.1 and ovirt-engine-3.3.2. - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Ohad Basan oba...@redhat.com Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Sunday, December 15, 2013 6:59:12 PM Subject: Re: [Engine-devel] [jenkins] dao tests broken Worked for me perfectly on master. - Original Message - From: Ohad Basan oba...@redhat.com To: Gilad Chaplik gchap...@redhat.com Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Sunday, December 15, 2013 1:44:08 PM Subject: Re: [Engine-devel] [jenkins] dao tests broken this job doesn't do any rebase where do you see it ? http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console I didn't find rebase in the console log - Original Message - From: Gilad Chaplik gchap...@redhat.com To: Eyal Edri ee...@redhat.com Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Sunday, December 15, 2013 1:06:04 PM Subject: Re: [Engine-devel] [jenkins] dao tests broken - Original Message - From: Eyal Edri ee...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: infra in...@ovirt.org, Gilad Chaplik gchap...@redhat.com Sent: Sunday, December 15, 2013 12:10:11 PM Subject: [jenkins] dao tests broken fyi, dao tests are broken for some time now, who can look into it? current failing tests are: Hi Eyal, what fails is unit tests and not dao tests (fails on dao job), it looks like you're trying to rebase ovirt-engine-3.3 on top of master (you can see it even it the log, comparing the last success and first fail jobs). can you check it out? Thanks, Gilad. Tests in error: testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console looks like it started after commit : http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/ core: scheduling: handle cpu load duration (detail / gitweb) Eyal. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
On 11/11/2013 08:48 PM, Einav Cohen wrote:
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
Sent: Saturday, November 9, 2013 4:07:44 AM
On 11/06/2013 07:40 PM, Einav Cohen wrote:
- Original Message -
From: Alexander Wels aw...@redhat.com
Sent: Wednesday, November 6, 2013 8:28:13 AM
Looking at the code, if you start the error message with a $ it will not
do
the . to _ replacement. Not sure if your error message will now simply
start
with a $, but it is worth a try I guess.
AFAIK: the '$' prefix is for variable-value message.
e.g. if you have a message cannot run VM ${vm-name} and another one
$vm-name vm1,
then their combination would eventually yield cannot run VM vm1.
Also, I think that messages that begin with $ cannot be displayed when
they
are on their own.
i.e. if you will get message $vm-name vm1 'alone', nothing will
eventually be displayed.
but, as I mentioned, if you will get message $vm-name vm1 along with
message cannot run
VM ${vm-name}, eventually cannot run VM vm1 will be displayed.
I think that the replacement of . to _ should be done only if the
message
represents a *key* in the relevant resource (VdsmErrors in this case).
but if the message is not a key, and would be displayed as-is, on . to
_ replacement
should take place.
adding Derez for his thoughts (I think that he changed something around it
a while ago).
There is an upstream patch according to Einav's suggestion above.
http://gerrit.ovirt.org/#/c/21083/
Many thanks, Shubhendu.
@Derez - any chance that you can take a look (as you probably understand best
this particular code/logic)?
Daniel, any comments on the patch ?
http://gerrit.ovirt.org/#/c/21083/
On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
Hi,
In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!
But while translation of the error messages, all the occurrences of .
get replaced with _.
This causes an issue for the gluster errors. If the error message sent
from gluster has .s (say IP Address of a host or FQDN for a host),
that also gets replaced with _ and the error message does not look
correct.
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of . with _, if the flag is set it will not do the
replacements.
Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RSDL breakage in oVirt upstream
On 11/15/2013 09:28 AM, Shubhendu Tripathi wrote:
On 11/14/2013 08:26 PM, Michael Pasternak wrote:
Hi Shubhendu,
On 11/14/2013 04:32 PM, Shubhendu Tripathi wrote:
Hi Michael/Ori,
There is payload breakage for RSDL in upstream oVirt.
can you elaborate a bit? [1] works for me.
[1] http://localhost:8080/api?rsdl
I have raised the patch http://gerrit.ovirt.org/#/c/21308/ resolving the
same issue.
Kindly have a look and do the needful.
Hi Michael,
The RSDL gets displayed but there are some issues while showing the
payload details for 'glustervolumes'.
Current value shown in the UI is as below -
link href=/ovirt-engine/api/clusters/{cluster:id}/glustervolumes
rel=add
request
http_methodPOST/http_method
body
typeGlusterVolume/type
/body
/request
response
typeGlusterVolume/type
/response
/link
Attached the RSDl file for reference.
Whereas the correct value should be as below -
link href=/api/clusters/{cluster:id}/glustervolumes rel=add
descriptionadd a new gluster volume to the cluster/description
request
http_methodPOST/http_method
headers
header required=true
nameContent-Type/name
valueapplication/xml|json/value
/header
header required=false
nameExpect/name
value201-created/value
/header
header required=false
nameCorrelation-Id/name
valueany string/value
/header
/headers
body
typeGlusterVolume/type
parameters_set
description
add a new gluster volume to the cluster at the specified gluster fs
server
/description
parameter required=true type=xs:string
namegluster_volume.name/name
/parameter
parameter required=true type=xs:string
namegluster_volume.volume_type/name
/parameter
parameter required=true type=collection
namegluster_volume.bricks.brick/name
parameters_set
parameter required=true type=xs:string
namebrick.server_id/name
/parameter
parameter required=true type=xs:string
namebrick.brick_dir/name
/parameter
/parameters_set
/parameter
parameter required=false type=collection
namegluster_volume.transport_types/name
parameters_set
parameter required=false type=xs:string
nametransport_type/name
/parameter
/parameters_set
/parameter
parameter required=false type=xs:unsignedShort
namegluster_volume.replica_count/name
/parameter
parameter required=false type=xs:unsignedShort
namegluster_volume.stripe_count/name
/parameter
parameter required=false type=collection
namegluster_volume.options.option/name
parameters_set
parameter required=false type=xs:string
nameoption.name/name
/parameter
parameter required=false type=xs:string
nameoption.value/name
/parameter
/parameters_set
/parameter
/parameters_set
/body
/request
response
typeGlusterVolume/type
/response
/link
This has happened somewhere between the patches
gerrit.ovirt.org/#/c/20610/ and http://gerrit.ovirt.org/#/c/15409/.
If I try to test out with patch http://gerrit.ovirt.org/#/c/15409/,
it does break.
Not sure what could be the issue. Tried debugging but not able to
figure it out.
Kindly help me on the same figuring out what could be the issue.
Thanks and Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
Self and Ori had a detailed discussion on the topic.
Points discussed -
1. Ori mentioned that Michael and Ori did not mean to have a separate
DELETE action for the purpose of commit in previous discussions.
2. Ori tried to understand the intention behind the separate commit
command in gluster and suggested that ideally gluster should remember
that a migration of data is started on the set of bricks, and if there
is a delete fired on the same bricks it should perform a commit action
because commit is nothing but a delete action
3. Ori suggested that in an ideal situation APIs needed would be
- start migrate
- stop migrate
- delete bricks
- retain bricks
4. As suggested by Ori, the remove bricks action should internally
decide if there was a data migration, started on the set of bricks. If
so, it should effectively fire a commit for the set of bricks. And if
there was not occurrence of data migration it should behave like a
normal force remove action.
Ori, please add your comments if I have missed out anything here.
Sahina, request your comments on the same.
Thanks and Regards,
Shubhendu
On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote:
On 11/10/2013 11:06 PM, Moti Asayag wrote:
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
To: engine-devel engine-devel@ovirt.org, Michael Pasternak
mpast...@redhat.com, ol...@redhat.com
Sent: Friday, November 8, 2013 8:37:30 AM
Subject: [Engine-devel] REST-API: Problem with additional DELETE
action atcollection level
Hi All,
There is a DELETE action defined at collection level for Gluster
Bricks with
signature -
@DELETE
public Response remove ( GlusterBricks bricks );
Recently we had needed a commit action to remove migrated bricks.
After multiple rounds of discussion on introducing a commit action
to remove
migrated bricks we introduced a DELETE action [1] which accepts a
boolean
parameter isForce.
If the parameter is set to true , forced deletion of bricks happens
without
any data migration.
And if the parameter is not set or set to false, the deletion is
meant for a
brick on which migration has already taken place.
To achieve the above functionality we introduced another DELETE
action with
new signature as below and also marked the first action as deprecated -
@DELETE
public Response remove ( Action action );
The problem arises now as the new api works fine for all possible
scenarios
with below input structure -
action
forcetrue/false/force
bricks
brick
name brick1-name/name
namebrick2-name/name
/brick
/bricks
/action
BUT after these change backward compatibility is broken and the old
api does
not work.
If we try invoking old DELETE with bricks as input parameter as
below, it
still invokes the new api and gives an error saying Invalid
parameter .
Maybe I've missed it some where, but i wasn't able to find the new
'force' parameter
in the rsdl, and specifically not in optionalArguments list of:
- name:
/api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete
and perhaps the correct approach will be to deprecate this signature
and introduce a new
one with the 'force' in the 'mandatoryArguments' section.
Moti, I have introduced another methods remove of DELETE type which
takes Action as input.
I pass list of bricks and force as parameter in the same Action.
Also, I tried marking the old method deprecated and introduced the new
one BUT as mentioned above, after introduction of new DELETE with
Action parameter old one STOPS working.
Is it OK to stop working for a method if its deprecated?? I don't feel
so. Please comment.
bricks
brick id=brick1-id/
brick id=brick2-id/
/bricks
Kindly suggest a solution around the same.
PS: Both the actions are defined at collection level (
/api/clusters/cluster-id/glustervolumes/volume-id/bricks )
[1]: http://gerrit.ovirt.org/#/c/21043/
Thanks and Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
On 11/11/2013 04:08 PM, Ori Liel wrote: - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: ol...@redhat.com, Michael Pasternak mpast...@redhat.com, Sahina Bose sab...@redhat.com Cc: Dusmant Pati dp...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Monday, November 11, 2013 12:00:34 PM Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Self and Ori had a detailed discussion on the topic. Points discussed - 1. Ori mentioned that Michael and Ori did not mean to have a separate DELETE action for the purpose of commit in previous discussions. That's right - no need for a new delete signature; existing signatures are enough. 2. Ori tried to understand the intention behind the separate commit command in gluster and suggested that ideally gluster should remember that a migration of data is started on the set of bricks, and if there is a delete fired on the same bricks it should perform a commit action because commit is nothing but a delete action 3. Ori suggested that in an ideal situation APIs needed would be - start migrate - stop migrate - delete bricks - retain bricks 4. As suggested by Ori, the remove bricks action should internally decide if there was a data migration, started on the set of bricks. If so, it should effectively fire a commit for the set of bricks. And if there was not occurrence of data migration it should behave like a normal force remove action. Ori, please add your comments if I have missed out anything here. I agree with what you wrote, let me sort of say it again in my words: I don't like requiring two consecutive commands from the API user, to perform migrate. If the user only does 'migrate', and doesn't do the second step, we are in a state of corruption. But Shubhendu explained to me that there's no way around this; the administrator *must* take a look and decide; it is simply not possible to make this decision in advance. So I accepted this heavy-heartedly. Then we were left with the decision of how to model this two step operation. I tried to look at it from the point of view of the user; what would be the simplest way to 'tell him the story?' - If you want to migrate a brick, run 'migrate' on it. - If you want to stop migration of the brick, run 'stopMigrate' on it. - If you want to resume the migration of the brick, simply run 'migrate' on it again. After migration is done: - if you want to remove the brick, DELETE it (regular delete). - if you want to keep using the brick, run 'reactivate' on it. And that's the whole story. The advantages are: * In simple English, not bound to Gluster terms, the administrator has to decide whether to get rid of the brick, remove it, when migration is done. So what would be more natural than to delete it? It makes sense, and there's no need for a new 'action'. On the Gluster side, if user tried to delete a brick which is undergoing migration - simply don't allow it. This is something you have to do anyway; a user might try to delete a brick which is undergoing migration and you have to stop him from doing so. So 0 extra work here. * Instead of stopMigrate meaning two different things in two different contexts, we now have stopMigration mean exactly what its name suggests: it stops the migration, and 'reactive' mean exactly what it suggests - mark this brick as active again, allow it to be used. Thanks Ori for the detailed mail. So now the final set of APIs are - - migrate - stopmigrate - delete (existing delete to be enabled for commit) - reactivate Will go ahead with this and raise the patches accordingly. Thanks and Regards, Shubhendu Sahina, request your comments on the same. Thanks and Regards, Shubhendu On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: On 11/10/2013 11:06 PM, Moti Asayag wrote: - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com, ol...@redhat.com Sent: Friday, November 8, 2013 8:37:30 AM Subject: [Engine-devel] REST-API: Problem with additional DELETE action atcollection level Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - @DELETE public Response remove ( GlusterBricks bricks ); Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to true , forced deletion of bricks happens without any data migration. And if the parameter is not set or set to false, the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - @DELETE public Response remove
Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
On 11/10/2013 11:06 PM, Moti Asayag wrote:
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
To: engine-devel engine-devel@ovirt.org, Michael Pasternak
mpast...@redhat.com, ol...@redhat.com
Sent: Friday, November 8, 2013 8:37:30 AM
Subject: [Engine-devel] REST-API: Problem with additional DELETE action at
collection level
Hi All,
There is a DELETE action defined at collection level for Gluster Bricks with
signature -
@DELETE
public Response remove ( GlusterBricks bricks );
Recently we had needed a commit action to remove migrated bricks.
After multiple rounds of discussion on introducing a commit action to remove
migrated bricks we introduced a DELETE action [1] which accepts a boolean
parameter isForce.
If the parameter is set to true , forced deletion of bricks happens without
any data migration.
And if the parameter is not set or set to false, the deletion is meant for a
brick on which migration has already taken place.
To achieve the above functionality we introduced another DELETE action with
new signature as below and also marked the first action as deprecated -
@DELETE
public Response remove ( Action action );
The problem arises now as the new api works fine for all possible scenarios
with below input structure -
action
forcetrue/false/force
bricks
brick
name brick1-name/name
namebrick2-name/name
/brick
/bricks
/action
BUT after these change backward compatibility is broken and the old api does
not work.
If we try invoking old DELETE with bricks as input parameter as below, it
still invokes the new api and gives an error saying Invalid parameter .
Maybe I've missed it some where, but i wasn't able to find the new 'force'
parameter
in the rsdl, and specifically not in optionalArguments list of:
- name:
/api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete
and perhaps the correct approach will be to deprecate this signature and
introduce a new
one with the 'force' in the 'mandatoryArguments' section.
Moti, I have introduced another methods remove of DELETE type which
takes Action as input.
I pass list of bricks and force as parameter in the same Action.
Also, I tried marking the old method deprecated and introduced the new
one BUT as mentioned above, after introduction of new DELETE with Action
parameter old one STOPS working.
Is it OK to stop working for a method if its deprecated?? I don't feel
so. Please comment.
bricks
brick id=brick1-id/
brick id=brick2-id/
/bricks
Kindly suggest a solution around the same.
PS: Both the actions are defined at collection level (
/api/clusters/cluster-id/glustervolumes/volume-id/bricks )
[1]: http://gerrit.ovirt.org/#/c/21043/
Thanks and Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Error message while trying to delete default cluster
Hi, While trying to delete the Default cluster in oVirt it shows the below error message - Cannot remove default Host Cluster. Cannot remove Cluster. One or more Template(s) are still associated with it But in the case of RHSC, Templates are not used and this message is not relevant. [1]. Can we opt for not installing the templates while engine setup? And would it be having any impact/consequences ? Kindly provide your thoughts and possibility of the same. Thanks and Regards, Shubhendu PS: [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1019838 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
On 11/06/2013 07:40 PM, Einav Cohen wrote:
- Original Message -
From: Alexander Wels aw...@redhat.com
Sent: Wednesday, November 6, 2013 8:28:13 AM
Looking at the code, if you start the error message with a $ it will not do
the . to _ replacement. Not sure if your error message will now simply start
with a $, but it is worth a try I guess.
AFAIK: the '$' prefix is for variable-value message.
e.g. if you have a message cannot run VM ${vm-name} and another one $vm-name
vm1,
then their combination would eventually yield cannot run VM vm1.
Also, I think that messages that begin with $ cannot be displayed when they
are on their own.
i.e. if you will get message $vm-name vm1 'alone', nothing will eventually be
displayed.
but, as I mentioned, if you will get message $vm-name vm1 along with message
cannot run
VM ${vm-name}, eventually cannot run VM vm1 will be displayed.
I think that the replacement of . to _ should be done only if the message
represents a *key* in the relevant resource (VdsmErrors in this case).
but if the message is not a key, and would be displayed as-is, on . to _
replacement
should take place.
adding Derez for his thoughts (I think that he changed something around it a
while ago).
There is an upstream patch according to Einav's suggestion above.
http://gerrit.ovirt.org/#/c/21083/
On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
Hi,
In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!
But while translation of the error messages, all the occurrences of .
get replaced with _.
This causes an issue for the gluster errors. If the error message sent
from gluster has .s (say IP Address of a host or FQDN for a host),
that also gets replaced with _ and the error message does not look
correct.
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of . with _, if the flag is set it will not do the
replacements.
Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] REST-API: Problem with additional DELETE action at collection level
Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - /@DELETE publicResponse//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - /@DELETE publicResponse//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible scenarios with below input structure - / //action// //forcetrue/false/force// //bricks// //brick// //name//brick1-name/name// //namebrick2-name/name// ///brick// ///bricks// ///action/ BUT after these change backward compatibility is broken and the old api does not work. If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying Invalid parameter. / //bricks brick id=brick1-id/ //brick id=brick2-id/ /bricks/ Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level (//api/clusters/cluster-id/glustervolumes/volume-id/bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] REST-API: Problem with additional DELETE action at collection level
Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - /@DELETE publicResponse//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - /@DELETE publicResponse//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible scenarios with below input structure - / //action// //forcetrue/false/force// //bricks// //brick// //name//brick1-name/name// //namebrick2-name/name// ///brick// ///bricks// ///action/ BUT after these change backward compatibility is broken and the old api does not work. If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying Invalid parameter. / //bricks brick id=brick1-id/ //brick id=brick2-id/ /bricks/ Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level (//api/clusters/cluster-id/glustervolumes/volume-id/bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
Hi,
In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!
But while translation of the error messages, all the occurrences of .
get replaced with _.
This causes an issue for the gluster errors. If the error message sent
from gluster has .s (say IP Address of a host or FQDN for a host),
that also gets replaced with _ and the error message does not look
correct.
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of . with _, if the flag is set it will not do the
replacements.
Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
On 11/06/2013 07:43 PM, Daniel Erez wrote:
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
To: de...@redhat.com, engine-devel engine-devel@ovirt.org
Cc: Dusmant Pati dp...@redhat.com
Sent: Wednesday, November 6, 2013 12:07:34 PM
Subject: IMP: Regarding an issue while translating the error messages for
gluster using ErrorTranslator class
Hi,
In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!
But while translation of the error messages, all the occurrences of .
get replaced with _.
This causes an issue for the gluster errors. If the error message sent
from gluster has .s (say IP Address of a host or FQDN for a host),
that also gets replaced with _ and the error message does not look
correct.
This mechanism of replacing [1] has been introduced to allow proper
message translation when retrieving a message key that contains dots.
E.g. AppErrors.properties - VALIDATION.ROLES.NAME.MAX is translated
to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
signatures cannot contain dots. Note that this process shouldn't
address the message; i.e. only the key is examined for dots.
As you've mentioned VdsmErrorsTranslator I guess there's an issue
only when translating VdsmErrors messages.
Can you please send an example of a message usage?
One example of the error message which is shown on the dialog after
translation is as below -
/Error while executin action Create Gluster Volume: Volume create
failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a
is already part of a volume/
If you see the highlighted portion not only the dots in IP address but
also the full stop is changed to _.
(and maybe try the same message using AppErrors instead)
There are no one to one mapping of these messages in AppErrors as they
arise randomly, so in such cases we throw the VDSM error message as is
on the dialog.
[1] ErrorTranslator - translateErrorTextSingle()
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of . with _, if the flag is set it will not do the
replacements.
Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
On 11/06/2013 07:41 PM, Einav Cohen wrote:
but if the message is not a key, and would be displayed as-is, on . to _
replacement should take place.
on - no*
This solution looks fine. If the error message is not found in the map,
we can revert back to original message which has the .s.
Request comments from others as well.
- Original Message -
From: Einav Cohen eco...@redhat.com
Sent: Wednesday, November 6, 2013 9:10:09 AM
- Original Message -
From: Alexander Wels aw...@redhat.com
Sent: Wednesday, November 6, 2013 8:28:13 AM
Looking at the code, if you start the error message with a $ it will not do
the . to _ replacement. Not sure if your error message will now simply
start
with a $, but it is worth a try I guess.
AFAIK: the '$' prefix is for variable-value message.
e.g. if you have a message cannot run VM ${vm-name} and another one
$vm-name vm1,
then their combination would eventually yield cannot run VM vm1.
Also, I think that messages that begin with $ cannot be displayed when they
are on their own.
i.e. if you will get message $vm-name vm1 'alone', nothing will eventually
be displayed.
but, as I mentioned, if you will get message $vm-name vm1 along with
message cannot run
VM ${vm-name}, eventually cannot run VM vm1 will be displayed.
I think that the replacement of . to _ should be done only if the message
represents a *key* in the relevant resource (VdsmErrors in this case).
but if the message is not a key, and would be displayed as-is, on . to _
replacement
should take place.
adding Derez for his thoughts (I think that he changed something around it a
while ago).
On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
Hi,
In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!
But while translation of the error messages, all the occurrences of .
get replaced with _.
This causes an issue for the gluster errors. If the error message sent
from gluster has .s (say IP Address of a host or FQDN for a host),
that also gets replaced with _ and the error message does not look
correct.
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of . with _, if the flag is set it will not do the
replacements.
Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
On 11/06/2013 09:29 PM, Daniel Erez wrote:
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
To: Daniel Erez de...@redhat.com
Cc: engine-devel engine-devel@ovirt.org, Dusmant Pati dp...@redhat.com
Sent: Wednesday, November 6, 2013 4:31:52 PM
Subject: Re: IMP: Regarding an issue while translating the error messages for
gluster using ErrorTranslator class
On 11/06/2013 07:43 PM, Daniel Erez wrote:
- Original Message -
From: Shubhendu Tripathi shtri...@redhat.com
To: de...@redhat.com, engine-devel engine-devel@ovirt.org
Cc: Dusmant Pati dp...@redhat.com
Sent: Wednesday, November 6, 2013 12:07:34 PM
Subject: IMP: Regarding an issue while translating the error messages for
gluster using ErrorTranslator class
Hi,
In the case of Gluster, as there are no one to one mappings available
for all the error messages from Gluster, we set the error in the
VdcFault object as NULL.
We also populate the actual error from the Gluster as error message in
the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);//
//getReturnValue().getFault().setMessage(error);//
//getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/
class the error message as is gets displayed on the error dialog -
/
//public String translateVdcFault(final VdcFault fault) {//
//return
getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() ==
null//
//? fault.getMessage() : fault.getError().toString());//
//}//
/
Well and good till now !!
But while translation of the error messages, all the occurrences of .
get replaced with _.
This causes an issue for the gluster errors. If the error message sent
from gluster has .s (say IP Address of a host or FQDN for a host),
that also gets replaced with _ and the error message does not look
correct.
This mechanism of replacing [1] has been introduced to allow proper
message translation when retrieving a message key that contains dots.
E.g. AppErrors.properties - VALIDATION.ROLES.NAME.MAX is translated
to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface
signatures cannot contain dots. Note that this process shouldn't
address the message; i.e. only the key is examined for dots.
As you've mentioned VdsmErrorsTranslator I guess there's an issue
only when translating VdsmErrors messages.
Can you please send an example of a message usage?
One example of the error message which is shown on the dialog after
translation is as below -
/Error while executin action Create Gluster Volume: Volume create
failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a
is already part of a volume/
What are the keys that been sent from the engine (i.e. the message before
translation)?
We set message code as NULL and error message is set as is whatever is
received from VDSM. Message contains dots (.) as part of it.
Code snippet is shown below -
/getReturnValue().getExecuteFailedMessages().add(error);
getReturnValue().getFault().setMessage(error);
getReturnValue().getFault().setError(null);/
If you see the highlighted portion not only the dots in IP address but
also the full stop is changed to _.
(and maybe try the same message using AppErrors instead)
There are no one to one mapping of these messages in AppErrors as they
arise randomly, so in such cases we throw the VDSM error message as is
on the dialog.
[1] ErrorTranslator - translateErrorTextSingle()
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called
/isExternalError/ in /VdcFault/ class to identify if the source of the
fault is external. From Gluster we would set the flag as /true/, and
while replacement of . with _, if the flag is set it will not do the
replacements.
Regards,
Shubhendu
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Regarding access to ovirt.org for creating feature pages
Hi All, I have joined RedHat this month and work with RHSC team. I need to create a feature page on Ovirt WIKI, and so raised a request for the same to get an id created. I have not received any confirmation till now. Kindly let me know if something is missing or I need to follow some other process. ID Created: shtripat Email Id: shtri...@redhat.com Thanks and Regards, Shubhendu Tripathi attachment: shtripat.vcf___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
