| erik_lonroth | rick_h: Did you write this? http://mitechie.com/blog/2017/9/28/learning-to-speak-juju | 07:05 |
|---|---|---|
| zeestrat | erik_lonroth: Yeah, that's Rick. | 07:24 |
| erik_lonroth | its super! | 07:26 |
| rick_h | erik_lonroth: thank you | 10:50 |
| rick_h | erik_lonroth: zeestrat please make sure to share it along. | 10: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) | 12:54 |
| rick_h | ed____: you should be able to juju destroy-machine --force | 13:14 |
| ed____ | thank you Rick, I'll give it a try | 13:31 |
| ed____ | yay :) it worked. Thank you Rick | 13:39 |
| 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:40 |
| skay | I like the idea of using a wsgi layer, but I can't upgrade my application right now | 13:41 |
| 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:44 |
| 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:45 |
| 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:46 |
| skay | rick_h: oh hey, have of them written an epic of their journey past 1.6 and deployment gotchas? | 13:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| rick_h | skay: ouch yea that's not really a migration but a rewrite there | 13:51 |
| * skay nods, sadly | 13:51 | |
| bdx | skay: you found an artifact for the juju museum? | 13:53 |
| skay | if not that, then the juju hospice | 13:53 |
| bdx | skay: lets get you a fresh new juju 2 version and send that bad boy to the grave | 13:54 |
| 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:24 |
| skay | http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments | 14:25 |
| bdx | that function is a dangler, I shoudl remove it | 14:26 |
| bdx | but thanks for the heads up on that | 14:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| bdx | skay: thanks again for pointing those out, I fixed up those in the django-base-layer | 14:40 |
| 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? | 14:59 |
| skay | bdx: it's not critical. | 15:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| bdx | skay: I'm working on getting a protocol going for things like that | 15:05 |
| bdx | but yeah, send some me prs | 15:05 |
| 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:07 |
| 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:08 |
| skay | at least keep the log line | 15:09 |
| === rogpeppe1 is now known as rogpeppe | ||
| zeestrat | Hey rick_h, what's the status on getting bash autocompletion for snapped juju? | 18:31 |
| rick_h | zeestrat: not sure. balloons any insight? | 18:32 |
| 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:01 |
| 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:03 |
| balloons | zeestrat, it's already there | 19:11 |
| balloons | zeestrat, it should be working for you | 19:11 |
| * rick_h uses zsh and missed it was working doh | 19:14 | |
| 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:21 |
| 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:36 |
| balloons | zeestrat, I have had to source the completion script manually or ensure bash-completion is installed and running | 19:37 |
| 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:38 |
| balloons | right, if you don't have bash completion, it won't work :-) | 19:39 |
| 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:47 |
| 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:50 |
| zeestrat | rick_h: Was thinking about a commit tag or hash as mentioned in the issue. | 20:52 |
| zeestrat | rick_h: If I'm reading the issue correctly, that seems to be what the submitter is asking for to. | 21:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!