[03:47] <noodles785> I was wanting to experiment adding egress rules to all units in an environment. I can't do that via constraints or similar juju functionality right? (I'm assuming I'll need to update the default secgroup for the env, which will only work when deploying to openstack/aws, not local)
[04:11] <rick_h_> noodles775: you could add a subordinate, I've thought of doing that
[04:11] <rick_h_> noodles775: having a egress filter subordinate that get attched in dev/qa to create firewall rules manually
[06:46] <noodles775> rick_h_: yeah - I was hoping to do it outside the units themselves (ie. secgroups), but wanted to check whether it's something juju manages (I'm assuming not). Thanks!
[06:47] <rick_h_> noodles775: I don't think so atm
[15:30] <skay> I think the charm helper docs for charm create are out of sync with the package, but could use a sanity check. here's what results from following the docs, http://paste.ubuntu.com/9125147/
[15:30] <skay> expected behavior should be http://pythonhosted.org/charmhelpers/getting-started.html#creating-a-new-charm right?
[15:35] <tvansteenburgh> skay: too many "create" in your commands
[15:36] <lazyPower> skay: are you looking at using the services framework as well
[15:36] <lazyPower> the python-basic template is more likely what you're looking for.
[15:36] <skay> lazyPower: when I tried to use the -t to specify a template, I got a usage error
[15:37] <tvansteenburgh> skay you have "charm create create"
[15:46] <skay> tvansteenburgh: woohoo, I like it when it's a typo instead of a complete crazy misunderstanding
[15:46] <tvansteenburgh>  :)
[15:47] <skay> lazyPower: python-basic is indeed what I was looking for (it also looks like the docs should indicate python-basic for hte template rather than python?)
[15:47] <skay> thanks all
[15:48] <lazyPower> skay: It's a bit confusing I agree - python being an alias for the services framework.
[15:49] <skay> lazyPower: for feedback: when I use the python template the dir tree does not resemble the dir tree on the docs.
[15:50]  * tvansteenburgh makes a note to update docs
[15:50] <tvansteenburgh> thanks for pointing that out skay
[15:50] <skay> tvansteenburgh: I wasn't sure if I should open an issue in case I had misunderstood something. thanks for helping.
[15:51] <tvansteenburgh> sure thing
[15:54] <skay> avoine: adding support for pip_extra_args in order to use --no-index --find-links=/some/path, isn't as straight forward as I thought due to pip not being able to find /some/path.
[15:55] <skay> avoine: I am not sure exactly what to do, and maybe I need to write a subordinate charm to populate /some/path on the python-django unit?
[15:55] <skay> because I don't think that functionality belongs in python-django
[15:56] <skay> I think adding support for pip_extra_args belongs, and python-django would just pass that to pip
[15:56] <skay> and it would be the responsibility of something else to ensure the path is reachable
[16:21] <avoine> skay: Have you tried to upgrade pip?
[16:23] <skay> avoine: I did try, that did not resolve the problem. (and also would be a problem if one applies pip_extra_args to all calls, if it is the case that the existing pip doesn't support the extra args, but while I investigated I introduced a temp kluge to ignore it when installing pip)
[16:31] <avoine> skay: just to be sure I understand, your installing a tar archive with your django project + your dependencies and then your pointing pip ... --find-links to your dependencies dir, right?
[16:32] <avoine> also pip don't need to be upgrade on trusty since "Added support for bare paths (including relative paths) as argument to –find-links" was added in version 1.3 and trusty is 1.5.4
[16:32] <skay> avoine: not exactly. I tarred up my django project and had dependencies in the local file system. oh derp, I should just tar them up too?
[16:32] <skay> avoine: I'm using precise at the moment (I thought the gunicorn charm was precise, but if I'm mistaken I can use trusty)
[16:34] <avoine> gunicorn is in trusty too
[16:34] <avoine> skay: how do you add your dependencies, with scp?
[16:35] <avoine> –find-links needs a dir where dependencies are already downloaded
[16:35] <skay> avoine: no, I ignorantly thought that juju would be able to provide access to them in the local file system
[16:35] <avoine> oh like vagrant does
[16:35] <avoine> ?
[16:35] <skay> yeah
[16:35] <avoine> no indeed it's not
[16:35] <avoine> I would put them in the tar
[16:36] <skay> yes, it is clear to me now
[16:36] <skay> this is simpler.
[16:36] <skay> thanks for walking me through that
[16:36] <avoine> but I think that's a feature they want to add
[16:36] <avoine> that would be usefull
[16:38] <avoine> lazyPower: mounting local directory inside a local deployement (with nfs for example) is still a feature you wanted to add to juju?
[16:39] <lazyPower> avoine: we found a work around as documented in the NFS charm
[16:39] <avoine> cool
[16:39] <avoine> skay:  ^
[16:39] <skay> o/
[16:39] <lazyPower> it requires some manual intervention - so adding something without the manual intervention would be nice - but i can see it as being lower priority
[16:40] <lazyPower> skay: https://jujucharms.com/nfs/trusty/0 - take a look at "On the LXC host" in the readme
[16:41]  * skay takes a look
[16:42] <avoine> I guess that would be a good use case for a juju plugin
[16:52] <jw4> lazyPower, avoine this sounds like what Juju Actions is intended for
[16:53] <lazyPower> jw4: i dont think actions will be able to modify the HOST on behalf of the user.
[16:53] <lazyPower> those particular edits take place on the LXC host so the containers can receive the nfs kernel modules - otherwise apparmor blocks them
[16:54] <jw4> lazyPower: I see - and actions run in the context of the units
[16:54] <lazyPower> correct
[16:55] <lazyPower> actions are intended to be helpers that dont necessarily belong in the hooks - like database backups, adding users to an app, etc.
[16:55] <jw4> lazyPower: oh well.  I got excited for a minute there
[17:19] <avoine> I forgot, is there a way I can get the data of a relation outside a hook or with a juju command?
[17:31] <avoine> juju-run on the vm did the trick
[18:41] <mwenning> hi juju team, can anyone help with a juju hang problem?
[18:47] <lazyPower> mwenning: hey o/ whats going on with juju?
[18:49] <mwenning> lazyPower, hi, I'm running juju bootstrap --debug -e maas and it hangs for 10 min and then fails with a timeout
[18:50] <lazyPower> mwenning: are the units still spinning up? iirc you're working in a pure hardware environment
[18:50] <mwenning> I'm pretty sure I didn't set the proxy right, but it won't take the right value anymore.
[18:51] <mwenning> juju destroy-environment --debug --force maas also hangs
[18:51] <mwenning> stby I'll get a pastebin
[18:51] <jose> mwenning: is it still giving the 502?
[18:51] <mwenning> yes.
[18:52] <jose> huh
[18:52] <mwenning> after I set the proxy correctly it worked for awhile, now it's hung again
[18:52] <mwenning> s/hung/hanging
[18:54] <mwenning> https://pastebin.canonical.com/120815/
[18:55] <mwenning> lazyPower, jose, it hangs at line 9 for probably 10 min, then dumps the rest of that stuff.
[18:56] <jose> mwenning: lazyPower will give you a hand with this - cannot access canonical services and I wouldn't risk pasting any private details on a public site
[18:56] <mwenning> jose, ok thx
[18:58] <lazyPower> mwenning: can your workstation reach the node its attempting to bootstrap when you just activate it in the MAAS gui?
[18:58] <mwenning> lazyPower, yes, maas works fine, I can start/stop all my nodes
[18:59] <jcastro> is `instance-type` ignored in environments.yaml?
[18:59] <lazyPower> mwenning: and workstation connectivity to the nodes works as well?
[18:59] <jcastro> I put m3.mediums but it's asking for m1.smalls
[18:59] <lazyPower> jcastro: thats a depreciated constraint
[18:59] <lazyPower> you should add proper constraints
[18:59] <mwenning> lazyPower, yes, I can ssh into all the nodes from my maas server
[19:00] <jcastro> I thought we were putting it back in?
[19:00] <jcastro> or at least defaulting to m3's?
[19:00] <lazyPower> mwenning: hmm... this is troubling
[19:00] <lazyPower> mwenning: which juju revision are you on? 1.20.x i assume?
[19:01] <mwenning> juju-core 1.20.11
[19:01] <lazyPower> ok, latest stable
[19:01] <lazyPower> hmm this sounds like a reachability issue though
[19:02] <mwenning> what's wierd is that it doesn't seem to take anything from environments.yaml or environments/maas.jenv
[19:03] <jose> what do you mean?
[19:03] <mwenning> I tried changing bootstrap-timeout to 120  and it didn't take it.
[19:04] <mwenning> I've got http-proxy and https-proxy set in the environments.yaml, that should point to the correct proxy but it doesn't seem to pay attention
[19:05] <mwenning> Is there somewhere else that juju is reading that info?
[19:06] <lazyPower> mwenning: im' asking for a core dev to come take a look with us - 1 moment
[19:06] <lazyPower> i'm not using any proxies and have limited interaction with using a proxy in juju
[19:10] <mwenning> hmm, what the heck?  It's trying to access 192.168.1.1/MAAS .
[19:10] <mwenning> That's not my MAAS server, it's at 192.168.0.2
[19:10] <lazyPower> mwenning: stale maas jenv?
[19:10] <mwenning> where is that?
[19:11] <mwenning> where is maas.jenv?
[19:11] <lazyPower> ~/.juju/environments/maas.jenv
[19:11] <jose> tvansteenburgh: ping, mind a quick pm?
[19:11] <tvansteenburgh> jose: sure
[19:12] <mwenning> actually maas.jenv is gone.
[19:15] <lazyPower> mwenning: ok so if its not reading a stale jenv file - something else is awry
[19:15] <lazyPower> can you verify the server config in environments.yaml is the correct ip address?
[19:17] <mwenning> I lazyPower , yes.  stby I'll paste the whole thing
[19:18] <mwenning> https://pastebin.canonical.com/120819/
[19:22] <lazyPower> mwenning: do you have another PROXy export set?
[19:22] <lazyPower> echo $JUJU_PROXY i think
[19:23] <mwenning> lazyPower, $JUJU_PROXY shows nothing
[19:23]  * lazyPower snaps
[19:23] <lazyPower> that was the last thought i had on what it could be
[19:23] <lazyPower> i unfortunately dont know why you're seeing that behavior :(
[19:24] <mwenning> lazyPower, ok.  I've got to drive downtown to a meeting, I'll look at this later
[19:25] <jcastro> hey bcsallerm can you add your +1 to this bug?
[19:25] <jcastro> https://bugs.launchpad.net/juju-core/+bug/1373516
[19:25] <mup> Bug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1373516>
[19:27] <jcastro> hey natefinch, can we get this on someone's radar? ^^^^
[19:27] <jcastro> This will only get worse and worse
[19:33] <mwenning> lazyPower, if you can think of anywhere that juju might be cacheing that information please let me know, that's all I can figure
[19:34] <lazyPower> mwenning: my only other suggestion is to do a full env dump and sift through whats in there
[19:34] <lazyPower> juju reads from env => .jenv => environments.yaml - in that order.
[19:35] <mwenning> lazyPower, do you know if it reads http_proxy in the env?
[19:35] <lazyPower> i believe so
[19:36] <mwenning> ok, I think that's new, but I've set it there too.
[19:36] <natefinch> jcastro: I think we addressed that... lemme double check, thought I saw that in the 1.21 release notes
[19:37] <natefinch> jcastro: hmm. maybe not
[19:39] <natefinch> jcastro: it's definitely on our radar.  I'll see if I can get someone to put a little time into fixing it.  I think the main problem we had was that there wasn't really a no-brainer replacement.  both t2.small and m3.medium had slight problems (I believe t2.small is a burstable instance, and m3.medium is slightly more expensive)
[19:39] <jcastro> yeah
[19:40] <jcastro> it was just reiterated to us that m1's are going away much faster than we thought
[19:40] <natefinch> jcastro: personally, I'd just go with m3.medium.... it's not our fault amazon doesn't have cheap prices :)
[19:40] <natefinch> (for reasonable machines)
[19:41] <natefinch> jcastro: I'll bring it up right now.  I agree it needs to get fixed ASAP.  Of course, the problem is that it won't be fixed in older jujus
[19:41] <jcastro> I'd rather have people pay more than having it not work because m1's are being culled
[19:41] <natefinch> yep
[19:41] <natefinch> jcastro: we also should handle that error better by requesting from a different AZ in the region and/or trying a different instance type
[19:43] <natefinch> jcastro: who said the m1's are going away faster?  Just want to give proper attribution.
[19:43] <jcastro> ben and robert
[19:43] <jcastro> aka the CPC team
[19:43] <jcastro> robert filed the initial bug
[19:50] <natefinch> jcastro: just sent a mail to juju-dev.  Assuming no one objects, I'll try to make sure someone gets on it ASAP.
[19:50] <jcastro> -<3 thanks