[07:05] rick_h: Did you write this? http://mitechie.com/blog/2017/9/28/learning-to-speak-juju [07:24] erik_lonroth: Yeah, that's Rick. [07:26] its super! [10:50] erik_lonroth: thank you [10:54] erik_lonroth: zeestrat please make sure to share it along. [12:54] 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] ed____: you should be able to juju destroy-machine --force [13:31] thank you Rick, I'll give it a try [13:39] yay :) it worked. Thank you Rick [13:40] np ed____ [13:40] 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] I like the idea of using a wsgi layer, but I can't upgrade my application right now [13:44] 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] skay: can you crib enough to make the layer-wsgi py2 compatible? [13:44] rick_h: I was wondering about that. would anyone other than me find it valuable? [13:45] skay: always default to "yes" on that one :P [13:45] haha [13:45] skay: you're not so special as to be the only one doing it hehe [13:45] just the only one asking about it out loud [13:46] 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] :( [13:46] ;_; cry [13:46] skay: hah, yea the MAAS folks I know had to put some big time into that move [13:47] rick_h: oh hey, have of them written an epic of their journey past 1.6 and deployment gotchas? [13:48] 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] 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] 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] also [13:48] skay, https://github.com/jamesbeedy/layer-django-base/blob/master/templates/django-gunicorn.service.tmpl [13:49] bdx: I'm thinking for now I might get to 1.8 first, even though it ends next year [13:49] i use that^ works for python 2 or 3 [13:49] bdx: thanks [13:49] skay: yea, I'm pretty sure maas took that route [13:49] I'll take a look [13:49] bdx: http://mitechie.com/blog/2017/9/28/learning-to-speak-juju for ya [13:49] please spread far and wide :) [13:50] will get it on insights in another couple of hours but I think it looks better on my blog :) [13:50] 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] also, I inherited a juju1 charm written in bash that was from ages yore [13:50] rick_h: that is beautiful [13:50] so basically I would like to dump it [13:51] skay: ouch yea that's not really a migration but a rewrite there [13:51] * skay nods, sadly [13:53] skay: you found an artifact for the juju museum? [13:53] if not that, then the juju hospice [13:54] skay: lets get you a fresh new juju 2 version and send that bad boy to the grave [14:24] 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] http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments [14:26] that function is a dangler, I shoudl remove it [14:26] but thanks for the heads up on that [14:27] yeah, I noticed it has a note for not used [14:27] wasn't sure if it will be used in the future, etc [14:27] anyway, scrub elsewhere too. I just noticed it in render_settings_py [14:28] that gotcha bit me a while back [14:28] Im not sure I see the issue [14:28] thying to grok that ^ link now [14:30] 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] I think you may be okay since you are not mutating secrets unless I missed it [14:31] but it's better never to use a mutable arg [14:31] yeah, Im see that [14:31] ok, well nice little wake up call [14:31] thanks @skay [14:31] I can go fix all my code now [14:32] I'm sure I have that everywhere [14:32] shoots [14:32] lol [14:32] haha [14:32] OSS ftw :) [14:40] skay: thanks again for pointing those out, I fixed up those in the django-base-layer [14:59] bdx: this is handy. I'm learning about actions. [14:59] skay, yeah that update-app action comes in really handy for sure [14:59] 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] bdx: it's not critical. [15:01] skay: those django layers are new, I'm working on them daily - would gladly accept pull requests [15:01] skay: theres a lot of ground to cover with django .... its so open ended that it makes making an opinionated charm difficult [15:02] but my basic goal is to come up with some best practices for making it more extensible [15:02] the settings files are one thing [15:03] the way I have a separate file for each thing, then the templates/settings.py.tmpl has to track those imports [15:03] at the bottom [15:04] I think a better way would be to write all juju generated settings files to a "juju_django_settings/" directory [15:04] then glob all the files *.py in that dir [15:04] or something to that affect [15:05] skay: I'm working on getting a protocol going for things like that [15:05] but yeah, send some me prs [15:07] bdx: do you need the long git sha for any reason? perhaps just use the short one all the time [15:07] yeah, so thats kind of a personal thing we can remove [15:07] I use to like to have a REVISION file in my project root [15:07] that contained the full sha [15:08] it just kind of became a practice of mine a worked its way into the charm [15:08] I've got a thing that runs bzr revno (actually it's in that old charm) [15:08] I dont really use it anymore, and its just hanging out, so we can nix it [15:08] so I know what you mean I think [15:08] hey, it's informative [15:09] at least keep the log line === rogpeppe1 is now known as rogpeppe [18:31] Hey rick_h, what's the status on getting bash autocompletion for snapped juju? [18:32] zeestrat: not sure. balloons any insight? [19:01] 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] 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] zeestrat, it's already there [19:11] zeestrat, it should be working for you [19:14] * rick_h uses zsh and missed it was working doh [19:21] 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] 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] zeestrat, bash completion is a bit wonky honestly [19:37] zeestrat, I have had to source the completion script manually or ensure bash-completion is installed and running [19:38] it's /etc/bash_completion and /usr/share/bash-completion/completions/juju [19:38] balloons: Ah, installing bash-completion and relogging did the trick. That should be documented somewhere. [19:39] right, if you don't have bash completion, it won't work :-) [20:47] 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] zeestrat: no, only the homepage and bugs url are shown. [20:50] rick_h: Alright. Is that a hard rule or can I put in a request somewhere? [20:50] zeestrat: you can ask, what are you thinking? [20:52] rick_h: Was thinking about a commit tag or hash as mentioned in the issue. [21:06] rick_h: If I'm reading the issue correctly, that seems to be what the submitter is asking for to.