=== CyberJacob_ is now known as Guest92403 === Guest92403 is now known as CyberJacob === plars-off_ is now known as plars-off === CyberJacob is now known as Guest20395 === tris- is now known as tris === bruno1 is now known as BrunoR === Makyo is now known as Guest60455 === firl_ is now known as firl === ejat_ is now known as ejat === Guest20395 is now known as CyberJacob [12:34] :q === verterok` is now known as verterok [14:27] how would I go about bootstrapping an LXC environment on a remote node? ie: I can ssh to a remote machine and I want to bootstrap juju with LXC on that machine [14:36] Icey: like using the local provider? [14:36] exactly, but on a remote host (I suppose I can ssh and use local there but I'd rather not have to move all the local dev stuff over) [14:38] jrwren ^^ [14:38] Sometime soon there will be an lxd-provider and it will do what you want very trivially. Right now, I think there is no good answer other than use latest beta release and try lxd-provider. [14:39] Icey: and I'm not sure if lxd-provider is in latest beta. Might need 1.26-alpha release. [14:39] fun -_- [14:39] may just use manual and --to=lxc [14:39] but can't bootstrap to an lxc container that way methinks [14:40] you could do it all manual. manual provider don't know or care that something is lxc. [14:41] yea [14:41] Icey: manual opens up all kinds of crazy situations :) [14:41] oh yeah, and it's buggy as hell ;-) [14:41] coworker and I were using it and discovered how badly most charms clean up after themselves, leaving trash all over the place [14:41] and the leftovers are often files the charm uses to know what's been completed [14:42] most charms don't cleanup after themselves at all. [14:42] nope :-P === JoshStrobl is now known as JoshStrobl|AFK [17:25] rick_h_: was the idea of bundle inheritance phased out with v4? === tvansteenburgh1 is now known as tvansteenburgh [17:27] cc anyone who happens to know [17:30] tvansteenburgh: iirc yes. there were very few bundles in store which used it. [17:30] jrwren: thanks [17:45] wq [17:53] Hello Team, I am writing reactive decorated pattern and i am facing a scenario wherein i have to install some tools as a pre-requisites and i want tat particular LOC to be executed only once. So i have written something like that using @hook pattern http://paste.ubuntu.com/14129704/ while testing unfortunately it is failing. could someone please help me to resolve this or suggest me some alternative method? [18:05] Prabakaran: "it is failing"... can you please be more specific? === jam1 is now known as jam [18:44] tvansteenburgh: yes bundle inheritqnce was moved to the 'new format' work that will turn more intonbundle composition [18:45] tvansteenburgh: as figuring out what bundle you mean from an inheritance list in a file caused issues. [19:00] rick_h_: thanks === JoshStrobl|AFK is now known as JoshStrobl [22:30] hey whats up guys? Is there a best practice for the keeping of secrets other than plain text in the .yaml config files? [22:34] bdx: what kind of secrets? [22:35] marcoceppi: openstack un/pw primarily [22:36] bdx: if you want to avoid putting it in config.yaml. y ou could make it an action [22:36] but actions exist as one off admin tasks and aren't persisted data in the model [22:36] (so if you wanted to export w/t pwd and username, you couldn't) [22:37] marcoceppi: could you elaborate on what the action is? [22:37] or link me :-) [22:37] bdx: https://jujucharms.com/docs/stable/authors-charm-actions [22:39] marcoceppi: oh...I understand those type of actions exist,bu how do they relate to the juju-client config on a per user basis? [22:39] marcoceppi: are you implying to write a wrapper of sorts ? [22:39] bdx: they don't, you could just make an action that takes the user/password to set it [22:41] marcoceppi: I think I see what you are saying... deploy juju-client as a charm on a peruser basis ? [22:41] bdx: no, well, maybe [22:41] I need more context [22:41] what are you trying to do? [22:43] marcoceppi: I have 10 devs, each with his/her own openstack username/password, I am trying to share juju environments amongst us all, but am catching flack bc bad practice of plaintext passwords in the env.yaml files.... [22:45] marcoceppi: from what you said about the action.... "juju deploy juju-client, juju action do juju-client/0 add-juju-user-openstack-user --params pw=somepassword un=someuser" [22:50] marcoceppi: I just found the accesskey and secret key parms for openstack provider.....I think using those should be slightly more diligent. Do you think so? [23:02] marcoceppi: nm^^