2024-06-25T01:25:56.121Z

<Raghu> i tried that before and as this is multisite, i saw the following error message
```ceph rgw zone create -i /tmp/rgw2.spec --start-radosgw
Error EINVAL: Traceback (most recent call last):
  File "/usr/share/ceph/mgr/mgr_module.py", line 1864, in _handle_command
    return CLICommand.COMMANDS[cmd['prefix']].call(self, cmd, inbuf)
  File "/usr/share/ceph/mgr/mgr_module.py", line 499, in call
    return self.func(mgr, **kwargs)
  File "/usr/share/ceph/mgr/rgw/module.py", line 96, in wrapper
    return func(self, **args, ***kwargs)
  File "/usr/share/ceph/mgr/rgw/module.py", line 304, in _cmd_rgw_zone_create
    return HandleCommandResult(retval=0, stdout=f"Zones {', '.join(created_zones)} created successfully")
TypeError: sequence item 0: expected str instance, int found```
Since the zone already exist, this does fail halfway though.

2024-06-25T01:26:18.550Z

<Raghu> i tried that before and as this is secondary site in a multisite config, i saw the following error message
```ceph rgw zone create -i /tmp/rgw2.spec --start-radosgw
Error EINVAL: Traceback (most recent call last):
  File "/usr/share/ceph/mgr/mgr_module.py", line 1864, in _handle_command
    return CLICommand.COMMANDS[cmd['prefix']].call(self, cmd, inbuf)
  File "/usr/share/ceph/mgr/mgr_module.py", line 499, in call
    return self.func(mgr, **kwargs)
  File "/usr/share/ceph/mgr/rgw/module.py", line 96, in wrapper
    return func(self, **args, ***kwargs)
  File "/usr/share/ceph/mgr/rgw/module.py", line 304, in _cmd_rgw_zone_create
    return HandleCommandResult(retval=0, stdout=f"Zones {', '.join(created_zones)} created successfully")
TypeError: sequence item 0: expected str instance, int found```
Since the zone already exist, this does fail halfway though.

2024-06-25T01:39:21.638Z

<Raghu> i tried that before and as this is secondary site in a multisite config, i saw the following error message
```ceph rgw zone create -i /tmp/rgw2.spec --start-radosgw
Error EINVAL: Traceback (most recent call last):
  File "/usr/share/ceph/mgr/mgr_module.py", line 1864, in _handle_command
    return CLICommand.COMMANDS[cmd['prefix']].call(self, cmd, inbuf)
  File "/usr/share/ceph/mgr/mgr_module.py", line 499, in call
    return self.func(mgr, **kwargs)
  File "/usr/share/ceph/mgr/rgw/module.py", line 96, in wrapper
    return func(self, **args, ***kwargs)
  File "/usr/share/ceph/mgr/rgw/module.py", line 304, in _cmd_rgw_zone_create
    return HandleCommandResult(retval=0, stdout=f"Zones {', '.join(created_zones)} created successfully")
TypeError: sequence item 0: expected str instance, int found```
Since the zone already exist, this does fail halfway though.

Does this mean i have to cleanup all the secondary site configuration and setup a fresh mulstisite  ?

2024-06-25T12:09:42.261Z

<Innocent T.> When installing ceph cluster using cephadm, ntp service such as chrony is required. I wanted to ask if systemd-timesyncd which is enabled by default in ubuntu, can't be used by ceph.

2024-06-25T13:05:33.526Z

<Matthew Vernon> I think not - systemd-timesyncd is not for use-cases where high-precision timekeeping is required. AIUI.

2024-06-25T15:06:41.017Z

<John Mulligan> It's already supported. AFAIK, <https://github.com/ceph/ceph/blob/main/src/cephadm/cephadm.py#L4432>

If you're having issues with it you may need to debug it some.

2024-06-25T16:59:06.227Z

<Adam King> if the zone is already there, you can just apply the spec directly to the orchestrator with `ceph orch apply -i...` rather than `ceph rgw zone create...`. That zone create command is just passing the spec file to the orchestrator in the end anyway

2024-06-25T17:23:13.936Z

<Raghu> Thank you so much,
once i ran
```ceph orch apply rgw rgw.realmcephadm.secondaryzone '--placement=label:rgwsync count-per-host:2' --port=8000```
everything came back up clean , including the replication.

how would we know what caused this service to go away in the first place.  If this was production site, it would have been an outage.

2024-06-25T17:32:17.171Z

<Adam King> I'm not sure what happened originally (the logs snippets don't include the actual removal of the service) but as said before cephadm shouldn't be doing any automatic service removal. I'd be very surprised if this happened again without some human interaction with the cluster (and if so, and you can reproduce it, I'd like to know)