[Deepsea-users] Antw: Re: Antw: Re: Integration of DeepSea in a ceph-deploy based installation

Martin Weiss Martin.Weiss at suse.com
Tue Jan 24 00:30:25 MST 2017


How can we verify if the policy.cfg is matching the current deployment without changing anything?
Is there some sort of a "dry-run"?

Regarding DeepSea vs. ceph-deploy - if we are on par or even have more functionality in DeepSea I believe the only thing that we need to add to DeepSea is a "migration method" for existing ceph-deploy based clusters before we can move away from ceph-deploy.
So getting the inventory, building the policy.cfg and then comparing DeepSea with the existing deployment with a "dry-run" would be nice to have "automated" or in a script...
Btw. I do not need a "command line editor for ceph.conf"..

Oh - and we need proper integration of DeepSea into existing Salt deployments i.e. in case the customer has SUSE Manager - DeepSea needs to integrate, there..

Thanks
Martin



On Monday, January 23, 2017 12:25:01 AM Martin Weiss wrote:
> > On Thursday, January 19, 2017 07:40:28 AM Martin Weiss wrote:
> 
> 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 ;-).

To my knowledge, the only two items ceph-deploy does that DeepSea does not is 
support dm-crypt and provide a command line editor of ceph.conf.  The former 
is in the todo list and I am still trying to understand the requirements of 
the latter.

> 
> 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
> > this
> > 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
> 4. ?
> 
> -> 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?
> 
If you did build your policy.cfg identically to the existing environment along 
with centralizing any customized configurations (e.g. ceph.conf, rgw.conf, 
etc.), then nothing would happen.  Running Stage 3 and Stage 4 would check 
that all roles and services are as they should be.

> Thanks,
> Martin
> 
> > Eric
> 
> _______________________________________________
> Deepsea-users mailing list
> Deepsea-users at lists.suse.com
> http://lists.suse.com/mailman/listinfo/deepsea-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/pipermail/deepsea-users/attachments/20170124/a0c258bb/attachment.htm>


More information about the Deepsea-users mailing list