[New Charm] iPython Notebook available for testing
Hi All, Following a request from a friend doing data science training I took some time to release an early and very simple iPython Notebook Server charm. I welcome additions, bugs from both Launchpad and GitHub: * https://github.com/SaMnCo * https://code.launchpad.net/~samuel-cozannet/charms/trusty/ipython-notebook/trunk I only tested it locally and on AWS so far. If someone is happy to deploy on Rackspace and tell me if OK I could use that help. Don't hesitate to fire an email to tell me about features you'd like or missing libraries. I just uploaded it to the charmstore to my personal namespace so give it a few minutes for the GUI. You can already install it with : juju deploy cs:~samuel-cozannet/trusty/ipython-notebook juju expose ipython-notebook then browse to https://unit-ip Let me know your thoughts, Enjoy, Best, Samuel -- Samuel Cozannet Cloud, Big Data and IoT Strategy Team Strategic Program Manager Changing the Future of Cloud Ubuntu http://ubuntu.com / Canonical http://canonical.com UK LTD samuel.cozan...@canonical.com +33 616 702 389 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
python-django charm questions
Hi all, I'm working with the assumption that the pure-python fork of python-django will be in trunk soon, and will be around until the ansible reboot fork replaces it. If this is a bad assumption, let me know. There are some nice to haves that I'd like to have in the python-django charm before the ansible reboot hits. Since I'm new to juju and to charming things, I'd like sanity checks before I start proposing changes. I'm using a personal fork for now. Pip wishes * pip_extra_args support so that I can use --no-index --find-links=/path/to/wheels (this is in my fork) * remove --upgrade --use-mirrors, leave it up to the user (in my fork) Django wishes * call collectstatic (in my fork). I see a pending MR with something like this, but it enforces dj-static, which I would not do. * allow installing from tgz (in my fork) * fail on install/config changed if django-admin.py is not found. discovered this doesn't happen when it isn't installed, while working on the pip changes. otherwise it fails (in my fork) * allow users to inject custom templates. e.g. conditionally add django-debug-toolbar based on DEBUG. Newbie Questions * My fork adds a couple of lines to website_relation_joined_changed because the unit_name and port were not available to populate my apache2 template otherwise, but this could be due to user error. How do other people do this? * Why is django_extra_settings used in config_changed but not during install? -- she...@pobox.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: python-django charm questions
On 2 December 2014 at 17:04, sheila miguez she...@pobox.com wrote: Hi all, Pip wishes * pip_extra_args support so that I can use --no-index --find-links=/path/to/wheels (this is in my fork) * remove --upgrade --use-mirrors, leave it up to the user (in my fork) First class support for wheels in the charm would be good. Django wishes * call collectstatic (in my fork). I see a pending MR with something like this, but it enforces dj-static, which I would not do. Right, I think this is my branch, which was to get a demo working. Although, we do use dj-static in prod (with squid in front) and it works great, same solution in dev/prod, and fast (assuming squid or similar). AIUI, th alternatives are to a) deploy to alt service (cdn, apache, whatever), which means deploying to two targets, which I prefer not to do, or b) running apache/nginx on the django units to serve. But, in our deployments, static assets are always accelerated by squid or similar, so there's not much benefit to b. * allow installing from tgz (in my fork) So, the django charm allows more extensive customisation via a subordinate charm. This means you can write your own subordinate charm, bundle/fetch your tgz as appropriate, control your own settings.py, etc. You relate it to the django charm, and it supplies the needed info to the django charm, which will do the rest. I think this is generally a good route to go, as a single django charm cannot reasonably support every deployment option under the sun. That being said, I haven't personally used this feature, not am I the maintainer, so Patrick may have more to add, or correct me. * fail on install/config changed if django-admin.py is not found. discovered this doesn't happen when it isn't installed, while working on the pip changes. otherwise it fails (in my fork) Yeah, failing hard with good logs is always good. * allow users to inject custom templates. e.g. conditionally add django-debug-toolbar based on DEBUG. You mean settings.py templates? You can do that with the custom subordiate above. Newbie Questions * My fork adds a couple of lines to website_relation_joined_changed because the unit_name and port were not available to populate my apache2 template otherwise, but this could be due to user error. How do other people do this? Is your fork available to view? Which apache2 template are you referring to? One in your fork, or the apache charm? This sounds odd, as the http relation type should expose 'port' and 'hostname' variables, with hostname usually defaulting to the unit name. When I've used the django charm, this worked as expected. * Why is django_extra_settings used in config_changed but not during install? I expect that's a bug. -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] owncloud, and transcode
Today in the Review Queue I reviewed the following: Promote owncloud charm to trusty: https://bugs.launchpad.net/charms/+bug/1389078 The maintainer added tests but Amulet tests default to the precise series. I made a small change to get it to pass the tests: amulet.Deployment(series='trusty') Once the tests passed I promulgated the owncloud charm for trusty. Adding tests to transcode: https://code.launchpad.net/~marcoceppi/charms/precise/transcode/tests/+merge/240890 This charm had a bundle in the charm directory that is incorrect and caused the tests to fail. I moved the bundle to a bundles directory and the charm tests passed. I merged the charm with these changes. Thanks, - Matt Bruzek matthew.bru...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: python-django charm questions
On 03/12/14 06:38, Simon Davy wrote: On 2 December 2014 at 17:04, sheila miguez she...@pobox.com wrote: * Why is django_extra_settings used in config_changed but not during install? I expect that's a bug. The config_changed hook is called after the install hook when first installing. Tim -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: python-django charm questions
On Tue, Dec 2, 2014 at 11:38 AM, Simon Davy bloodearn...@gmail.com wrote: On 2 December 2014 at 17:04, sheila miguez she...@pobox.com wrote: Hi all, Pip wishes * pip_extra_args support so that I can use --no-index --find-links=/path/to/wheels (this is in my fork) * remove --upgrade --use-mirrors, leave it up to the user (in my fork) First class support for wheels in the charm would be good. Cool! I will make a MR when the pure-python branch lands. I'll probably pop up in #juju if I can't figure out how to test charms properly before asking for review. Django wishes * call collectstatic (in my fork). I see a pending MR with something like this, but it enforces dj-static, which I would not do. Right, I think this is my branch, which was to get a demo working. Although, we do use dj-static in prod (with squid in front) and it works great, same solution in dev/prod, and fast (assuming squid or similar). AIUI, th alternatives are to a) deploy to alt service (cdn, apache, whatever), which means deploying to two targets, which I prefer not to do, or b) running apache/nginx on the django units to serve. But, in our deployments, static assets are always accelerated by squid or similar, so there's not much benefit to b. This makes sense. I went with dj-static too, but figured people might want to have the option not to. I can hold back making a MR for this in case it is not in line with the project goals. * allow installing from tgz (in my fork) So, the django charm allows more extensive customisation via a subordinate charm. This means you can write your own subordinate [more on subordinate charming] This makes more sense than my changes to add tgz. I used the charm that way based on ignorance. * fail on install/config changed if django-admin.py is not found. discovered this doesn't happen when it isn't installed, while working on the pip changes. otherwise it fails (in my fork) Yeah, failing hard with good logs is always good. I need to double check my assumptions. Patrick mentioned a case where it shouldn't fail, but I'm questioning that. I'll trace through the charm carefully before making a MR here. Newbie Questions * My fork adds a couple of lines to website_relation_joined_changed because the unit_name and port were not available to populate my apache2 template otherwise, but this could be due to user error. How do other people do this? Is your fork available to view? No, I made a mistake and committed it to a private team when it doesn't have any private information. Sorry about that. Which apache2 template are you referring to? One in your fork, or the apache charm? The apache charm in the charm store. This sounds odd, as the http relation type should expose 'port' and 'hostname' variables, with hostname usually defaulting to the unit name. When I've used the django charm, this worked as expected. I bet this is a user error on my part. * Why is django_extra_settings used in config_changed but not during install? I expect that's a bug. I can look in to it and make a MR when I have a chance. This might take me longer than doing the others. Thanks very much for the answers! The channel and the mailing list have been great. -- she...@pobox.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Dear reviewers,
Hello there reviewers, I have a number of concerns around reviews that I need to say. Firstly, as an on call reviewer, you only need to look at the reviews that have not yet been looked at. If you ask for changes on a branch as a reviewer, you have a responsibility to respond to the developer when they make said changes or they ask for clarification. As a developer it is your responsibility to get your branch landed. Don't just throw it over the review fence and think you are done. Please be pragmatic when using the errors library. It doesn't make sense to have it on absolutely every error return. It can be helpful, but it isn't a requirement to be everywhere. As a developer, consider annotating errors when it makes sense and tracing where appropriate. As a reviewer, please don't expect it everywhere. With respect to string literals: if it is used once, inline is fine; twice is borderline; more than twice and there should be a (hopefully documented) defined constant. The constant should have a meaningful name, not obscure. Thank you, Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Dear reviewers,
On 03/12/14 13:34, Tim Penhey wrote: Hello there reviewers, I have a number of concerns around reviews that I need to say. Firstly, as an on call reviewer, you only need to look at the reviews that have not yet been looked at. If you ask for changes on a branch as a reviewer, you have a responsibility to respond to the developer when they make said changes or they ask for clarification. +1 I know sometimes I forget to go back the next day and look at subsequent changes, hence As a developer it is your responsibility to get your branch landed. Don't just throw it over the review fence and think you are done. ... sometimes the developer needs to poke the reviewer and remind them to finish the review :-) Please be pragmatic when using the errors library. It doesn't make sense to have it on absolutely every error return. It can be helpful, but it isn't a requirement to be everywhere. As a developer, consider annotating errors when it makes sense and tracing where appropriate. As a reviewer, please don't expect it everywhere. +1 Let's be pragmatic and consider the situation. eg I would not expect trace to be required when returning an error at a layer boundary, but deep down inside some complex function, yes. With annotate, it may not be needed it an immediate caller annotates the error for example. So please use good judgement rather than a blanket insistence that trace and annotate be used everywhere. With respect to string literals: if it is used once, inline is fine; twice is borderline; more than twice and there should be a (hopefully documented) defined constant. The constant should have a meaningful name, not obscure. +100 for so many reasons -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Dear reviewers,
On Wed, Dec 3, 2014 at 11:43 AM, Ian Booth ian.bo...@canonical.com wrote: On 03/12/14 13:34, Tim Penhey wrote: Hello there reviewers, I have a number of concerns around reviews that I need to say. Firstly, as an on call reviewer, you only need to look at the reviews that have not yet been looked at. If you ask for changes on a branch as a reviewer, you have a responsibility to respond to the developer when they make said changes or they ask for clarification. +1 I know sometimes I forget to go back the next day and look at subsequent changes, hence As a developer it is your responsibility to get your branch landed. Don't just throw it over the review fence and think you are done. ... sometimes the developer needs to poke the reviewer and remind them to finish the review :-) Agree with prodding for PTAL. It doesn't make sense to push the burden onto everyone else. It seems reasonable to expect a branch with *no* reviews to receive them quickly - within a day or two, unless there is a glut of unreviewed branches. If you see a branch that hasn't been reviewed, please leave a comment about *why* you're not reviewing it (e.g. the branch is too big, is doing too much at once, etc.) Please be pragmatic when using the errors library. It doesn't make sense to have it on absolutely every error return. It can be helpful, but it isn't a requirement to be everywhere. As a developer, consider annotating errors when it makes sense and tracing where appropriate. As a reviewer, please don't expect it everywhere. +1 Let's be pragmatic and consider the situation. eg I would not expect trace to be required when returning an error at a layer boundary, but deep down inside some complex function, yes. With annotate, it may not be needed it an immediate caller annotates the error for example. So please use good judgement rather than a blanket insistence that trace and annotate be used everywhere. Yes. Otherwise we end up with could not do x: could not do x: could not do x: could not do x: x could not be done because reasons. Add enough information so that we can diagnose where errors came from to diagnose the root cause. Err on the side of adding more information than less, but be thoughtful about it: too much information will obscure things. Generally: if you're making a suggestion in a review, base that suggestion on the outcome and not on some arbitrary rule. With respect to string literals: if it is used once, inline is fine; twice is borderline; more than twice and there should be a (hopefully documented) defined constant. The constant should have a meaningful name, not obscure. +100 for so many reasons -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
