Tuning ceph

[Pshem Kowalczyk]

Hi,

In this particular case I just want to make sure that my settings for CRUSH
are used for various pools and be able to define my own pools (see below).

I'm trying to create two different pools for both nova-compute and
cinder-ceph (one with SSDs the other with spinning drives). I have managed
to create another 'local storage' (lvm based) cinder instance (and that
works fine with volume-type). But I'm completely unsure as how to keep one
ceph instance with different types of pools for cinder. At this stage
doesn't look like the cinder (or cinder-ceph) charm  allows you to specify
the pool to use (it allows for one for volume-group for local LVM). For the
nova-compute I'm basing the setup on is here:
https://ceph.com/planet/openstack-nova-configure-multiple-ceph-backends-on-one-hypervisor/
(which
requires for a single nova-compute charm to be aware of 2 pools). The
second one is probably less important since I (probably, not tried that
yet) create deploy two nova-compute charms with different rbd-pool settings
and point back to the same ceph charm.

kind regards
Pshem



On Thu, 26 Nov 2015 at 10:07 Billy Olsen <billy.olsen at canonical.com> wrote:

> Pshem,
>
> If you have specific use cases around the setting of config options,
> please do share. The charms tend to be opinionated about configuration and
> make it simple to deploy the majority of installations. However, there will
> undoubtedly be config tweaks here and there. Your use cases can help ensure
> we are attempting to cover your needs.
>
>
> Thanks,
>
> Billy
>
>
> On Wednesday, November 25, 2015, Pshem Kowalczyk <pshem.k at gmail.com>
> wrote:
>
>> Hi,
>>
>> Yes, I got the the same conclusion, either write my own charms to try to
>> get the features implemented upstream.
>>
>> In a way I think that having some sort of local 'overlay' for the hooks
>> (that get's applied automatically, but doesn't modify the original charms)
>> would make the things easier.
>>
>> At this stage the juju ecosystem, despite being quite flexible is not
>> really conductive to external changes. It's pretty much an all-or-nothing
>> approach. It works for well for most deployments, but not when you want to
>> fine-tune (the relatively complex stuff). I do wonder how much need there
>> really is for this fine tuning of the charms, perhaps it's just me ;-)
>>
>> kind regards
>> Pshem
>>
>>
>> On Thu, 26 Nov 2015 at 09:34 Peter Sabaini <peter.sabaini at canonical.com>
>> wrote:
>>
>>> On 25.11.15 21:29, Pshem Kowalczyk wrote:
>>> > Right,
>>> >
>>> > How to you make sure that juju doesn't override my changes? If I had to
>>> > add another mon node (and remove one of the existing ones) the new
>>> > config would be overwritten by the default one.
>>> >
>>> > I think the general issue is that I can't tell when particular config
>>> > files will be re-generated.
>>>
>>> Indeed, that only lends itself for configuration outside of the charms'
>>> control. If however you're getting an overlap by a juju-managed config
>>> file your only options are a) get the needed parameter included
>>> upstream or b) fork the charm
>>>
>>> cheers,
>>> peter.
>>>
>>>
>>>
>>> >
>>> > kind regards
>>> > Pshem
>>> >
>>> >
>>> > On Wed, 25 Nov 2015 at 21:58 Peter Sabaini <
>>> peter.sabaini at canonical.com
>>> > <mailto:peter.sabaini at canonical.com>> wrote:
>>> >
>>> >     On 24.11.15 23:25, Pshem Kowalczyk wrote:
>>> >     > Hi,
>>> >     >
>>> >     > I'm relatively new to the juju ecosystem. I've built a test/POC
>>> >     > openstack setup using juju charms. Ceph is used as the
>>> >     backend-storage
>>> >     > system for the deployment. Since the production deployment of
>>> this
>>> >     > system has to meet some external requirements (particular CRUSH
>>> >     > settings, recovery times etc) I'll have to tune ceph settings a
>>> bit.
>>> >     >
>>> >     > The charm itself doesn't seem to have a section to add that
>>> >     information
>>> >     > (some other charms do have that ability). What's the best way of
>>> >     doing it?
>>> >     >
>>> >     > In general case, I've realised that sometimes it would be useful
>>> to
>>> >     > have ability to run some actions after juju has finished its
>>> >     > configuration to fine-tune it to particular requirements (without
>>> >     > losing the advantages of using juju for all the dependencies).
>>> Is it
>>> >     > possible to do something like that without building my own
>>> charms?
>>> >
>>> >     We're generally just using "juju ssh", "juju run" and occasionally
>>> >     "juju scp"
>>> >
>>> >     Caveat: juju ssh doesn't really handle stdin
>>> >
>>> >     cheers,
>>> >     peter.
>>> >
>>> >     > kind regards
>>> >     > Pshem
>>> >     >
>>> >     >
>>> >     >
>>> >
>>> >
>>> >     --
>>> >     Juju mailing list
>>> >     Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>>> >     Modify settings or unsubscribe at:
>>> >     https://lists.ubuntu.com/mailman/listinfo/juju
>>> >
>>>
>>>
>>>
>
> --
> Billy Olsen
>
> billy.olsen at canonical.com
> Software Engineer
> Canonical USA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151126/85cd3ad3/attachment.html>