[09:39] <schkovich> i am working with manual provider. each machine has 3 interfaces, public, multi-tenant service and private one. is there a way to configure juju to communicate on the private interface?
[09:57] <schkovich> if i edit agent.conf and set apiaddresses to private one or ad private one to array am i at risk that setting might be overwritten?
[10:00] <schkovich> is there preferable way to denote correct apiaddress? juju api-info gives me a list of all state sever IP addresses
[10:15] <schkovich> i see, apiaddresses will be overwritten therefore state-server is setting it
[11:03] <schkovich> not having an option to set preferred network makes manual environment truly manual
[11:03] <schkovich> based on non-transparent rules juju is picking multi-tenant network to communicate on
[11:03] <schkovich> which in turn makes setting firewall rules hard
[11:03] <schkovich> instead of selecting private network and just allowing connections from all machines in subnet
[11:03] <schkovich> firewall rules must be updated whenever a new machine is added
[12:53] <schkovich> anyone on manual provider and selecting private network to use? state-servers, logging, storage...
[13:14] <schkovich> there is a similar bug report https://bugs.launchpad.net/juju-core/+bug/1303204
[13:14] <mup> Bug #1303204: manual provider allow specifying private address for connecting back to state-server <improvement> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1303204>
[13:16] <schkovich> juju does use local-cloud but in my case i have two interfaces: one on rackspace multi-tenant service network which juju  would use and another one on the private network which i would like juju to use :)
[13:17] <schkovich> there is also a similar question on askubuntu having 6 votes http://askubuntu.com/questions/611564/how-does-juju-get-the-private-address-of-a-node
[13:22] <schkovich> i guess that in all cases logic implemented in juju/network/address.go will be used e.g. the first ip matching condition will be used :(
[14:42] <Johncr1> Hello Folks, I am trying deploy a seervice in lxc-container but the container is stuck in pending state ?
[14:43] <Johncr1> I have stopped ufw already
[14:43] <Johncr1> containers:
[14:43] <Johncr1>       2/lxc/0:
[14:43] <Johncr1>         agent-state: pending
[14:59] <Web> Big thanks to Juju team for all your work.  Without you my graduate project wouldn't have been such a success!
[15:09] <jcastro> Web: oh really?
[15:09] <jcastro> that'd be an awesome post to put on the list, sounds awesome
[15:12] <Web> jcastro: Thank you directly.  You been a huge help.  I will post a detailed development blog article soon on mastersproject.info but the project was a questionnaire service with developer access http://themindspot.com
[15:13] <jcastro> cool, let me know when it's up, we should be able to syndicate posts on juju.u.c soon
[15:16] <Web> Cool. I will do.  Focusing on getting a job this week now that I have time but get to it soon.
[15:16] <Web> PLus want to make sure that final grade is an A+++++++++++++.
[15:16] <Web> first
[15:17] <jcastro> heh, awesome
[15:36] <schkovich> can someone explain me why in one case juju is deciding to connect to the state server on the public ip and in other to the private ip
[15:36] <schkovich> machine agent.conf
[15:36] <schkovich> apiaddresses:
[15:36] <schkovich> - 10.181.139.18:17070
[15:36] <schkovich> unit on the machine above agent.conf
[15:36] <schkovich> apiaddresses:
[15:36] <schkovich> - 162.13.183.96:17070
[15:36] <schkovich> id does not make sense :(
[15:49] <jcastro> I need a ~charmer to action on this if they have a minute: https://bugs.launchpad.net/charms/+bug/1457263
[15:49] <mup> Bug #1457263: Remove galera charm from personal namespace <Juju Charms Collection:Confirmed> <https://launchpad.net/bugs/1457263>
[15:49] <cjwatson> Hi, is there any way I can get juju's private mongod to not sit there spinning and calling select 100 times a second?  It's quite literally causing me to have to open a window to dissipate laptop heat any time I'm using juju
[15:49] <jcastro> cjwatson: you probably want the guys in #juju-dev for that one
[15:50] <cjwatson> Mkay
[15:50] <lazyPower> jcastro: as thee LP Repository has been removed, the only leftover from that would actually come from UIEngineering. rick_h_ ^
[15:51] <jcastro> yeah I wasn't sure if we still need to file an RT ticket?
[15:51] <lazyPower> i dont think so
[15:51] <lazyPower> i'm pretty sure that with the new stuff they can do it in-house.
[15:51] <jcastro> yeah, rick_h_ I'd like to catch up with you today anyway if you have like a 10 min window for G+
[15:57] <rick_h_> jcastro: sure thing
[15:57] <rick_h_> jcastro: sooner is better for the next two hours I've got a window
[15:58] <rick_h_> lazyPower: rgr, will look. not had a chance yet today
[16:01] <jog> mgz, sinzui, do you know where I can find information on how to request a windows instance with juju?
[16:02] <sinzui> jog: the series eg local:win2012/dummy-source
[16:02] <rick_h_> jcastro: lazyPower replied to the bug
[16:03] <rick_h_> lazyPower: glad you had the bug there because I thought it was the ~codership one.
[16:04] <sinzui> jog: if you are using add-machine, you can use maas tags. I think like this juju add-machine --constraint tags=win2012
[16:05] <jog> sinzui, ok
[16:19] <lazyPower> rick_h_: happy to help :)
[17:00] <jcastro> rick_h_: how about now?
[17:01] <rick_h_> jcastro: sure
[20:45] <thumper> lazyPower: you around?
[20:46] <thumper> marcoceppi: you are at ODS?
[20:52] <tvansteenburgh> thumper: marcoceppi flying home atm
[20:53] <thumper> tvansteenburgh: ta
[20:58] <lazyPower> thumper: i'm here
[21:38] <mattrae> is it possible with juju gui and the local provider, to choose which machines i deploy a bundle to? when i click 'deploy this bundle' it asks if i'm sure, but doesn't give me an opportunity to choose which machines i want to use
[21:53] <lazyPower> mattrae: that's an incoming feature in a future juju gui release.
[21:53] <lazyPower> mattrae: aiui its been prototyped, and is in the alpha testing phase
[21:53] <lazyPower> hatch: may have more information about this for you
[21:55] <mattrae> lazyPower: ahh thanks :)
[22:17] <hatch> lazyPower: it's actually beta, soon to be RC'd :D
[22:27] <thumper> lazyPower: oh hai, I'm back here now
[22:27] <thumper> lazyPower: do you have 10-15 minutes for a hangout?
[22:29] <lazyPower> thumper: sure
[22:30] <thumper> lazyPower: https://plus.google.com/hangouts/_/canonical.com/charming?authuser=0
[23:02] <miken> Is there a way now to be able to upgrade a charm and set a (new) config option in one step?
[23:13] <lazyPower> miken: afaik - no. you upgrade-charm, then juju set.
[23:14] <lazyPower> juju upgrade-charm service && juju set service foo=bar - would be a hacky way to 'do it in one step' - but you'll still get the hooks executing as such. so 2x runs of config-changed in that sequence.
[23:15] <miken> k, thanks. Yeah, I'd ideally like to have something set for the install hook, which I assume that won't.