launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

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.

jml