[00:53] Anyone have advice for passing json or json like objects into charm actions as params? [05:58] Hi Folks. How do I install charms specific to Openstack Ocata release? [05:59] The current charms are for mitaka release === Lukewh_ is now known as Lukewh === wolsen_ is now known as wolsen === skayskayskay_ is now known as skayskayskay === mpontillo_ is now known as mpontillo === thomi_ is now known as thomi [06:49] I created a new dummy-subordinate charm for dummy-sink charm [06:49] 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] Is there anything that I need to do to make sure that dummy-sink is "Started" === Dmitrii-Sh_ is now known as Dmitrii-Sh === frankban|afk is now known as frankban [08:06] Good morning Juju world [08:10] 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] @kjackal - It is resolved now :) [08:10] ah great! [08:11] Thanks kjackal [08:41] 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] pranav_: But please check with the guys in #openstack-charms to make sure. [09:05] hi Juju World === frankban is now known as frankban|afk [11:19] hi guys, are charms compatible with both juju 1.25 and 2.0? === frankban|afk is now known as frankban [12:29] kklimonda: they should be === admcleod_ is now known as admcleod [13:45] morning [15:30] stokachu: sos, conjure-up won't let me configure clouds with latest classic snap from beta channel [15:31] it only ever gives me localhost and not my existing maas [15:31] stokachu: it's also stacktracing if I try localhost === verterok` is now known as verterok === skayskayskay is now known as skayskay [17:16] هستی؟ [17:16] آره [17:17] این لیستی که این یغل هست همه آدمن؟ [17:48] 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] 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] sorry if I just posted that 3 times, having irc bouncer issues [18:17] mmcc: and a devilish issue number, don't search further ;-) [18:18] vila :) [18:48] mmcc: it also failed on localhost [18:48] mmcc: but why limit it to localhost? It should work fine on maas? [18:49] marcoceppi: it's targeted at deploying into LXD containers. if you deployed that bundle on maas, you'd use ~13 full machines [18:49] the intent is that if you want to deploy openstack onto maas you should use the other openstack spell [18:50] which crams those services into ~4 machines IIRC [18:50] mmcc: there is no nova-lxd spell though [18:50] other than localhost [18:51] mmcc: seems the spell should choose a different bundle based on cloud selected [18:51] I want OpenStack NovaLXD, I don't care about the nuainces between maas or lxd [18:51] is it possible to have different models on a controller to be different clouds? e.g. local and maas? [18:51] 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] marcoceppi: it's not nested. there are no placement directives in the bundle [18:52] stormmore: technically, yes, however those models would both need to have networking between them [18:52] mmcc: I'm saying you could do nested still, instead of an exploded 13 machine lxd bundle [18:52] stormmore: we see people do this a lot with regional models, I don't think we support cross cloud models atm [18:52] marcoceppi that is the plan :) I need to build a minimal offline cluster [18:53] 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] potentially make it a top of rack design / data center bootstrap system too [18:55] 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] 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] 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] not sure off the top of my head if that's all though [18:57] mmcc: you need the LXD charm as well [18:57] ah ok [18:57] mmcc: https://jujucharms.com/u/openstack-charmers-next/openstack-lxd/ [18:58] though, that bundle doesn't deploy cleanly yet, if you change two (outdated) config options it will [18:59] 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] 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] OK now I have a crazy idea forming in my head that begs to be tested [19:05] marcoceppi: here's that issue https://github.com/conjure-up/spells/issues/46 [19:05] thanks for the feedback! [19:14] 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. === frankban is now known as frankban|afk [20:56] beisner: I will, it was just two config options that were no longer there, easy enough [20:58] thx marcoceppi, but if against the -next bundle, don't sweat it, we've got updates in flight for those. [20:59] beisner: cheers === frankban|afk is now known as frankban [21:59] stub: hey, are you around? I started seeing this failure yesterday with the postgresql charm. https://paste.ubuntu.com/23963015/ [22:00] I'm in a bootstrapped juju1 environment, and can reproduce it by running: juju deploy postgresql [22:20] basically I think squashfuse is not in a trusty repo [22:34] 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] I am deploying using lxd [22:51] infinityplusb, other than juju scp there isn't a way within the charm [22:51] infinityplusb, you can use resources if you want === frankban is now known as frankban|afk