[07:05] <erik_lonroth> rick_h: Did you write this? http://mitechie.com/blog/2017/9/28/learning-to-speak-juju
[07:24] <zeestrat> erik_lonroth: Yeah, that's Rick.
[07:26] <erik_lonroth> its super!
[10:50] <rick_h> erik_lonroth: thank you
[10:54] <rick_h> erik_lonroth: zeestrat please make sure to share it along.
[12:54] <ed____> hi there :) does anyone know the right way to get rid of a machine that's in error state where provisioning can't match a suitable machine because of constraints? I want to back out of adding one machine manually! (oops)
[13:14] <rick_h> ed____: you should be able to juju destroy-machine --force
[13:31] <ed____> thank you Rick, I'll give it a try
[13:39] <ed____> yay :) it worked. Thank you Rick
[13:40] <rick_h> np ed____
[13:40] <skay> does anyone have a wsgi-layer that can deal with python 2 wsgi apps? There's https://github.com/canonical-webteam/layer-wsgi for python3
[13:41] <skay> I like the idea of using a wsgi layer, but I can't upgrade my application right now
[13:44] <rick_h> skay: hmm, might be tough. I'm not sure if bdx has anything as he was doing some django bits but I don't know if it was py2 or py3
[13:44] <rick_h> skay: can you crib enough to make the layer-wsgi py2 compatible?
[13:44] <skay> rick_h: I was wondering about that. would anyone other than me find it valuable?
[13:45] <rick_h> skay: always default to "yes" on that one :P
[13:45] <skay> haha
[13:45] <rick_h> skay: you're not so special as to be the only one doing it hehe
[13:45] <rick_h> just the only one asking about it out loud
[13:46] <skay> rick_h: I'm currently upgrading a django project from 1.6 to 1.11 so I have enough to deal with than to get it on python 3 /o\
[13:46] <skay> :(
[13:46] <skay> ;_; cry
[13:46] <rick_h> skay: hah, yea the MAAS folks I know had to put some big time into that move
[13:47] <skay> rick_h: oh hey, have of them written an epic of their journey past 1.6 and deployment gotchas?
[13:48] <skay> I've been thinking about how to do that, and wondering if I should just make a one-off deployment to get from 1.6 to 1.7 and subsequently do normal stuff
[13:48] <rick_h> skay: hmm, not sure. I thought I've got something tickling my brain but can't find anything off the top of my head.
[13:48] <bdx> skay, I've traced those trails ... it really helps if you are familiar with the big changes going into 1.11 (e.g write/deploy some small app in 1.11 before you do the port just so you are familiar with the changes)
[13:48] <bdx> also
[13:48] <bdx> skay, https://github.com/jamesbeedy/layer-django-base/blob/master/templates/django-gunicorn.service.tmpl
[13:49] <skay> bdx: I'm thinking for now I might get to 1.8 first, even though it ends next year
[13:49] <bdx> i use that^ works for python 2 or 3
[13:49] <skay> bdx: thanks
[13:49] <rick_h> skay: yea, I'm pretty sure maas took that route
[13:49] <skay> I'll take a look
[13:49] <rick_h> bdx: http://mitechie.com/blog/2017/9/28/learning-to-speak-juju for ya
[13:49] <rick_h> please spread far and wide :)
[13:50] <rick_h> will get it on insights in another couple of hours but I think it looks better on my blog :)
[13:50] <bdx> skay, heres the simple handler that writes it out https://github.com/jamesbeedy/layer-django-base/blob/master/reactive/django_base.py#L237,L247
[13:50] <skay> also, I inherited a juju1 charm written in bash that was from ages yore
[13:50] <bdx> rick_h: that is beautiful
[13:50] <skay> so basically I would like to dump it
[13:51] <rick_h> skay: ouch yea that's not really a migration but a rewrite there
[13:51]  * skay nods, sadly
[13:53] <bdx> skay: you found an artifact for the juju museum?
[13:53] <skay> if not that, then the juju hospice
[13:54] <bdx> skay: lets get you a fresh new juju 2 version and send that bad boy to the grave
[14:24] <skay> bdx: small comment. you have mutable args, and that is a gotcha. https://github.com/jamesbeedy/layer-django-base/blob/master/lib/charms/layer/django_base.py#L121
[14:25] <skay> http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments
[14:26] <bdx> that function is a dangler, I shoudl remove it
[14:26] <bdx> but thanks for the heads up on that
[14:27] <skay> yeah, I noticed it has a note for not used
[14:27] <skay> wasn't sure if it will be used in the future, etc
[14:27] <skay> anyway, scrub elsewhere too. I just noticed it in render_settings_py
[14:28] <skay> that gotcha bit me a while back
[14:28] <bdx> Im not sure I see the issue
[14:28] <bdx> thying to grok that ^ link now
[14:30] <bdx> ahh I see "This means that if you use a mutable default argument and mutate it, you will and have mutated that object for all future calls to the function as well."
[14:31] <skay> I think you may be okay since you are not mutating secrets unless I missed it
[14:31] <skay> but it's better never to use a mutable arg
[14:31] <bdx> yeah, Im see that
[14:31] <bdx> ok, well nice little wake up call
[14:31] <bdx> thanks @skay
[14:31] <bdx> I can go fix all my code now
[14:32] <bdx> I'm sure I have that everywhere
[14:32] <bdx> shoots
[14:32] <bdx> lol
[14:32] <skay> haha
[14:32] <rick_h> OSS ftw :)
[14:40] <bdx> skay: thanks again for pointing those out, I fixed up those in the django-base-layer
[14:59] <skay> bdx: this is handy. I'm learning about actions.
[14:59] <bdx> skay, yeah that update-app action comes in really handy for sure
[14:59] <skay> bdx: also, I may have a small PR to tidy something. for gen_short_sha_for_current_comment you could use git rev-parse --short HEAD, so perhaps you could merely pass a short=True to the other method. any objection/comment?
[15:00] <skay> bdx: it's not critical.
[15:01] <bdx> skay: those django layers are new, I'm working on them daily - would gladly accept pull requests
[15:01] <bdx> skay: theres a lot of ground to cover with django .... its so open ended that it makes making an opinionated charm difficult
[15:02] <bdx> but my basic goal is to come up with some best practices for making it more extensible
[15:02] <bdx> the settings files are one thing
[15:03] <bdx> the way I have a separate file for each thing, then the templates/settings.py.tmpl has to track those imports
[15:03] <bdx> at the bottom
[15:04] <bdx> I think a better way would be to write all juju generated settings files to a "juju_django_settings/" directory
[15:04] <bdx> then glob all the files *.py in that dir
[15:04] <bdx> or something to that affect
[15:05] <bdx> skay: I'm working on getting a protocol going for things like that
[15:05] <bdx> but yeah, send some me prs
[15:07] <skay> bdx: do you need the long git sha for any reason? perhaps just use the short one all the time
[15:07] <bdx> yeah, so thats kind of a personal thing we can remove
[15:07] <bdx> I use to like to have a REVISION file in my project root
[15:07] <bdx> that contained the full sha
[15:08] <bdx> it just kind of became a practice of mine a worked its way into the charm
[15:08] <skay> I've got a thing that runs bzr revno (actually it's in that old charm)
[15:08] <bdx> I dont really use it anymore, and its just hanging out, so we can nix it
[15:08] <skay> so I know what you mean I think
[15:08] <skay> hey, it's informative
[15:09] <skay> at least keep the log line
[18:31] <zeestrat> Hey rick_h, what's the status on getting bash autocompletion for snapped juju?
[18:32] <rick_h> zeestrat: not sure. balloons  any insight?
[19:01] <skay> rick_h: oh hey, you still around? how bad is this approach? I don't like it but if something like this works to support python2 use then I might suggest it https://github.com/codersquid/layer-wsgi/commit/448ba8d669f87328ee36512ba57c9cb2b3d86713
[19:03] <skay> rick_h: also, charmhelpers contrib has python package support, but with a limited set of options, so I can see why this layer is not using it
[19:11] <balloons> zeestrat, it's already there
[19:11] <balloons> zeestrat, it should be working for you
[19:14]  * rick_h uses zsh and missed it was working doh
[19:21] <balloons> rick_h, ahh.. well snap is landing support for all shells bash completion, we can 'upgrade' the snap to include support once it lands
[19:36] <zeestrat> balloons: Is there a trick to it with environment variables or something? Can't seem to get it to work on a clean 14.04 or 16.04 vm after "sudo snap install juju --classic". Tried logging in and out. snap version on both is 2.27.6
[19:36] <balloons> zeestrat, bash completion is a bit wonky honestly
[19:37] <balloons> zeestrat, I have had to source the completion script manually or ensure bash-completion is installed and running
[19:38] <balloons> it's /etc/bash_completion and /usr/share/bash-completion/completions/juju
[19:38] <zeestrat> balloons: Ah, installing bash-completion and relogging did the trick. That should be documented somewhere.
[19:39] <balloons> right, if you don't have bash completion, it won't work :-)
[20:47] <zeestrat> rick_h: Regarding https://github.com/juju/charmstore/issues/774, adding some extra-info to the charm store seems to be easy enough, but are there any fields that will be displayed on jujucharms.com? There used to be a revision box but I can't find that anymore.
[20:47] <rick_h> zeestrat: no, only the homepage and bugs url are shown.
[20:50] <zeestrat> rick_h: Alright. Is that a hard rule or can I put in a request somewhere?
[20:50] <rick_h> zeestrat: you can ask, what are you thinking?
[20:52] <zeestrat> rick_h: Was thinking about a commit tag or hash as mentioned in the issue.
[21:06] <zeestrat> rick_h: If I'm reading the issue correctly, that seems to be what the submitter is asking for to.