[Review Queue] OpenID/SSO, Charm Testing, and Queue Scrubbing
Happy 2015! I hope everyone new year is off to a good start. This week I spent some time on the following reviews: OpenID/SSO Subordinate Charm Nice charm from the PES Tools Certification Canonical team. My major comments were around adding tests and sprucing up the readme a bit. Pending adding charm tests this charm looks to be ready for a final review by a charmer and acceptance into the recommeded charm store. https://bugs.launchpad.net/charms/+bug/1396237 Pinged Marco on ensuring the following charms dropped out of the review queue: Trusty Lamp: https://bugs.launchpad.net/charms/+bug/1387467 Trusty pythin-django: https://bugs.launchpad.net/charms/+bug/1387465 The following charms had MPs for adding tests. https://code.launchpad.net/~marcoceppi/charms/precise/seafile/tests/+merge/240964 https://code.launchpad.net/~marcoceppi/charms/precise/opentsdb/tests/+merge/240984 https://code.launchpad.net/~marcoceppi/charms/precise/thinkup/tests/+merge/240894 https://code.launchpad.net/~mbruzek/charms/precise/newrelic-php/tests/+merge/240983 https://code.launchpad.net/~tvansteenburgh/charms/trusty/rabbitmq-server/add-amulet-test/+merge/245766 https://code.launchpad.net/~nicopace/charms/trusty/rabbitmq-server/10-outofthebox-testing/+merge/245871 Even though the charm is failing tests I suggest to accept these charm test MP for the reasons listed in the MPs. My overall reasoning is as follows: 1. A test is still valid even if the results aren't positive. 2. Having charm tests provides the first step to helping the charm author and community fix the charm. Specifically by providing a reproducible failure. 3. The tests are seed (basic) tests that an interested person can build off of. 4. As fixes are made to this charm automating charm testing will be able to run additional tests in addition to charm proof. 5. Having basic tests, as demonstrated here, helps ensure the charm is in a working (deployable) state given this charm is a recommended charm. A test failure can prompt a bug the charm author can take action on. The charm author may not have been aware of the bug had the charm not had even basic deployment tests. I also added specific comments for each MP. In discussion with ~charmers in #juju the folks who responded were a +1 as long as the test itself was valid and not missing any config values since the tests were auto-generated. thanks, -- Antonio Rosales Juju Ecosystem Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
django-python upgrade questions
I need to have upgrade functionality for this charm. I'm not experienced with writing hooks, so I want to check my assumptions and ask questions. Here begins the wall of text. During install, configure_and_install[1] is called in the install hook to install Django and, optionally, South. configure_and_install is handling concerns that I think would be better to split out. Here is the current logic: * if the user specifies a ppa, it will add the ppa * if the user specifies a key, it will add the key * if the method is somehow called with an empty string, it bails * otherwise it defaults to pip I think it would be better to break this up. Adding apt repositories and keys should be done separately. Config items could be added for a ppa list and a key list. Install could check for those and add them regardless of any django or south concerns. Django and South versions/distro/whatever would proceed separately. This makes upgrade simpler, I think. Upgrade would have similar steps to install, but I have a question about idempotence when adding apt repositories and keys. Are those idempotent? If not, then refactoring them out of that method makes it easier to idempotently handle Django and South dependencies. Now on to general plans for upgrade hook. It needs these to be added, but I want to know if my assumptions are mistaken: * ability to pull new src * ability to upgrade django and south * ability re-inject settings And one general observation I have -- if I could remove some of the options this charm allows, it would be easier to deal with. e.g. not give many options for how packages are installed. Force people to do it only one way. Pick a recommended practice and stick with it. I recommend taking a look at what audryr and pydanny suggest, but ultimately, whatever devops people decide to want, I will roll with it. but pick one way. To sum up, if you reached this far, I'd really like for my assumptions to be checked and corrected. Help! Thanks! Ps. as a side note, you can see some of the tiny incremental changes I'm thinking about in my branch[2]. I need to have the ability to install a project from a tarball due to lack of access. I'm not sure I will ultimately request any merge for tarball functionality as it is really janky. but it's what I have to work with based on what we've been doing at work. [1] http://bazaar.launchpad.net/~charmers/charms/trusty/python-django/trunk/view/head:/hooks/hooks.py#L151 [2] https://code.launchpad.net/~codersquid/charms/trusty/python-django/tgz-projects -- she...@pobox.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: goamz status / going forward
On 9 January 2015 at 02:52, Andrew Wilkins andrew.wilk...@canonical.com wrote: On Fri, Jan 9, 2015 at 3:13 AM, Dimiter Naydenov dimiter.nayde...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, FYI, I had a chat with Gustavo yesterday about goamz - workflow on github, reviews, maintenance, collaboration with the community, merging existing forks, etc. Here's a summary of the most important points and decisions: 0. The v2-dev branch will land tomorrow or on Monday at the latest, so both networking and storage work can be unblocked. 1. Most of the existing goamz contributors (rogpeppe, mgz, katco, wallyworld, axw) asked if they are willing to give a hand with reviews / maintenance initially. We aim to attract and involve more external users and community members which know EC2/AWS and care enough about goamz to become maintainers. 2. I'm preparing a CONTRIBUTING.md file with guidelines, and there will also be an AUTHORS.md listing all contributors. External contributors will need to sign the Canonical CLA. 3. Ensure all of the code is LGPLv3 licensed and make copyright headers consistent (Gustavo suggested removing his name from Written by ..). 4. Bug tracking will happen on Github only - existing relevant bugs from LP will be migrated as GH issues and the wiki page / docs updated to reflect this. 5. We'll use semantic versioning for branches (v1, v2, etc.) and releases (tags like v2.1.0) and following Go and gopkg.in guidelines to decide when to bump the version. 6. In general the workflow for contributing will be the same as juju-core (one +1 and no -1 from an official maintainer to merge), but reviews will happen on Github's Pull Requests, not reviewboard. 7. When integrating code from other forks, we need to ensure (as reviewers/maintainers) that what goes in is reasonable, consistent with the rest of the code, has tests and proper comments/docs. The suggestion to fast-forward the integration by pulling in code in exp/ or contrib/ initially (with the intent to clean it up / polish it later and promote it to a production-grade package) is not going to work and should be avoided (as for example the exiting exp/ package - it never got any serious attention or maintenance). Sounds good, thanks Dimiter. +1 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
