[00:24] <jose> mind some upvotes? http://www.reddit.com/r/Ubuntu/comments/275r00/do_you_like_cloud_and_automation_with_juju_check/
[00:41] <designated> Can someone please explain to me how I would deploy a juju charm and specify different network interfaces for different things?  As an example, I have two bonded and vlan tagged 10Gbe NICS that I would like to use for openstack storage and host to host communication, but the charm doesn't seem to account for any variation.  Are we truly limited to a single network interface for everything unless we write custom charms?
[00:42] <designated> I'm not finding anything in the documentation that addresses this situation.
[01:27] <jkary1> Hello folks.  Anyone having issues with juju sync-tools?  I seem to be getting connection timeout issues…
[01:30] <jkary1> Debug is telling me "cannot load index "https://streams.canonical.com/juju/tools/streams/v1/index.sjson": invalid URL", but curl works fine.
[01:49] <designated> jkary1, good luck getting a response in here :(
[02:24] <jose> jkary1: can you try again, please?
[02:24] <jose> designated: maybe try in business hours? I find more people around 9am-5pm EST
[02:24] <jose> (well, EDT)
[04:02] <lazyPower> designated: thats purely dependent on teh charm. if the charm doesn't support designating the interface to bind to, its a defacto missing feature and should be filed.
[04:03] <lazyPower> designated: Most of the charms that I've reviewed do not support that kind of a scenario, and this would be the first i've seen it come up in chat. However - with that being said, its a valid use case and if you have need, this is a great area that you could contribute back to. If you need some help getting started I could take a look at teh charm with you and lay out a road map on how i would tackle the implementation / review process.
[04:04] <lazyPower> and +1 for jose's note about business hours. Most of the juju team is around during EDT office hours.
[13:00] <s3an2> Hi, has anyone had any problems with the openstack vncproxy not getting installed - I would have expected this to be within the nova-cloud-controller charm?
[13:02] <Mosibi> s3an2: yes..
[13:03] <Mosibi> a colleage had changed the charms and can start testing it real soon.
[13:04] <s3an2> Ok - So this is a known problem?
[13:04] <Mosibi> If his code does what we want, he will submit it and then hopefully it will be commited.
[13:05] <Mosibi> s3an2: there's is a small workaround. You can put the needed configuration in config_flags in nova-cloud-conroller and nova-compute
[13:05] <Mosibi> Besides that, you need to install some extra packages.
[13:08] <s3an2> cool, So I can install the packages on the nova-cloud-controller, and set the nova.conf options in config_flags as a work around - that sounds good.
[13:08] <Mosibi> s3an2: config-flags: "vncserver_listen=<ip_addr_cloudctrl>,vncserver_proxyclient_address=<ip_addr_cloudctrl>,vnc_enabled=True,novncproxy_host=0.0.0.0,novncproxy_port=6080,novncproxy_base_url=http://<ip_addr_cloudctrl>:6080/vnc_auto.html"
[13:08] <Mosibi> that's for the cloudcontroller
[13:08] <Mosibi> and this one for the compute node
[13:08] <Mosibi> config-flags: "vnc_enabled=True,vncserver_listen=0.0.0.0,novncproxy_base_url=http://<ip_addr_cloudctrl>:6080/vnc_auto.html,vncserver_proxyclient_address=<ip_addr_compute_node>"
[13:08] <jkary1> Hello folks.  Anyone having issues with juju sync-tools?  I seem to be getting connection timeout issues…
[13:08] <Mosibi> The problem is that ip_addr_compute_node is static....
[13:09] <jkary1> Debug is telling me "cannot load index "https://streams.canonical.com/juju/tools/streams/v1/index.sjson": invalid URL", but curl works fine.
[13:09] <Mosibi> s3an2: cloudcontroller: apt-get install nova-console nova-novncproxy
[13:09] <Mosibi> s3an2: compute: apt-get install nova-novncproxy
[13:10] <Mosibi> that's it :)
[13:39] <s3an2> cool, got it working :)
[13:51] <gh0st_> Hello
[13:51] <Mosibi> s3an2: nice!
[13:53] <gh0st_> does someone know how to stop hook executing?
[13:53] <marcoceppi> gh0st_: could you elaborate?
[13:53] <gh0st_> i want to deploy mongo shard cluster
[13:54] <alexpilotti> alexisb: ping
[13:54] <alexisb> alexpilotti, join juju-dev
[13:55] <lazyPower> gh0st_: whats juju doing that you're not expecting it to do? I don't understand the correlation between wanting to deploy a mongodb cluster and stopping hook execution.
[13:57] <gh0st_> when I connect charms beetwen them (3 configsvr and 1 mongos) i have a hook error becaues mongos instance try to connect to config servers but it's not ready yet
[13:58] <lazyPower> gh0st_: ah, ok. Well you can't 'stop hook execution' persay - but i'm assuming your service is now in an 'error' state because it didn't receive the data it was expecting?
[13:59] <gh0st_> yeah
[13:59] <gh0st_> hmm, maybe not stopping, but pausing or something
[14:00] <lazyPower> gh0st_: if its in an 'error' state, it wont be re-executed untill you tell it to re-run that hook or resolve it.
[14:00] <lazyPower> if your other service is online, you should be able to do a juju resolved --retry unit/#  and it will attempt to re-execute the hook that failed
[14:01] <hackedbellini> hi guys,
[14:01] <hackedbellini> I'm having 2 problems here since juju upgraded from 1.18.x to 1.19.2 (btw, don't know why upgrade-juju juju did this since 1.19.2 is a non-stable release).
[14:01] <hackedbellini> But well, all of my unit logs are being spammed with this: http://pastebin.ubuntu.com/7580562/
[14:01] <hackedbellini> and one of my units are in an error state but when I try to "juju resolved" it it gives me "ERROR cannot set resolved mode for unit "asyncweb/0": already resolved"
[14:01] <gh0st_> yeah, that's true, but i want to know is there any option to tell juju which instance it must configure first?
[14:02] <marcoceppi> gh0st_: no, the charm should do that
[14:02] <marcoceppi> so if it's not, then it may be a bug in the charm
[14:03] <lazyPower> gh0st_: if you're using a bundle, juju deployer will parse the relationships and deploy dependent services, and once they have reached a ready state, it will then build the relationships between charms. But to marcoceppi's point, the charm should be robust enough to enter a wait loop while its pending data.
[14:03] <lazyPower> gh0st_: if you're seeing behavior that doesnt fit with that statement, I encourage you to file a bug against the MongoDB charm so the maintainer can take a look at it and potentially issue a patch.
[14:05] <gh0st_> ok, i think I do that
[14:06] <gh0st_> but i have another question..
[14:06] <gh0st_> so how to put charm into wait loop in code, i need create for this special function or something?
[14:07] <jamespage> gnuoy, if you have time - https://code.launchpad.net/~james-page/charm-helpers/juno-opening/+merge/221882
[14:07] <lazyPower> gh0st_: relationships send data over the wire and you read them on the consuming charm. If the data is not present, you can do one of two things. a) return 0 so when its complete the relationship-changed hook will re-execute, or b) sleep & loop until the value is present.
[14:08] <lazyPower> gh0st_: and correct - the charm code itself would need to implement this behavior
[14:08] <gnuoy> jamespage, looking
[14:09] <lazyPower> gh0st_: from what I remember the MongoDB charm is a pretty robust python based charm, and if you're familiar with python you may be able to implement and submit a patch. All community contributions are welcome!
[14:10] <gh0st_> yeah, and I want to do this
[14:11] <gh0st_> but for now i try to figure it out how to write this wait loop while charm is waiting for data?
[14:12] <lazyPower> gh0st_: if you have charm-tools package installed, charm-get mongodb and start looking through the source for the relationship hooks.
[14:14] <gnuoy> jamespage, merged
[14:22] <gh0st_> ok, is there option, when charm hook is in waiting loop, is there option to execut another hook to gather data that charm is needs?
[14:24] <lazyPower> gh0st_: it should be gathering the data it needs during the hook you've put in a wait loop
[14:29] <jose> lazyPower: HAPPY BIRTHDAY, SIR!
[14:29] <wwitzel3> cory_fu: just noticed you got bug 1314699 buttoned up last week, nice work :)
[14:29]  * jose brings balloons and cake
[14:30] <gh0st_> but what when i put charm in waiting loop and it can't gathering data because, all what charm is need is waiting for configure server on another instance deployed by juju?
[14:31] <lazyPower> jose: thanks :)
[14:33] <lazyPower> gh0st_: I think you're misunderstanding the workflow. when that data is propigated via relation-set - the relationship's config-changed hook is fired on the consuming service. It can then read that data. So this is a if / then logic block that says "if this relationship value is present, execute, otherwise return 0 and do nothing until we have the data"
[14:33] <cory_fu> wwitzel3: It still needs solr and SCM support, but I'm quite happy with how clean the charm-helpers services framework made the charm.
[14:34] <lazyPower> er, sorry i said config-changed and thats confusing. its relationship-changed hook. gh0st_
[14:34] <gh0st_> sorry, i get it now
[14:35] <lazyPower> no need to apologize :) We have to start somewhere
[14:38] <hackedbellini> so, I found this bug (https://bugs.launchpad.net/juju-core/+bug/1175031) and tried to do what the first comment said, to restart some jujud services running inside the lxc. Now there's a panic on the unit log (http://pastebin.ubuntu.com/7580760/) and I still can't set it resolved (juju insists it's already resolved when it's not)
[14:45] <gh0st_> so when relation-set is executed, then next executed is config-changed, that's correct?
[14:57] <marcoceppi> gh0st_: no, relation-changed is executed
[14:57] <marcoceppi> well *-relation-changed, where * is the relation that the data was changed on
[15:21] <rbasak> sinzui: thank you for sorting out the 1.18.4 release for me. I hope to upload to Utopic tomorrow.
[15:21] <rbasak> Then I can backport push it to Trusty.
[15:22] <sinzui> rbasak, thank you very much
[15:25] <rbasak> jamespage: ^^, just so I don't step on your toes.
[15:25] <jamespage> rbasak, you are not :-)
[15:25] <jamespage> thanks for the headsup
[15:34] <jose> mbruzek: I'm about to be done with the idempotency issues, just one last manual test about to be ran :)
[15:34] <jose> jcastro: hey, whatcha think about putting the reddit link on the channel topic?
[15:34] <jcastro> sure
[15:35] <mbruzek> jose that is awesome
[15:35] <mbruzek> looking forward to it jose
[15:36] <gh0st_> ok, and when you executed relation-set you put some info like unit, port, address. Is there any way to change that info when relation-changed is executed after relation-set?
[15:36] <jose> ah, there ya go
[15:36] <jose> gh0st_: relation-set is not meant to be a hook, it's a command, so you execute that inside your relation-changed
[15:37] <gh0st_> oh, i get it so finally when relation-set is executed it must be in *-relation-changed not in *-relation-joined hook?
[15:39] <jose> gh0st_: you can put the command in any of the hooks, when you see it necessary put it there
[15:39] <jose> so you can run it in *-relation-joined, and then in *-relation-changed
[15:51] <gh0st_> and if I run it on *-relation-joined it executed relation-changed, is that correct?
[15:51] <gh0st_> and when i execute relation-set in *-relation-changed hook, what next will be executed, again relation-changed?
[15:52] <cjohnston> noodles775: hey there.. avoine is working on conversting the python-django charm to use ansbible..
[15:52] <cjohnston> he has some questions about a way to do a couple of the things that he is doing...
[15:52] <noodles775> Hi there avoine! How far along are you?
[15:52] <avoine> noodles775: I'm there
[15:53] <cjohnston> It looks quite good so far... but there is still more python to be removed that he isn't quite sure how to do.
[15:54] <avoine> the problem is that I have some extra variables that I would need in the ansible playbook
[15:54] <avoine> so I was thinking maybe we could modify the module in charm-helpers to do that
[15:54] <avoine> something like: apply_playbook(playbook, tags=Install,      extra_vars={'my_custom_var': 1234})
[15:55] <avoine> noodles775: what do you think?
[15:55] <noodles775> avoine: Yes, something similar was requested by bloodearnest a few weeks ago. +1. But let me know your actual use-case, as you may be able to simply set the variable in your playbook for it to be available in all other tasks/templates etc.
[15:56] <jose> gh0st_: I don't understand what you're trying to do
[15:57] <avoine> noodles775: one example is that I need to do some  escaping like this: {{local_unit|dirname|replace("-","_")}}
[15:57] <avoine> and that makes the playbook horrible
[15:58] <noodles775> avoine: if it's DRY it wouldn't be horrible would it? (I mean, if you add to your playbook's vars section with, 'myvar: {{ local_unit|dirname|replace("-","_")}}' and just use 'myvar' throughout your playbook?
[15:59] <avoine> yeah that would do it
[16:00] <avoine> but I also the settings and python path combinations are quite complicated and I don't want to make a task for every combinations
[16:01] <avoine> like I'm doing now for the repos + branch combinations
[16:01] <noodles775> avoine: can I see? Where's the branch
[16:01] <avoine> noodles775: here -> http://bazaar.launchpad.net/~patrick-hetu/charms/precise/python-django/charmhelpers/view/head:/playbooks/install.yaml
[16:02] <noodles775> avoine: Just a heads-up, I'm currently working on some re-usable roles for charms for our internal use. I've not yet documented them at all, but will do in the next few days: https://github.com/absoludity/charm-ansible-roles
[16:02] <noodles775> avoine: the wsgi-app role may be something you could reuse (if you wanted to), but I'll ping you about it in a week or so when I've got it documented/better tested.
[16:02]  * noodles775 checks the branch.
[16:03] <avoine> a re-usable role for vcs would do the trick
[16:05] <noodles775> avoine: so in that install.yaml, a vars section defining repo_destination would get rid of a lot of the ugliness. I'm not sure how you can avoid separate tasks for separate vcs's though.
[16:06] <noodles775> avoine: great work on the upgrade, it's looking really nice!
[16:07] <avoine> noodles775: thanks
[16:09] <avoine> noodles775: I'll give it a try at ansible only and I'll ping you back if that's too complicated
[16:11] <noodles775> avoine: sounds good. I'll probably be gone, but will take a look first thing tomorrow (or may pop back later)
[16:13] <avoine> noodles775: ok, btw if you could give your +1 to the Merge proposal that would be awesome (I can't wait to use it in juju-gui ;) )
[16:14] <noodles775> avoine: I've not looked closely at your charm yet, but one thought is that you could separate those tasks into separate files (not playbooks, just tasks for inclusion) and then conditionally include them in your playbook depending on vcs and/or repos_branch (see the ansible docs)
[16:14] <noodles775> avoine: will do, feel free to ping me when it's ready.
[16:14] <avoine> ok
[16:14] <jose> mbruzek: and it's all set now! :)
[16:14] <mbruzek> meow?
[16:14] <mbruzek> jose, owncloud?
[16:14] <avoine> noodles775: thanks for the tip
[16:14] <jose> mbruzek: yeah!
[16:15] <mbruzek> or nyan cat?
[16:15] <jose> owncloud
[16:15]  * avoine go to lunch
[16:15] <jose> damn, I have to fix nyancat too? /me shrugs
[16:15] <mbruzek> just kidding with you Jose.
[16:15] <jose> :P
[16:16] <mbruzek> I will take a look at owncloud when I get a chance.
[16:16] <jose> thank you!
[16:31] <Egoist> Hello
[16:31] <Egoist> I have a problem with charm hooks?
[16:31] <designated> lazyPower, Thanks for the response.  When do you have some time to discuss charms supporting multiple network interfaces, to include bonded and vlan tagged NICs?
[16:31] <Egoist> is there any one who can explain me?
[16:32] <lazyPower> designated: I'll be 'free'ish around 4:00pm EDT if that works for you.
[16:32] <designated> lazyPower, I'll be here.
[16:34] <Egoist> i have a problem with mongodb charm, when i want to connect instances who should be config server with router, then i have a problem with hook
[17:17] <Egoist> I have to instances and want to connect them. The problem is that first instance want to connect with second but second has not finished configuration so refsed connection, and by that i have Error in *-relation-changed hook
[17:17] <Egoist> someone know how to handle with this?
[18:22] <sebas5384> ahasenack: pt-br ?
[18:22] <ahasenack> sim
[18:22] <sebas5384> opa!
[18:23] <sebas5384> não conheço ninguem do brasil que use juju, fora os caras do tsuru rsrs
[18:23] <sebas5384> que bom!
[18:26] <sebas5384> some wip ideia i'm working on, https://github.com/sebas5384/ansible-juju-local
[18:27] <lazyPower> interesting sebas5384
[18:27] <lazyPower> I'll be watching this as it develops.
[18:27] <sebas5384> lazyPower: great!
[18:28] <sebas5384> this one was only to prove a concept, now I'm going to modularize more
[18:28] <lazyPower> sebas5384: my only thought on this - is that you're driving lxc with vagrant to drive juju, which is an added wrapper
[18:28] <lazyPower> why not use charms?
[18:29] <lazyPower> and cut out the vagrant portion?
[18:29] <lazyPower> oh wait, i missed something. You're driving lxc inside of vagrant for mac users.
[18:29] <lazyPower> carry on then
[18:29] <sebas5384> lazyPower: because i'm using mac, and others guys here too
[18:30] <lazyPower> sebas5384: i was brain bending around this a bit and think I'm going to write a wrapper for sending commands to the vagrant box via a juju plugin
[18:30] <lazyPower> eg: juju vagrant deploy mycharm
[18:30] <sebas5384> lazyPower: wow
[18:30] <sebas5384> thats interesting
[18:31] <lazyPower> that way you dont have to open an ssh connection inside the vagrant box, and it exposes a set of convenience methods for users consuming the vagrant boxes
[18:31] <lazyPower> which will accomplish some of what this is doing.
[18:31] <sebas5384> hmmm
[18:31] <lazyPower> i haven't done anything beyond drink beer and think about it... but you'll see some prelim code land in the next week or two.
[18:31] <sebas5384> hahaha
[18:32] <sebas5384> if you want to talk more about that lazyPower maybe a hangout
[18:32] <sebas5384> because that idea is great!
[18:32] <sebas5384> something i would be interesting in working in too
[18:34] <lazyPower> sure
[18:34] <lazyPower> Tomorrow evening work for you?
[18:34] <sebas5384> lazyPower: anyway i'm planning to make some juju roles for ansible
[18:34] <sebas5384> yeah of course
[18:34] <sebas5384> but whats your time zone?
[18:34] <lazyPower> brilliant.
[18:34] <lazyPower> EDT
[18:37] <lazyPower> sebas5384: whats your timezone?
[20:13] <designated> lazyPower, you available?
[20:13] <lazyPower> designated: shortly - i need to finish composing this email
[20:15] <lazyPower> designated: Ok. So - where do we begin? You want to specify network interfaces for binding on which charm?
[20:17] <designated> lazyPower, any of the openstack charms.  I want to have the ability to use separate interfaces for different functions, for example the mgmt network should be em1, the private and storage network should be two bonded 10Gbe interfaces, etc...
[20:22] <lazyPower> jamespage: is this on the roadmap for the OStack charms? ^
[20:22] <lazyPower> designated: let me validate this isn't already being worked on
[20:23] <designated> lazyPower, thank you
[20:26] <lazyPower> designated: without any response from an openstack charmer, my first thought is as follows. How do you determine which interfaces used for which task as it stands now? is this an arbitrary thing you do in your network, or do you follow a convention. In addition, is there an easy way to determine this programmatically?
[20:28] <designated> lazyPower, all of the servers in the resource pool will be configured identically so just having the ability in the charm to assign the bonded interface to certain tasks
[20:29] <designated> lazyPower, instead of being limited to a single interface
[20:30] <lazyPower> designated: In this instance, I would install the charm-tools package and 'charm get' the charm you wish to modify. Add a config parameter in config.yaml and modify the relevant hook(s) config-changed block and start testing the functionality.
[20:30] <lazyPower> once you've got something that accomplishes your goal, then submit it for Review process if you want it included in the upstream OpenStack charms.
[20:31] <lazyPower> This sounds like it would be a great addition to the OpenStack ecosystem. I'm not sure if it's already being worked on, so before i wrote any code, I would suggest you mail the juju mailing list and see if any traction has been made around the topic.
[20:31] <lazyPower> In terms of deployment and testing, I can help by 'sponsoring' your efforts and donating time to test / review your initial code prior to the official openstack charmer review
[20:32] <designated> lazyPower, thank you
[20:32] <lazyPower> but without an easy way to know 'this interface for public, this interface for private' since its kind of arbitrary between setups - the logic would need to be dependent on config options, and need to be added to the charm.
[20:33] <lazyPower> and the charm, by default, should assume a single network interface so it works with most deployments - which it does now.
[20:34] <lazyPower> designated: any time! We have a great community. Each submission counts :) And it sound's like you're working towards a highly optimized revision to the existing openstack experience, which would be great to see on top of our existing optimizations.
[20:38] <lazyPower> designated: i'm normally around unless i'm attending a conference circuit or on holiday. Feel free to ping me anytime for Q/A & reviews.
[21:13] <sebas5384> lazyPower: sorry!! was called to a meeting ¬¬
[21:14] <sebas5384> lazyPower: my timezone is EDT+1
[21:15] <lazyPower> sebas5384: ok. I can carve out some time around say, 2PM EDT for our Q/A?
[21:17] <sebas5384> lazyPower: what about the beer?
[21:17] <sebas5384> hehe
[21:17] <lazyPower> I cant drink at that hour, but you're more than welcome to :)
[21:17] <sebas5384> can be something more late, like 7pm ?
[21:17] <sebas5384> hehe
[21:17] <lazyPower> I don't see why not.
[21:17] <sebas5384> sure then
[21:17] <sebas5384> 7pm EDT time