[00:55] <Crypticus> anyone know how to make the juju-gui bind to all interfaces?
[00:55] <Crypticus> or just change which interface it binds too?
[01:18] <rick_h_> Crypticus: it's not something exposed in the charm atm.
[01:19] <rick_h_> Crypticus: we'd welcome a bug on that if you have a need on that, but typically there's just the one public IP in question when you deploy the charm.
[01:19] <Crypticus> rick_h_, turns out... it is by default
[01:19] <rick_h_> Crypticus: I'd love to hear what you're up to and how we can help
[01:19] <rick_h_> Crypticus: oh, then even better heh
[01:19] <Crypticus> I thought that was the issue but it looks like an external network issue
[01:19] <rick_h_> I know we've added custom port but nothing on custom network interface
[01:20] <rick_h_> Crypticus: cool, then glad to hear we've got you covered
[01:20] <Crypticus> Well I am trying to install OpenStack with Juju using LXC.
[01:20] <Crypticus> I am using the manual provider because the openstack-installer way doesn't seem to make a usable deployment
[01:20] <Crypticus> So far so good.
[01:21] <rick_h_> Crypticus: hmm, yea the one I know that the folks have been working on is this one: https://jujucharms.com/openstack/ but that's more maas/bare metal I think than lxc
[01:22] <Crypticus> I got 10 LXC containers on a HP Proliant Gen9 I used the download ubuntu template, installed openssh-sever and dbus and configured my network to use a macvlan bridge for external access and the veth for internal communication
[01:23] <rick_h_> sounds like a party :)
[01:23] <Crypticus> just got juju to bootstrap and got the gui installed on machine 0.  Couldn't figure out why my windows machine couldn't access th GUI but turns out my IT has something screwed up in the DNS.
[01:24] <Crypticus> rick_h_, thanks for offering to help
[01:24] <Crypticus> This is a lot of fun... but there is a lot of magic in the juju and it's hard to debug still
[01:25] <Crypticus> rick_h_, could you tell me how to restart the juju gui, I just changed my environment.yaml to include an admin-secret and I'm hoping that will let me login with a more rememberable password
[01:26] <Crypticus> My thought is to do juju ssh 0 and restart manually service juju-gui, but I assume that will not get the new password
[01:29] <rick_h_> Crypticus: hmm, the environments.yaml isn't read once things are bootstrapped. I'm actually not sure how you'd change that up as it's alive in the environment at this point.
[01:29] <rick_h_> think of it like a template used to create a document, changing the template doesn't update the documents you've already created
[01:30] <Crypticus> rick_h_, OK... well I am going to destroy and redeploy the service and see if that works, if not... more digging
[01:30] <Crypticus> wish the docs mentioned this upfront
[01:30] <rick_h_> Crypticus: well it's the admin password of the environment
[01:30] <rick_h_> so just redeploying the GUI won't do much
[01:31] <rick_h_> thumper: any way to update admin-secret of an already running env?
[01:31] <rick_h_> ^
[01:31] <thumper> hey
[01:32]  * thumper thinks
[01:32] <thumper> well
[01:32] <thumper> how about you tell me what you are wanting to do...
[01:32] <thumper> admin secret has many initial masters
[01:32] <Crypticus> how about changing .juju/environments/manual.jenv
[01:32] <Crypticus> then redeploying?
[01:32] <rick_h_> thumper: after bootstrap, change the admin-secret so the gui will let me login with a shorter or more memorable password
[01:32] <thumper> sure
[01:32] <Crypticus> Trying to change the admin-secrete
[01:32] <thumper> juju user change-password
[01:32] <Crypticus> LOL
[01:33] <Crypticus> nice
[01:33] <rick_h_> well there you go then :)
[01:33] <rick_h_> thumper: that's in 1.21?
[01:33] <thumper> um...
[01:33] <Crypticus> I figured it must be something easy... but how do you find these commands?
[01:33] <rick_h_> Crypticus: just to check what version of juju you're running
[01:33] <thumper> let me look
[01:33] <thumper> yep
[01:33] <thumper> juju help commands
[01:33] <thumper> juju help user
[01:34] <thumper> help FTW
[01:34] <thumper> rick_h_: now, for the record
[01:34] <thumper> we aren't changing admin-secret
[01:34] <Crypticus> OK... did that... but did think to look for user... I was looking how to restart a service... didn't find that
[01:35] <thumper> what we are changing is the user password for the admin user
[01:35] <Crypticus> thanks a lot thumper and rick_h_
[01:35] <thumper> Crypticus: np
[01:35] <thumper> admin-secret is still used by the state server machine agent to talk to mongo
[01:35] <thumper> I think
[01:36] <thumper> Crypticus: services are kinda etherial
[01:36] <thumper> Crypticus: you restart units not services
[01:36] <thumper> or machines
[01:36] <Crypticus> hrm... OK
[01:36] <Crypticus> cool
[01:36] <thumper> units are instances of a service
[01:36] <rick_h_> thumper: yea, gotcha
[01:37] <rick_h_> thumper: but since we support user/login now I think it should work out ok
[01:37]  * thumper nods
[01:37] <thumper> should do
[01:37] <thumper> now I can soon land my patch that changes the initial user from 'admin' to the logged in user
[01:37] <rick_h_> ooooh, that's going to mess up the world lol
[01:37] <thumper> rick_h_: will the gui / quickstart handle that
[01:38] <Crypticus> well thanks so much guys... I can't wait to document all this I think it's going to help some people that need to test openstack in a really lightweight manner (LXC)
[01:38] <thumper> np
[01:38] <thumper> Crypticus: good luck
[01:38] <rick_h_> thumper: yea, I think we'll be ok. The big thing is just a ton of docs, blogs, history around that admin user
[01:38] <thumper> yeah
[01:38]  * rick_h_ wonders how many scripts have that hard coded in ops/etc
[01:39] <rick_h_> thumper: also I thought-dumped in your JES doc
[01:39] <rick_h_> hopefully useful or not, let me know if we want to chat/walk through stuff as we've got a few steps to get where you're headed I think and now that the code/etc is real I'm nervous about a couple of bits
[01:43] <thumper> rick_h_: sure... did you want to chat now or start of next week?
[01:43] <thumper> rick_h_: we are right up against implementing this
[01:43] <thumper> rick_h_: but I wanted to get it written down and agreed on
[01:43] <rick_h_> thumper: I can do my best now if that's helpful
[01:43] <rick_h_> or start of next week can also work
[01:43] <thumper> quick iteration on the doc is faster than rewriting code
[01:43] <thumper> lets chat now
[01:43] <rick_h_> rgr
[02:35] <nicopace> hi guys, i'm having a problem with amulet
[02:36] <nicopace> when i do:
[02:36] <nicopace> logstash_indexer_agent = d.sentry.unit['logstash-indexer/0']
[02:36] <nicopace> curl_response = logstash_indexer_agent.run("curl http://127.0.0.1:9200/index/_search?size=1")[0]
[02:36] <nicopace> print(curl_response)
[02:37] <nicopace> the output says: http://paste.ubuntu.com/10197382/
[02:37] <nicopace> (ssh: REMOTE HOST IDENTIFICATION HAS CHANGED)
[02:38] <sarnold> hah, love that it appears something tries to execute the results of the ssh output.
[02:39] <nicopace> but it shouldn't
[02:40] <nicopace> i've been implementing tests for almost 2 months with this methodology
[02:40] <nicopace> and this is the first time it happens
[02:40] <nicopace> any idea what could it be sarnold?
[02:41] <nicopace> i've found a similar error in a bug that is already patched (1 year ago) here: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1283198
[02:41] <mup> Bug #1283198: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED <airline> <Ubuntu CI Services:Fix Released by doanac> <Ubuntu CI Engine:Fix Released by doanac> <https://launchpad.net/bugs/1283198>
[02:42] <sarnold> nicopace: sorry, I just found that bit entertaining..
[02:42] <nicopace> oh... ok
[02:42] <nicopace> well.. i'll ask the list, thanks!
[10:37] <gnuoy> dosaboy, do you have anytime to take a look at https://code.launchpad.net/~gnuoy/charms/trusty/neutron-openvswitch/1421215/+merge/249535 ?
[11:29] <dosaboy> gnuoy: not right now but will in a few
[11:29] <gnuoy> thanks
[11:52] <cjwatson> Hi, I'm trying to get the local provider working for me on vivid, but having no luck doing even the simplest things.  Here's my log: http://paste.ubuntu.com/10203407/
[11:53] <cjwatson> Could anyone have a look?  LXC normally works for me, but juju doesn't seem to be getting as far as invoking lxc-anything here, judging from ps and strace, there's nothing interesting in any log I can find, and I'm using upstart since I know juju doesn't work with systemd on the host yet.
[13:50] <hazmat> cjwatson: hmm.. there's an http server normally on local provider acting as storage, it looks like there's some issue there uploading the charms to it. is there anything in the machine-0.log
[13:51] <hazmat> cjwatson: machine-0 == host for local provider, there's normally something per default in ~/.juju/local
[13:51] <hazmat> for the logs
[13:52] <hazmat> cjwatson: the http server for storage on local provider defaults to port 8040 fwiw
[15:09] <cjwatson> hazmat: machine-0.log hasn't had anything since I bootstrapped, last line is '2015-02-13 11:50:03 DEBUG juju.worker.logger logger.go:45 reconfiguring logging from "<root>=DEBUG" to "<root>=WARNING;unit=DEBUG"' and I've had an attempted deploy running for a minute or so
[15:10] <cjwatson> hazmat: jujud is listening on 8040, but stracing it during an attempted deploy shows nothing but futex syscalls
[15:11] <cjwatson> oh and epoll_wait.  uninteresting stuff like that
[15:16] <cjwatson> there's a little bit of chatter with mongod as well, but nothing about 8040 as far as I can see
[15:59] <hazmat> cjwatson: its a little odd normally i would suspect a firewall, but 500 errors sounds the web server is responding with an error, if you hit it directly via curl i'm curious what it does
[15:59] <hazmat> cjwatson: flipside is destroy with force and try bootstraping again
[16:00] <cjwatson> hazmat: I've done the latter multiple times
[16:01] <cjwatson> $ sudo netstat -anp | grep -w 8040
[16:01] <cjwatson> tcp        0      0 10.0.3.1:8040           0.0.0.0:*               LISTEN      2991/jujud
[16:01] <cjwatson> curl http://10.0.3.1:8040/   hangs
[16:02] <cjwatson> oh wait, don't tell me this is a proxy thing
[16:02] <hazmat> cjwatson: doh.. thats possible no_proxy="localhost" ?
[16:02] <hazmat> er. no_proxy="10.0.3.1"
[16:04] <cjwatson> hazmat: running juju deploy under "env -u http_proxy" doesn't help, but perhaps it's jujud's environment that matters?
[16:05]  * cjwatson retries with no-proxy in environments.yaml
[16:07] <cjwatson> ah, victory
[16:07] <cjwatson> hazmat: thanks for the clues!
[16:10] <TimNich> when juju bootstrapping in maas, are the same cluster boot images used as for a normal node enlistment?
[16:39] <stub> Has anyone else been having provisioning problems with the local provider since 1.21.1 ? provisioning seems to stop sometimes, and no new instances until I've destroyed and rebootstrapped the environment.
[16:40] <stub> I think there was an lxc update around the same time, so I don't know if it is juju or lxc
[16:41] <stub> I can't locate any useful logs to diagnose further.
[16:58] <jcastro> kirkland, peer review at your convenience: http://askubuntu.com/questions/585150/what-is-the-difference-between-a-snappy-apps-and-charms-and-click/585187#585187
[17:03] <rick_h_> jcastro: I'd suggest mentioning a bit charms reactive to others when related/interfaces/etc as a different as well.
[17:16] <adalbas> hi! one question related to units and relations . If I add a unit after the relation is added, the charm hooks should be able to apply the new unit with any configuration needed for the relation, am i right?
[17:17] <jcastro> right
[17:18] <adalbas> jcastro, so, in case i'm working with two services, a manager and a client, and I add a unit in the client, would all hooks from manager-relation and client-relation run?
[17:18] <marcoceppi> adalbas: yes
[17:19] <marcoceppi> while relations are created on a per service context, hooks are executed on a per unit level
[17:19] <marcoceppi> so addign a new client would initiate the relation cycle for that new unit to the manager again
[17:20] <adalbas> marcoceppi, that would run the manager-relation-joined and client-relation-joined as well, and the changed
[17:20] <adalbas> if i have configure those
[17:20] <jcastro> any ~charmer have time to copy precise/transcode to trusty?
[17:20] <jcastro> the made up silly tests are passing. :p
[17:21] <adalbas> marcoceppi, the add-unit to my charm worked before i add the relation, but not after, so I'm trying to check if my assumptions are correct
[18:02] <jcastro> hey jose
[18:03] <jcastro> kwmonroe has been working on some big data stuff, I think we should sync up with him and talk about what to show @ SCALE?
[18:30] <lazyPower> jcastro: pulled the transcode charm, doing local verification before i promote. did we get a bug filed for this?
[18:31] <jcastro> there's no bug afaict
[18:33] <lazyPower> https://bugs.launchpad.net/charms/+source/transcode/+bug/1421767
[18:33] <mup> Bug #1421767: Promote transcode charm to trusty <transcode (Juju Charms Collection):New> <https://launchpad.net/bugs/1421767>
[18:33] <lazyPower> kirkland: if you want a bundle for trusty, i'll need a ticket and a new bundle repository attached
[18:34] <lazyPower> but working the charm now, should have this done shortly.
[19:05] <lazyPower> jcastro: just got a ping from jose on telegram, he's having internet issues and says "if you can hop on can you ping me there"
[19:11] <nicopace> hi guys, how can i provide extra files to a particular charm (for example deb files, or config files)? Ex. data/extra.vcl for Varnish, or elasticsearch.deb for Elastisearch?
[19:14] <jcastro> nicopace, check this out: https://api.jujucharms.com/v4/trusty/elasticsearch-8/archive/config.yaml
[19:14] <jcastro> you can just have the download location be a config option (with a default)
[19:14] <jcastro> or you can just bundle whatever in the charm, but that might make it annoying to update
[19:14] <nicopace> sure... but if i want to provide a deb file (a feature provided by the charm)
[19:14] <jcastro> for config files, then that's easy
[19:14] <jcastro> sure
[19:15] <nicopace> i'm testing the charm
[19:15] <jcastro> yeah
[19:15] <nicopace> so that is one of the functions provided by the charm
[19:16] <nicopace> jcastro: any idea about my question?
[19:17] <jcastro> which one? about bundling a file? sure you can do that
[19:17] <jcastro> just make like a /data or /payload directory or something in your charm
[19:18] <jcastro> then you can put whatever you want in there, config files, debs, etc and reference that directory from your other hooks
[19:20] <jcastro> does that answer your question?
[19:30] <nicopace> so, i need to 'fork' the charm in order to add files?
[19:38] <Crypticus> rick_h_, You around?
[19:42] <lazyPower> mbruzek: can you kick off the transcode ci test again? it was apparently kicked out
[19:43] <mbruzek> lazyPower: ack
[19:45] <mbruzek> lazyPower: cs:trusty/transcode-1?
[19:45] <mbruzek> or cs:precise/transcode-1
[19:46] <lazyPower> mbruzek: cs:precise/transode-1
[19:49] <rick_h_> Crypticus: what's up?
[19:49] <Crypticus> I was going to ask if you know how to make juju deploy Juno Openstack packages
[19:50] <Crypticus> I think I might have figured it out, but still testing
[19:50] <rick_h_> Crypticus: cool, I've no idea tbh. We can probably find out but it's hitting late friday and folks will start heading out
[19:52] <Crypticus> OK thanks
[19:52] <Crypticus> Ill do more digging
[19:53] <Crypticus> I found the juju get <service> command, that might be all I need
[19:53] <Crypticus> thanks again!
[19:53] <nicopace> jcastro: ^
[19:54] <jcastro> nicopace, if you're modifying an existing one yes, you need to fork it
[19:54] <nicopace> yes, i want to test elastiserch and varnish
[19:55] <jcastro> yeah fork it, then include the debs in a directory, then modify the install hook to reference the local deb instead of the default source
[19:56] <nicopace> jcastro: that's the strange thing... the charm already provides the functionality to look for a deb package inside the charm
[19:56] <jcastro> oh ok, so that's good
[19:57] <nicopace> well... i'll see what i can do :)
[19:57] <jcastro> does the varnish charm have that too?
[19:58] <nicopace> something similiar... in it's readme it recommends that if you want to add rules, to add an extra.vcl to the charm :S
[19:58] <nicopace> (instead of adding it as a config option)
[20:07] <mbruzek> lazyPower: I kicked the transcode tests again this time the *right* way
[20:07] <lazyPower> mbruzek:  <3 preciate you
[20:07] <mbruzek> lazyPower: if you want to follow along from home http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/73/console
[20:25] <nicopace> guys... i'm having this error with an example deploy for logstash-agent: Error': u'cannot add relation "auth-proxy:juju-info kibana:juju-info": principal and subordinate services\' series must match',
[20:26] <nicopace> auth-proxy: cs:~paulcz/precise/auth-proxy-0
[20:26] <nicopace> kibana: cs:trusty/kibana-3
[21:01] <jose> jcastro: pong, sure!
[21:01] <jose> got my internet connection back \o/
[21:05] <marcoceppi> nicopace: the error states taht you can't put a precise subordinate on a trusty service. The series must match for primary to subordiante
[21:15] <jose> still, you can link mix-match non-subordinate services and series
[22:28] <Crypticus> have a great weekend everyone!