Bug 1214799

##
# @StorageDomain.create:
#
# Create a new Storage Domain.
#
# @storagedomainID:  The UUID of the Storage Domain
#
# @domainType:       The type of backing storage used by the Storage Domain
#
# @typeArgs:         Type specific backing storage specifier
#
# @name:             A human-readable name
#
# @domainClass:      The Storage Domain Class
#
# @version:          #optional The Storage Domain version that should be used
#
# Since: 4.10.0
##
{'command': {'class': 'StorageDomain', 'name': 'create'},
 'data': {'storagedomainID': 'UUID', 'domainType': 'StorageDomainType',
          'typeArgs': 'StorageDomainCreateArguments', 'name': 'str',
          'domainClass': 'StorageDomainImageClass', '*version': 'int'}}

##
# @StorageDomainType:
#
# An enumeration of Storage Domain types.
#
# @UNKNOWN:   The type is not known
#
# @NFS:       The Storage Domain uses Network File System based storage
#
# @FCP:       The Storage Domain uses FibreChannel based storage
#
# @ISCSI:     The Storage Domain uses iSCSI based storage
#
# @LOCALFS:   The Storage Domain uses storage on the local file system
#
# @CIFS:      The Storage Domain uses CIFS/SMB based storage
#
# @SHAREDFS:  The Storage Domain uses storage from a Linux VFS file system
#
# Since: 4.10.0
# XXX: Need to specify explicit int values for the enum
##
{'enum': 'StorageDomainType',
 'data': ['UNKNOWN', 'NFS', 'FCP', 'ISCSI', 'LOCALFS', 'CIFS', 'SHAREDFS']}


So also this has moved from int to str?
The call I used since 3.3 comes from XMLRPC bindings provided by lib/vdscli.py

XMLRPC bindings provide createStorageDomain as domainCreate:

    def domainCreate(self, storageType, sdUUID, domainName,
                     typeSpecificArg, domClass,
                     domVersion=None, options=None):
        domain = API.StorageDomain(sdUUID)
        return domain.create(storageType, typeSpecificArg, domainName, domClass, domVersion)

(In reply to Sandro Bonazzola from comment #0)
> looking at the previous lines in the fpaste I see 
> 
> Permission denied for directory:
> /rhev/data-center/mnt/glusterSD/minidell.home:_hosted__engine__glusterfs
> with permissions:7
> 
> and 7 was the storage type specified in the create command:
> 
> createStorageDomain(storageType=7,

7 is (os.R_OK | os.W_OK | os.X_OK), not related to storage type.

This test is done usigng the real uid/gid of the process (vdsm).

Can you check the actual permissions on that path before vdsm is testing it, and after that test?

(In reply to Sandro Bonazzola from comment #1)
> ##
> # @StorageDomain.create:
> # @domainType:       The type of backing storage used by the Storage Domain
> {'command': {'class': 'StorageDomain', 'name': 'create'},
>  'data': {'storagedomainID': 'UUID', 'domainType': 'StorageDomainType',
> 
> ##
> # @StorageDomainType:
> {'enum': 'StorageDomainType',
>  'data': ['UNKNOWN', 'NFS', 'FCP', 'ISCSI', 'LOCALFS', 'CIFS', 'SHAREDFS']}

Note that there is no such type 7 - you are calling with unsupported type :-)

Would you like to open a schema bug for this?

> So also this has moved from int to str?
No, it is unfortunately using 7 instead of the enum name.

When using the xmlrpc interface, you should check how engine uses it and
do the same.

(In reply to Nir Soffer from comment #3)
> (In reply to Sandro Bonazzola from comment #1)
> > ##
> > # @StorageDomain.create:
> > # @domainType:       The type of backing storage used by the Storage Domain
> > {'command': {'class': 'StorageDomain', 'name': 'create'},
> >  'data': {'storagedomainID': 'UUID', 'domainType': 'StorageDomainType',
> > 
> > ##
> > # @StorageDomainType:
> > {'enum': 'StorageDomainType',
> >  'data': ['UNKNOWN', 'NFS', 'FCP', 'ISCSI', 'LOCALFS', 'CIFS', 'SHAREDFS']}
> 
> Note that there is no such type 7 - you are calling with unsupported type :-)
> 
> Would you like to open a schema bug for this?

Done, bug #1215039

> 
> > So also this has moved from int to str?
> No, it is unfortunately using 7 instead of the enum name.
> 
> When using the xmlrpc interface, you should check how engine uses it and
> do the same.

As far as I know, engine is using json bindings, not xmlrpc bindings.
Not sure why vdsm vdscli library is using xml and not json there.

(In reply to Sandro Bonazzola from comment #4)

> 
> As far as I know, engine is using json bindings, not xmlrpc bindings.
> Not sure why vdsm vdscli library is using xml and not json there.

Engine is using both but jsonrpc is default. There is work in progress to have vdscli using jsonrpc.

Can't reproduce with vdsm from git aa15c36027a22a74db66a0395dd90a8e327d2efa.
Closing with insufficient data, I'll reopen if I stumble on this again.