← Back to team overview

launchpad-dev team mailing list archive

Re: Yellow Squad Weekly Retrospective Minutes: June 22


On Mon, Jun 25, 2012 at 10:33 PM, Gary Poster <gary.poster@xxxxxxxxxxxxx> wrote:
> 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.

Yeah, that's worth adding,

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

Discussion in document is great. Comment or edit at will. Let me know
if you'd like someone else to be granted edit permissions.

>> 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.

I'm too much of an ignoramus to have an informed opinion. My one and
only charm gets by without it, and thus the principle of least
privilege applies.

>>> 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!

Cool. Will check them out. FWIW, we're caring less and less about
lucid now as we start migrating our machines to precise.


Follow ups