1. 27 Apr, 2020 1 commit
  2. 30 Mar, 2020 1 commit
  3. 10 Apr, 2019 1 commit
  4. 29 Nov, 2018 2 commits
  5. 17 Nov, 2018 1 commit
  6. 22 Oct, 2018 1 commit
  7. 16 Oct, 2018 1 commit
    • Andy McCrae's avatar
      Add ability to use a different client container · 3e0fa3bc
      Andy McCrae authored
      
      
      Currently a throw-away container is built to run ceph client
      commands to setup users, pools & auth keys. This utilises
      the same base ceph container which has all the ceph services
      inside it.
      
      This PR allows the use of a separate container if the deployer
      wishes - but defaults to use the same full ceph container.
      
      This can be used for different architectures or distributions,
      which may support the the Ceph client, but not Ceph server,
      and allows the deployer to build and specify a separate client
      container if need be.
      Signed-off-by: default avatarAndy McCrae <andy.mccrae@gmail.com>
      3e0fa3bc
  8. 07 Sep, 2018 1 commit
  9. 31 Aug, 2018 1 commit
    • Andy McCrae's avatar
      Dont run client dummy container on non-x86_64 hosts · 772e6b9b
      Andy McCrae authored
      
      
      The dummy client container currently wont work on non-x86_64 hosts.
      This PR creates a filtered client group that contains only hosts
      that are x86_64 - which can then be the group to run the
      dummy container against.
      
      This is for the specific case of a containerized_deployment where
      there is a mixture of non-x86_64 hosts and x86_64 hosts. As such
      the filtered group will contain all hosts when running with
      containerized_deployment: false.
      
      Currently ppc64le is not supported for Ceph server components.
      Signed-off-by: default avatarAndy McCrae <andy.mccrae@gmail.com>
      772e6b9b
  10. 13 Jul, 2018 1 commit
  11. 03 Jul, 2018 1 commit
  12. 13 Jun, 2018 1 commit
    • Guillaume Abrioux's avatar
      client: try to kill dummy container only on first client node · 51cf3b7f
      Guillaume Abrioux authored
      The 'dummy' container is created only on first client node, it means we
      must seek to destroy this container only on this node, otherwise this
      can cause failure like following :
      ```
      fatal: [192.168.24.8]: FAILED! => {"changed": false, "cmd": ["docker", "rm",
      "-f", "ceph-create-keys"], "delta": "0:00:00.023692", "end": "2018-06-12
      20:56:07.261278", "msg": "non-zero return code", "rc": 1, "start":
      "2018-06-12 20:56:07.237586", "stderr": "Error response from daemon: No such
      container: ceph-create-keys", "stderr_lines": ["Error response from daemon: No
      such container: ceph-create-keys"], "stdout": "", "stdout_lines": []}
      
      ```
      
      Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1590746
      
      Signed-off-by: default avatarGuillaume Abrioux <gabrioux@redhat.com>
      51cf3b7f
  13. 08 Jun, 2018 1 commit
  14. 07 Jun, 2018 2 commits
    • Guillaume Abrioux's avatar
      client: add a default value for keyring file · 8a653cac
      Guillaume Abrioux authored
      
      
      Potential error if someone doesnt pass the mode in `keys` dict for
      client nodes:
      
      ```
      fatal: [client2]: FAILED! => {}
      
      MSG:
      
      The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'mode'
      
      The error appears to have been in '/home/guits/ceph-ansible/roles/ceph-client/tasks/create_users_keys.yml': line 117, column 3, but may
      be elsewhere in the file depending on the exact syntax problem.
      
      The offending line appears to be:
      
      - name: get client cephx keys
        ^ here
      
      exception type: <class 'ansible.errors.AnsibleUndefinedVariable'>
      exception: 'dict object' has no attribute 'mode'
      
      ```
      
      adding a default value will avoid the deployment failing for this.
      Signed-off-by: default avatarGuillaume Abrioux <gabrioux@redhat.com>
      8a653cac
    • Guillaume Abrioux's avatar
      client: use dummy created container when there is no mon in inventory · 7b156deb
      Guillaume Abrioux authored
      
      
      the `docker_exec_cmd` fact set in client role when there is no monitor
      in inventory is wrong, `ceph-client-{{ hostname }}` is never created so
      it will fail anyway.
      Signed-off-by: default avatarGuillaume Abrioux <gabrioux@redhat.com>
      7b156deb
  15. 10 May, 2018 1 commit
  16. 03 May, 2018 1 commit
    • Guillaume Abrioux's avatar
      client: fix pool creation · 6fe8df62
      Guillaume Abrioux authored
      
      
      the value in `docker_exec_client_cmd` doesn't allow to check for
      existing pools because it's set with a wrong value for the entrypoint
      that is going to be used.
      It means the check were going to fail anyway even if pools actually exist.
      
      Using jinja syntax to set `docker_exec_cmd` allows to handle the case
      where you don't have monitors in your inventory.
      Signed-off-by: default avatarGuillaume Abrioux <gabrioux@redhat.com>
      6fe8df62
  17. 30 Apr, 2018 2 commits
  18. 23 Apr, 2018 3 commits
  19. 19 Apr, 2018 2 commits
  20. 18 Apr, 2018 2 commits
  21. 11 Apr, 2018 2 commits
  22. 04 Apr, 2018 1 commit
  23. 26 Mar, 2018 1 commit
  24. 14 Mar, 2018 1 commit
  25. 07 Mar, 2018 1 commit
    • Guillaume Abrioux's avatar
      client: fix pgs num for client pool creation · 9181c94a
      Guillaume Abrioux authored
      
      
      The `pools` dict defined in `roles/ceph-client/defaults/main.yml`
      shouldn't have `{{ ceph_conf_overrides.global.osd_pool_default_pg_num
      }}` as default value for `pgs` keys.
      
      For instance, if you want some pools to be created but without explicitely
      specifying the pgs for these pools (it means you want to use the
      `osd_pool_default_pg_num`), you will be obliged to define
      `{{ ceph_conf_overrides.global.osd_pool_default_pg_num }}` anyway while you
      wanted to use the current default value already defined in the cluster which is
      retrieved early in the playbook and stored in the
      `{{ osd_pool_default_pg_num }}` fact.
      Signed-off-by: default avatarGuillaume Abrioux <gabrioux@redhat.com>
      9181c94a
  26. 14 Dec, 2017 1 commit
  27. 03 Nov, 2017 1 commit
    • Sébastien Han's avatar
      osd: enhance backward compatibility · d4ed9a20
      Sébastien Han authored
      During the initial implementation of this 'old' thing we were falling
      into this issue without noticing
      https://github.com/moby/moby/issues/30341
      
       and where blindly using --rm,
      now this is fixed the prepare container disappears and thus activation
      fail.
      I'm fixing this for old jewel images.
      
      Also this fixes the machine reboot case where the docker logs are
      purgend. In the old scenario, we now store the log locally in the same
      directory as the ceph-osd-run.sh script.
      Signed-off-by: default avatarSébastien Han <seb@redhat.com>
      d4ed9a20
  28. 26 Oct, 2017 1 commit
    • John Fulton's avatar
      Make acls and mode parameters of opentack_keys optional · ae156e9f
      John Fulton authored
      Only chmod or setfacl the requested keyring(s) in the
      opentack_keys data structure when the mode or acls keys
      of that data structure exist.
      
      User may specify four permission combinations for the
      keyring file(s): 1. only set ACL, 2. only set mode,
      3. set neither mode nor ACL, 4. set mode and then ACL.
      
      Fixes: #2092
      ae156e9f
  29. 18 Sep, 2017 1 commit
  30. 06 Sep, 2017 1 commit
    • John Fulton's avatar
      Add option to create client keyring file but not import it · a57f61ef
      John Fulton authored
      Add new boolean parameter for client config create_key_file_only
      with a default of false. When create_key_file_only is true, the
      client tasks to connect to the external ceph cluster to verify
      the key `ceph auth import` the key are skipped.
      
      Fixes: #1848
      a57f61ef
  31. 10 Aug, 2017 1 commit
    • John Fulton's avatar
      Allow user to specify the mode of the openstack keys · 7d429410
      John Fulton authored
      The openstack_keys structure now supports a key called mode
      whose value is a string that one could pass to chmod to set
      the mode of the key file. The ansible file module applies the
      mode to all openstack keys with this property.
      
      Fixes: #1755
      7d429410
  32. 20 Jul, 2017 1 commit
    • John Fulton's avatar
      Allow user to define ACLs for OpenStack keys · 73633f05
      John Fulton authored
      The keys and openstack_keys structure now supports an optional
      key called acls whose value is a list of strings one could pass
      to setfacl. The ansible ACL module applies the ACLs to all
      openstack keys with this property.
      
      Fixes: #1688
      73633f05