[00:28] <jose> jacekn: ping
[08:33] <niedbalski> good morning eco's
[14:12] <fali> Hello. I installed juju-gui on machine0. Worked fine, but I get the following error message in the web browser: "Charm API server did not respond". Can't find that anyone else has this problem, so trying here.
[14:12] <fali> I can't find anything in the logs, and the juju.conf file shows the correct proxy settings.
[14:13] <avoine> fali: juju-gui use websockets does your proxy allow that?
[14:16] <fali> avoine: Don't know, but I doubt it... Will check. Is there any workaround if it's not allowed?
[14:17] <avoine> fali: I was using nginx an I had to upgrate to a newer version and follow this: http://nginx.org/en/docs/http/websocket.html
[14:20] <avoine> fali: if you use a browser inspector in the network tab you should see the error for the websocket request (one every seconds I think)
[14:35] <fali> avoine: seems like our corporate proxy won't let us through. I have no possibility to change that :( Is it possible to run juju-gui locally? downloading what we need, then use our own Charm API server?
[14:41] <avoine> fali: yes, you could install it by checking what the charm is doing but I'm not sure if juju-gui is using websocket for his communication
[14:41] <avoine> like getting charms from the charm store for example
[14:45] <avoine> fali: I'm looking at the code and I looks like it's the case so it won't work.
[14:45] <avoine> https://github.com/juju/juju-gui/blob/develop/app/config-prod.js#L36
[14:46] <avoine> maybe you can change the socket_protocol variable tought
[14:54] <fali> avoine: Ok. First I'll try finding a proxy that is a bit more cooperative. Thank you so much for your input.
[14:54] <avoine> fali: np, good luck
[15:04] <breze441> Trying to add netapp nfs share in to cinder . how do i paass the netapp info in to cinder via juju ? it appears manual config on cinder.conf get overwritten by juju
[15:37] <breze441> sorry to repeat but just wondering if anyone knows how to pass netapp config to cinder via juju
[15:48] <jcw4> breze441: what charms are you using?
[15:49] <jcw4> breze441: I assume cinder
[15:49] <jcw4> breze441: is there a charm for netapp?
[15:50] <breze441> no charm for netapp, i was trying to follwo the steps for RDO packstack by editing the cinder.conf but it get overwritten by the juju during cinder restart
[15:51] <breze441> i am assuming the same parameters should be able pass via juju cli to cinder
[15:52] <jcw4> breze441: hmm
[15:53] <jcw4> breze441: so you're doing 'juju deploy --config=cinder.conf cinder', but when cinder restarts it overwrites the cinder.conf file ?
[15:53] <jcw4> breze441: I mean juju overwrites cinder.conf when the cinder service restarts?
[15:56] <breze441> when i deployed i didnt have these netapp configs in the config file . so i go and edit the file with configs netapp recommends to use. to complete the process i have to do a stop jujud-cinder follwed by a start jujud-cinder where i lose the netapp configs. Now if i know how to send them when deploying i dont have to edit the configs
[15:57] <jcw4> breze441: I see that makes sense
[15:57] <jcw4> breze441: so if you edit the config after deploying, juju doesn't know about it and overwrites the config file...
[15:58] <jcw4> breze441: you want to know how to tell juju about the config settings so that juju doesn't overwrite it?
[16:07] <breze441> exactly, maybe there is a way to pass these information when o deploy.
[16:08] <breze441> on side note, is it possible to change conf files deployed with Juju ?
[16:09] <jcw4> breze441: I'm doing a little research to see if I can answer that; I don't really know much about it but I hope to get the people who do involved :)
[16:10] <breze441> much appreciated
[16:20] <lazyPower> breze441: thats dependent on how the charm is implemented. Idempotency dictates if you've made changes to a config file vs what the charm expects, it should update it.
[16:20] <jcw4> lazyPower, breze441 when you say edit the config... did you edit it in the charm directory or on the unit where it's deployed?  lazyPower does that make a difference?
[16:21] <lazyPower> breze441: is a charm you're deploying not exposing a configuration set? If thats the case there are 2 options here. 1) you can file a bug against the charm to see if the maintainer deems this missing behavior - or 2) you can fork the charm and implement the configuration file changes you need and track upstream by backporting patches as they are released.
[16:22] <jcw4> breze441: this is the charm right? https://github.com/charms/cinder
[16:22] <lazyPower> jcw4: When you edit a charm on the server, any edits will be blown away on the next upgrade of the charm - if you edit the config file manually - each run will blow your changes away. its all about idempotency. If it's already taken the action, and there's no delta on the files - it shouldn't execute. If it's got modifications, the charm should assume it requires an update and use the templated config.
[16:22] <jcw4> lazyPower: that makes sense to me, so you should edit the template if you want it to remain?
[16:23] <lazyPower> so you're better off to fetch the charm locally, and make the required modifications - and if deemed necessary, submit a patch back against the charm so everyone benefits.
[16:23] <lazyPower> Yep
[16:23] <breze441> so i edited the cinder.conf on the node *not the charm*
[16:23] <lazyPower> that or make it configurable.
[16:24] <jcw4> lazyPower: I see.  I think the specific config that breze441 is changing is not specific to cinder, it's actually specific to netapp
[16:25] <jcw4> is that right breze441 ?
[16:26] <jcw4> so I'm assuming breze441 would edit the charm template locally, but wouldn't propose it be merged back into the charm
[16:27] <lazyPower> that would be my suggestion - it will be prudent to make sure you subscribe to the upstream charm's launchpad repository so you're aware when updates are published so you can backport them to your local charm deployment
[16:27] <breze441> well there are few lines of config specific to netapp i need to add to the cinder.conf to load netapp drivers
[16:27] <lazyPower> thast the downside to forking a charm - you lose automatic upgradeability, it becomes a required manual step - its really simple, but takes away a dash of taht 'magic' juju brings to the table.
[16:28] <breze441> well the drivers are in upstream its just pointing the ip address of the netapp filer and credentials etc..
[16:28] <lazyPower> so ideally if everyone would benefit from loading netapp drivers - i'd propose a merge and see where it goes.
[16:28] <lazyPower> the worst that will happen is they say no
[16:28] <lazyPower> in which case you're no worse off than when you started, and *then* you walk down the path of maintaining a forked charm.
[16:32] <breze441> any any pointers on how to edit the cinder charm ?
[16:34] <lazyPower> do you have charm-tools installed?
[16:34] <breze441> sync-tools ? if so yes
[16:34] <lazyPower> sudo apt-get install charm-tools
[16:35] <lazyPower> mkdir -p ~/charms/<series> && cd ~/charms/<series> && charm get cs:<series>/cinder
[16:35] <lazyPower> then when you're ready to test your revisions: juju deploy --repository=$HOME/charms local:<series>/cinder mycinder
[16:36] <lazyPower> the cinder charm is in python, has unit tests, and is extremely well covered in terms of code quality - so  you should have a good foundation to work off of. Our OpenStack charms are stellar examples of charms.
[16:37] <breze441> ok Thank you let me give it a shot
[16:38] <lazyPower> np, if you get stuck dont hesitate to ask :)
[17:32] <jose> jacekn: ping
[20:11] <revagomes> Hi mates! Can anyone give me a hint about the connection refused error when trying to run juju status? When I ran juju status --debug -v I've got the following message: "DEBUG juju.state.api apiclient.go:248 error dialing "wss://localhost:17070/", will retry: websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused"
[20:14] <revagomes> I can ssh the service by hand but when I tried running "juju ssh [service]" it doesn't work The juju log shows
[20:15] <revagomes> that it's trying to start the api and dialing "wss://[...]" but thr connection is refused
[20:17] <marcoceppi> revagomes: is this local provider?
[20:18] <revagomes> marcoceppi, yep
[20:18] <marcoceppi> revagomes: run `sudo initctl list | grep juju` what does it say?
[20:18] <revagomes> I was using juju v1.20 but I already upgraded to 1.20.1
[20:19] <revagomes> juju-agent-revagomes-local stop/waiting
[20:19] <revagomes> juju-db-revagomes-local stop/waiting
[20:19] <marcoceppi> revagomes: run
[20:19] <marcoceppi> sudo start juju-db-revagomes-local
[20:19] <marcoceppi> sudo start juju-agent-revagomes-local
[20:20] <marcoceppi> revagomes: then do the list command again and make sure both are started
[20:22] <revagomes> The processes are running now. Perfect! The juju status and other commands are working now. ;)
[20:22] <revagomes> marcoceppi++
[20:22] <revagomes> marcoceppi, I have to start the processes by hand or it's was a bug from the 1.20 version?
[20:23] <marcoceppi> revagomes: this happens if you restarted the computer typically
[20:24] <sebas5384> revagomes: \o/
[20:25] <revagomes> marcoceppi, I got it. So to set juju processes to run on startup seems a good way to prevent this next time ;)
[20:25] <revagomes> marcoceppi, tks!
[20:25] <marcoceppi> revagomes: we did this a while ago
[20:25] <marcoceppi> people complained about it
[20:25] <sebas5384> thanks marcoceppi! revagomes is starting to use juju these days with us :)
[20:26] <marcoceppi> revagomes: we're building a "local" command, so in the future you can just do `juju local start` or `juju local suspend` etc to safely turn off/on local provider and recover from a state
[20:26] <marcoceppi> sebas5384: great to hear!
[20:26] <sebas5384> marcoceppi: that would be great! a start and stop
[20:26] <revagomes> awesome!