On Mon, Jun 25, 2012 at 10:33 PM, Gary Poster <gary.pos...@canonical.com> wrote: > On 06/25/2012 05:39 AM, Jonathan Lange wrote: >> On Fri, Jun 22, 2012 at 10:12 PM, Gary Poster <gary.pos...@canonical.com> >> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
