Group possible backend share configurations under same environment

[anoopcs9]

Key considerations:

• cephfs and cephfs.vfs are combined together under cephfs.
  • cephfs.mgr.vfs becomes cephfs.mgr when shares are configured using ceph smb mgr module.
• A new methods field to indicate how variations of each share section are to be configured within smb.conf.
  • Special cases:
    • kernel client approach is not yet supported by ceph mgr module. Accordingly we skip this variation.
    • gpfs scale variant configuration is always based on vfs. Thus we skip iterating over available methods.

fixes #101

[anoopcs9]

I have another branch(group-backend-shares2) which reduces the complexity of changes from test-info.yml.j2 by defining the strategies within global settings.yml.

[anoopcs9]

/retest centos-ci/gpfs.scale

[spuiuk]

Notes: Shares created

cephfs:
share-cephfs-default-vfs
share-cephfs-default-klcient

cephmgr:
share-cephfs-mgr-vfs

[spuiuk]

Looks good. ACK

[xhernandez]

I think that the meaning of variant and method (or strategy) is a bit mixed. Why do we need variant if we already have another list that contains all the variants we want to use ?

[anoopcs9]

I think that the meaning of variant and method (or strategy) is a bit mixed. Why do we need variant if we already have another list that contains all the variants we want to use ?

I intent to change the meaning of variant to indicate how(or who) Samba and/or CTDB configurations are handled during cluster setup. With this we will have just two variants namely, default(independent setup style) and mgr(using ceph mgr module). Each of these variants can have different methods through which shares are configured for client access.

[xhernandez]

I intent to change the meaning of variant to indicate how(or who) Samba and/or CTDB configurations are handled during cluster setup. With this we will have just two variants namely, default(independent setup style) and mgr(using ceph mgr module). Each of these variants can have different methods through which shares are configured for client access.

This means that the variant only makes sense for the ceph backend. All other backends won't have variants, which is a bit weird.

I think that we should move the definition of backends inside settings.yml (see #119). Then we could easily extend the definition like this (just a possible way, not thought much about it):

backends:
  cephfs:
    provider: mgr
    settings:
        <optional mgr specific options>
    shares:
      kclient:
        <optional kclient specific options>
      vfs:
        <optional vfs specific options>

This way we could easily create more than one backend, with multiple shares, in a single configuration (additional work required to avoid using the same devices, but that's another problem).

In any case, this is not related to this patch. We can discuss this in #119.

[anoopcs9]

I intent to change the meaning of variant to indicate how(or who) Samba and/or CTDB configurations are handled during cluster setup. With this we will have just two variants namely, default(independent setup style) and mgr(using ceph mgr module). Each of these variants can have different methods through which shares are configured for client access.

This means that the variant only makes sense for the ceph backend. All other backends won't have variants, which is a bit weird.

I have considered scale as a variant for GPFS.

I think that we should move the definition of backends inside settings.yml (see #119). Then we could easily extend the definition like this (just a possible way, not thought much about it):

backends:
  cephfs:
    provider: mgr
    settings:
        <optional mgr specific options>
    shares:
      kclient:
        <optional kclient specific options>
      vfs:
        <optional vfs specific options>

This way we could easily create more than one backend, with multiple shares, in a single configuration (additional work required to avoid using the same devices, but that's another problem).

In any case, this is not related to this patch. We can discuss this in #119.

Sure.

For now I've updated to include the suggestion to use only methods avoiding the strategy keyword.

[spuiuk]

ACK