Unable to restart ceph cluster from scratch about ceph-container

[Ulexus]

Good point. If the cluster has been configured, but no mons are available, ceph/config will fail. The real question is what to do about it. We can try to pull a monmap from etcd, but that would require the mons to update that key somehow.

I think as we converge the rest of the components on etcd/consult/confd, we'll be able to make that viable.

As a stop-gap, we can at least check for the existence of the monmap before attempting to pull it. I'll get that updated when I get some time, or someone can PR it.

[Ulexus]

Of course, that probably won't fix your problem, since in order to get to that point, you have to have not had a ceph.conf. If you don't have that, you probably don't have a monmap, either.

[h0tbird]

I suggest dropping the line with ceph mon getmap -o /etc/ceph/monmap
It is assuming a mon is running when it is not necessarily true.
The peer list can be fully populated later injecting a command into the container with something like this or using a dedicated container (in the same pod) to do so.

[Ulexus]

@h0tbird I think you're right. Lines 44 and 45 are essentially a duplication of effort. We should pull from the KV store and attempt to get a current map, but not fail if we cannot succeed, as long as we have a monmap from which to work.

So, as I see it, the logic should be:

if [ ! -f /etc/ceph/monmap]; then
  kviator... <get monmap>
fi

# ...

# Attempt to get most recent monmap (should be done in main start_mon routine)
set +e
timeout 5 ceph mon getmap -o /etc/ceph/monmap
set -e

[leseb]

Funny enough I had a similar concern while reviewing the first kv PR #103
@Ulexus During the attempt to get the most recent monmap, should we take the opportunity to compare the map and then update the kv backend as well?

[Ulexus]

@leseb My original thought was to attempt to pull the monmap regardless of the backend (and hence, execute it as a part of the main start_mon function. Somehow, though, the monmap does need to be updated in the kv store, and that's as good a time as any. It's probably more flexible to keep the monmap updating in the backend handler, anyway.

TLDR; sounds good to me

[h0tbird]

@CoRfr Since d91137d is merged you should be able to restart the monitors now.

I also have trouble restarting the OSD containers because the OSD_DEVICE is initialized every time. Replacing this...

case "$OSD_TYPE" in
      directory)
         osd_directory
         ;;
      disk)
         osd_disk
         ;;
      activate)
         osd_activate
         ;;
      *)
         if [ -n "$(find /var/lib/ceph/osd -prune -empty)" ]; then
            echo "No bootstrapped OSDs found; trying ceph-disk"
            osd_disk
         else
            echo "Bootstrapped OSD(s) found; using OSD directory"
            osd_directory
         fi
         ;;
   esac

...with this...

   case "$OSD_TYPE" in
      directory)
         osd_directory
         ;;
      disk)
         if [ -n "$(find /var/lib/ceph/osd -prune -empty)" ]; then
            echo "No bootstrapped OSDs found; trying ceph-disk"
            osd_disk
         else
            echo "Bootstrapped OSD(s) found; no bootstrapping will be performed"
            osd_activate
         fi
         ;;
      activate)
         osd_activate
         ;;
      *)
         echo "<usage warning goes here>"
         exit 1
         ;;
   esac

...makes more sense in my current use case.

[Ulexus]

@h0tbird The default is for a different case: providing reasonable defaults. The core point you make here is that you shouldn't have to change "disk" to "activate" after the first run. You want to specify the type and not have to change it?

[h0tbird]

@Ulexus Yes, I could not have said it better. I agree the code above is wrong, in fact a different implementation has been already merged 16add9b. Let me know how you feel about it.

[Ulexus]

@h0tbird Yes, that looks to be perfect.

[Ulexus]

@CoRfr It appears this issue is satisfied. Can you verify?

[leseb]

Closing this for now, feel free to reopen.