Dear all, I am trying to use cross model relations with Juju in order to add a region to an openstack installation. However it seems to fail.
I have two models (mvp-common and mvp1920) on the same controller and I use the following commands:
Hi Tim,
Currently we have had no progress on this. Due to its relative immaturity we had to postpone using multiple regions with CMR, however we will revert back on this as it seems to heat up again
@timClicks, don’t mean to hijack, but we’re looking at deploying some more OpenStack clusters soon and I’m having a bit of a hard time figuring out what and what isn’t supported with OpenStack and cross model relations. We would like to split up control plane, storage and monitoring. The OpenStack charmers have a few notes about multisite Ceph and Vault in their deployment guide, but that is it.
Perhaps it would be handy to do a run down with them for your upcoming CMR feature highlight?
P.S. Thanks for your great effort here on the Discourse!
Don’t apologise for hijacking the thread. It sounds like there is some common ground between what you and @soumplis are doing anyway. Hopefully there will be some useful knowledge sharing.
Before answering your question, an apology. The CMR documentation is indeed spartan. Sorry for that. Our team’s been without a technical writer for a few months so some critical pieces have not had as much attention as they should have.
I wasn’t involved in the implementation, so my information is not first hand. My understanding is that CMR is considered feature complete and everything should work as expected. If you are able to relate two applications in the same model, then they should be able to be related via a cross-model scenario also.
If you find something odd - please take the time to raise a question here and/or file a bug report.
I’m not able to speak authoritatively on how to deploy OpenStack. @beisner may have some suggestions about who is best placed to say a) if that’s a good idea and b) if they have any advice on how to make it happen.
Absolutely. That sounds like a great idea. I’ll send an email or two around.
By the way, I’m hoping that those feature highlights that I’m experimenting with become the kernel of material that is “CIO ready”. At the moment, I can see a bit of a gap for material about Juju that’s tailored for people wanting to sell Juju internally at their workplace.
Thanks for the thanks! It’s nice to see that people are noticing the work that our team is putting in outside of the code. We really want to create a forum that users enjoy coming back to.
One thing of note is that the OpenStack team has been working to make sure charms work in a CMR context this cycle. One of the big gates and tests for them is that Juju added support for CMR in bundles for 2.7 (coming soon) and so they’ve not been able to do a ton of validation/testing before that feature.
I know there were specific charms that were targets to make sure they’re updated and content in a CMR world (vault, keystone, not sure on others) and so it would be good to make sure to try the most up to date charms you can. There are changes that need to occur like charms leveraging network-get to identify network information in relation contexts and the like.
For the original post here, it’d be good to know what “fails”. The log file doesn’t have anything that appears to be error/etc and I’m not following what the issue after the relation kicks in exactly.
Unfortunately those models where used as a proof of concept and now are not available any more, so the original question can now be considered obsolete
@rick_h, that is great to hear! Really looking forward to try it out with 2.7 with defined bundles. I hope there will be some good examples in the OpenStack charm release notes or deployment guide.
Hi @szeestraten, supported CMR scenarios with Charmed OpenStack are evaluated on a case-by-case basis. This is documented in the OpenStack Charm Guide. HTH.
