[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