[00:53] <mskalka> Anyone have advice for passing json or json like objects into charm actions as params?
[05:58] <pranav_> Hi Folks. How do I install charms specific to Openstack Ocata release?
[05:59] <pranav_> The current charms are for mitaka release
[06:49] <viswesn> I created a new dummy-subordinate charm for dummy-sink charm
[06:49] <viswesn> and I am seeing the message status as " Waiting for token" for dummy-sink on running "juju add-relation dummy-sink dummy-subordinate"
[06:50] <viswesn> Is there anything that I need to do to make sure that dummy-sink is "Started"
[08:06] <kjackal> Good morning Juju world
[08:10] <kjackal> Hi viswesn I guess you are seing the msg from here: https://api.jujucharms.com/charmstore/v5/~juju-qa/xenial/dummy-sink-0/archive/hooks/source-relation-changed
[08:10] <viswesn> @kjackal - It is resolved now :)
[08:10] <kjackal> ah great!
[08:11] <viswesn> Thanks kjackal
[08:41] <zeestrat> pranav_: I'm pretty sure Ocata charms are still in their "next" channel in https://jujucharms.com/u/openstack-charmers-next/. See also this proposal for a new bundle for Ocata here: https://github.com/openstack-charmers/openstack-bundles/pull/17.
[08:41] <zeestrat> pranav_: But please check with the guys in #openstack-charms to make sure.
[09:05] <Zic> hi Juju World
[11:19] <kklimonda> hi guys, are charms compatible with both juju 1.25 and 2.0?
[12:29] <admcleod_> kklimonda: they should be
[13:45] <narindergupta>  morning
[15:30] <marcoceppi> stokachu: sos, conjure-up won't let me configure clouds with latest classic snap from beta channel
[15:31] <marcoceppi> it only ever gives me localhost and not my existing maas
[15:31] <marcoceppi> stokachu: it's also stacktracing if I try localhost
[17:16] <fs> هستی؟
[17:16] <ir> آره
[17:17] <fs> این لیستی که این یغل هست همه آدمن؟
[17:48] <mmcc> marcoceppi - were you trying this with the openstack-novalxd spell? that is restricted to only running on localhost intentionally. I can see how that'd be confusing, since there isn't good feedback on that in the UI currently. I've filed https://github.com/conjure-up/conjure-up/issues/666 to track improving that.
[17:50] <mmcc> marcoceppi - were you trying this with the openstack-novalxd spell? that is restricted to only running on localhost intentionally. I can see how that'd be confusing, since there isn't good feedback on that in the UI currently. I've filed https://github.com/conjure-up/conjure-up/issues/666 to track improving that.
[17:50] <mmcc> sorry if I just posted that 3 times, having irc bouncer issues
[18:17] <vila> mmcc: and a devilish issue number, don't search further ;-)
[18:18] <mmcc> vila :)
[18:48] <marcoceppi> mmcc: it also failed on localhost
[18:48] <marcoceppi> mmcc: but why limit it to localhost? It should work fine on maas?
[18:49] <mmcc> marcoceppi: it's targeted at deploying into LXD containers. if you deployed that bundle on maas, you'd use ~13 full machines
[18:49] <mmcc> the intent is that if you want to deploy openstack onto maas you should use the other openstack spell
[18:50] <mmcc> which crams those services into ~4 machines IIRC
[18:50] <marcoceppi> mmcc: there is no nova-lxd spell though
[18:50] <marcoceppi> other than localhost
[18:51] <marcoceppi> mmcc: seems the spell should choose a different bundle based on cloud selected
[18:51] <marcoceppi> I want OpenStack NovaLXD, I don't care about the nuainces between maas or lxd
[18:51] <stormmore> is it possible to have different models on a controller to be different clouds? e.g. local and maas?
[18:51] <marcoceppi> I also don't see why four lxd machines with more lxd machines inside that is a bad thing, lxd supports fully nested machines
[18:52] <mmcc> marcoceppi: it's not nested. there are no placement directives in the bundle
[18:52] <marcoceppi> stormmore: technically, yes, however those models would both need to have networking between them
[18:52] <marcoceppi> mmcc: I'm saying you could do nested still, instead of an exploded 13 machine lxd bundle
[18:52] <marcoceppi> stormmore: we see people do this a lot with regional models, I don't think we support cross cloud models atm
[18:52] <stormmore> marcoceppi that is the plan :) I need to build a minimal offline cluster
[18:53] <stormmore> marcoceppi thinking about making one machine the master / client running all the "master" services including MaaS rack/region and then just have worker nodes boot to it
[18:54] <stormmore> potentially make it a top of rack design / data center bootstrap system too
[18:55] <mmcc> marcoceppi: I agree that the current spell organization for openstack isn't ideal. We'll have a discussion about how we can make it clearer and easier to deploy openstack using novalxd onto maas
[18:56] <marcoceppi> mmcc: seems like the bundle keyword in the spell could be either a string or dictionary of cloud: bundle-url for arcitectures which diverge based on cloud backend
[18:57] <mmcc> fwiw, I think the way you'd do it with current spells is to pick the openstack-base spell and change the virt-type option in nova-compute to lxd
[18:57] <mmcc> not sure off the top of my head if that's all though
[18:57] <marcoceppi> mmcc: you need the LXD charm as well
[18:57] <mmcc> ah ok
[18:57] <marcoceppi> mmcc: https://jujucharms.com/u/openstack-charmers-next/openstack-lxd/
[18:58] <marcoceppi> though, that bundle doesn't deploy cleanly yet, if you change two (outdated) config options it will
[18:59] <stormmore> The only other way I was thinking which would be better in some ways it figuring out how to register the maas region/rack controller with maas and add juju controller to it too - this would be the ideal method
[19:01] <mmcc> marcoceppi: having a cloud: bundle mapping inside a spell isn't a bad idea. it complicates some of the other parts of spells, so there's a tradeoff. the simplest thing would be to just have additional spells and keep the 1:1 spell:bundle relationship. I'll file an issue to track discussion
[19:04] <stormmore> OK now I have a crazy idea forming in my head that begs to be tested
[19:05] <mmcc> marcoceppi: here's that issue https://github.com/conjure-up/spells/issues/46
[19:05] <mmcc> thanks for the feedback!
[19:14] <beisner> hey marcoceppi - yeah that dev bundle isn't quite in sync with the dev charms atm.  but if you have to adjust on the non-next/dev bundle, please raise that as a bug.
[20:56] <marcoceppi> beisner: I will, it was just two config options that were no longer there, easy enough
[20:58] <beisner> thx marcoceppi, but if against the -next bundle, don't sweat it, we've got updates in flight for those.
[20:59] <marcoceppi> beisner: cheers
[21:59] <skayskay> stub: hey, are you around? I started seeing this failure yesterday with the postgresql charm. https://paste.ubuntu.com/23963015/
[22:00] <skayskay> I'm in a bootstrapped juju1 environment, and can reproduce it by running: juju deploy postgresql
[22:20] <skayskay> basically I think squashfuse is not in a trusty repo
[22:34] <infinityplusb> ahoy. If I am writing a charm, is there any way to pull a file from my host filesystem, rather than having to host it, while I am testing
[22:34] <infinityplusb> I am deploying using lxd
[22:51] <stokachu> infinityplusb, other than juju scp there isn't a way within the charm
[22:51] <stokachu> infinityplusb, you can use resources if you want