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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 < >>> [email protected] >>> > <mailto:[email protected]>> 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 >>> > [email protected] <mailto:[email protected]> >>> > Modify settings or unsubscribe at: >>> > https://lists.ubuntu.com/mailman/listinfo/juju >>> > >>> >>> >>> > > -- > Billy Olsen > > [email protected] > Software Engineer > Canonical USA > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
