[Deepsea-users] Antw: Re: Integration of DeepSea in a ceph-deploy based installation
Martin.Weiss at suse.com
Mon Jan 23 00:25:01 MST 2017
> On Thursday, January 19, 2017 07:40:28 AM Martin Weiss wrote:
>> Hi *,
>> in case I want to add DeepSea to an existing SES deployment ‑ how can I do
>> that without "destroying" or "changing" or "re‑deploying" anything in the
>> existing cluster? (in case that is already possible)
> Hi Martin,
> I have not gone down this path yet. Technically, you can run Stage 1
> without causing any harm to your existing cluster. It's running a discovery
> and only writing files to the master. The next step would be the issue.
> How comfortable do you feel in creating a policy.cfg that matches the
> existing environment?
What about enhancing deepsea with creating the policy.cfg automatically?
In case I want to integrated deepsea into an existing environment - I believe this is a must have..
> This also implies verifying/creating/selecting the
> hardware profile for the various storage nodes. For a simple cluster of
> alone OSDs and a ceph cluster of only monitors and mds, you could quite
> literally be done in minutes.
Not enough knowledge and experience so far - and I am not sure what might happen in case there is a mistake in the policy.cfg..
> For a cluster of separate journals and other additional services such as
> iSCSI or RGW, you would need to roll up your sleeves. At this point, if you
> have such a cluster, I do not think it would be worth your time. This is
> harder task of accurately recording all the data and journal devices as well
> as centralizing configurations back onto the Salt master.
I have heard that we want to deprecate ceph-deploy in one of the next releases and replace it with deepsea.
With that in mind I believe we have to deliver a migration path from "ceph-deploy" to "deepsea"..
Ad yes - I agree - at the moment where deepsea is not yet on paar with ceph-deploy this might not be worth the effort...
But we need to start building the proper solution before deprecating ceph-deploy ;-).
Oh - and btw. - this would also be an added value for customers migrating from NON SLES bases Ceph deployments to SES..
> What happens if you try and something goes wrong? I don't know. My
> personal paranoia level would be high enough that I would skip using any of
> the stage orchestration commands (i.e. salt‑run state.orch ceph.stage.3) and
> run the individual steps on the individual nodes. It would be a bit tedious
> for a migration, but much easier to recover.
Agreed - this adds to my wish of an automatically generated policy.cfg for an existing cluster.
> In the longer term, we do have an existing card in
> https://github.com/SUSE/DeepSea/projects/2, but have not pursued it yet. I
> think the above would need to be automated for creating a policy.cfg with
> accurate hardware profiles and somehow verifiable. Also, I do not know if
> could be a generic solution for any Ceph cluster.
So for the moment I understand this status:
1. Recommendation: Do not use DeepSea for existing ceph-deploy based clusters.
2. Inventory can be done with DeepSea
3. policy.cfg can be created manually
-> In case I build the policy.cfg manually and correct - what would happen if I go through the next steps of DeepSea, then? Will this kill / overwrite anything already existing?
More information about the Deepsea-users