launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On 06/25/2012 05:39 AM, Jonathan Lange wrote:
> On Fri, Jun 22, 2012 at 10:12 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
> ...
>>  * gary_poster: When starting a new project, look at our checklist and jml's
>>
>> We're officially starting a new stretch project now with lpsetup.  We
>> have our own tiny baby checklist for a project.  It also links to a
>> getting-fabulously-better-and-yet-ever-depressingly-larger checklist
>> that jml has been working on.
>>
>> The only real message in our checklist is "hey, prototypes are cool, and
>> competing prototypes especially.  And follow those other rules too,
>> whydoncha."  jml's is a lot more comprehensive (and he's looking for
>> help with automation, if you are interested!).
> ...
> 
> I'm not just looking for help with automation, I also want help with
> gathering existing practices, adding items I've forgotten, organizing
> it to be more useful and less overwhelming, figuring out how to make
> it work with projects like LP who have their own policies/shortcuts,
> and actually using it in anger to see what needs to change.

A lot of the first bits will come from using it, I think.  We're
referring to your list now in our own conversations and planning.  If
you added the prototype suggestion from our list I could just point to
your list for our own squad.  Even if not, you still have an active
audience from us.

Do you want discussion on the document, I'm guessing, rather than via
email?  I have a thought or two about some details already.

> 
> I think being able to create new projects easily and thoroughly is
> important because of the re-use/release equivalence principle:
>   http://stackoverflow.com/questions/63142/the-reuse-release-equivalence-principle-rep
>   http://www.objectmentor.com/resources/articles/granularity.pdf
> 
>>  * gary_poster: When apt-get fails...
>>
>> Our juju charm sometimes fails on ec2 with errors like this:
>> subprocess.CalledProcessError: Command '['apt-get', 'install', '-y',
>> '--force-yes', u'your-package-name']' returned non-zero exit status 100
> 
> As an aside, when I was doing my first Juju charm recently,
> #ubuntu-devel told me to avoid --force-yes, citing apt-get(8):
> 
>   This is a dangerous option that will cause apt to continue
>   without prompting if it is doing something potentially harmful.
>   It should not be used except in very special situations.
>   Using force-yes can potentially destroy your system

It's been months since we wrote those bits, so I don't know if this is
memory talking or something more creative and less factual.  However,
the thought I had when reading your comment and quote was that we knew
this, and we made the decision to use  consciously.

We are not setting up arbitrary machines.  We are writing charms,
designed to set up disposable virtual machines for a specific purpose.
If it is not able to perform that purpose, the virtual machine is
useless to us.

Under those circumstances, I think it is arguable that trying to force
the change is the right thing to do.  I'd rather increase the chance
that the charm will work, even if that introduces a more extreme
possible failure condition.

What do you think of that position?  The ~charmers reviewed our code at
one point and didn't object, but that doesn't imply a full blessing on
the idea itself.

>> It would be really nice to add this automation to the Python charm
>> helpers once they are packaged and usable (waiting on bug 1016588).
> 
> I didn't know there was such a thing. It would certainly help me, and
> probably help others, if the Golden Horde could wrie up all the things
> it learned about Juju and share it with their community.

We have two sets of tools that we've been waiting on merging for a long
time.  The first are Python charm-tools, which are approved, but need
some Lucid-friendly packaging magic...

https://code.launchpad.net/~gmb/charm-tools/add-charm-helpers
https://bugs.launchpad.net/charm-tools/+bug/1016588

...and they depend on python-shelltoolbox, a package that SpamapS has
been interested in promoting into Ubuntu.  It also needs some
Lucid-friendly packaging magic, AIUI, though it seems to be working for
us...not quite sure what the story is there TBH.

https://launchpad.net/python-shelltoolbox
https://bugs.launchpad.net/python-shelltoolbox/+bug/1016585

It's simple, but a nice set of code to have tested and available in
Python.  It's available in our PPA at the moment.

https://code.launchpad.net/~yellow/+archive/ppa

We hope that these will be more widely available soon!

> 
> 
> ...
>>  * gmb: Beware: global state hates you: doctest die in a fire part XXXII
>>
>> The doctest module mucks with stdout, stderr, and __stdout__ and
>> __stderr__ by its very nature.  This can make debugging particularly
>> unpleasant when you yourself are doing things with stdout and stderr.
>> Our solution was to convert doctests to unittests.  bac: The testtools
>> doctest matcher makes converting from doctest to unit test a lot easier.
>>
> 
> There's a minor gotcha here: testtools' DocTestMatches doesn't have
> any flags by default. Launchpad does.

Mm, good to file away, thanks.

Gary

> 
> jml