[00:00] <hazmat> adam_g, there are also images available in other regions if you'd prefer till such time
[00:04] <adam_g> hazmat: hmm, well the us-east-1 archive mirror seems to be broken ATM. ive hacked providers/ec2/launch.py a bit so i can bootstrap oneiric from trunk
[00:04] <adam_g> mirror for natty, that is
[13:15] <hazmat> g'monring
[13:36] <niemeyer> Bom dias
[13:57] <hazmat> niemeyer, greetings
[13:57] <niemeyer> hazmat: Hey
[13:59] <hazmat> niemeyer, i think i'm going to switch the sans-ami branch back to what you approved, just addressing the review comments, and put the work for ben's in a separate branch, i'd like to get this feature in this week.
[13:59] <hazmat> bcsaller, does that sound good?
[14:00] <niemeyer> hazmat: Sounds good.  How far is it from getting the next few things in?
[14:00] <niemeyer> hazmat: This will be important for us next week too
[14:00] <niemeyer> hazmat: I mean, the actual branch, not the further chnages
[14:02] <hazmat> niemeyer, i'd like to land it today
[14:02] <hazmat> niemeyer, maybe 20m for the changes from your review
[14:03] <niemeyer> hazmat: Ah, cool
[14:03] <hazmat> the additional distro selection, ensemble source selection, i'd think early next week, in review monday
[14:03] <niemeyer> hazmat: What's the distro selection about?
[14:03] <niemeyer> hazmat: That wasn't entirely clear for me, because there are a few different perspectives on it
[14:03] <hazmat> niemeyer, being able to select what release of ubuntu you want to use for your image
[14:03] <niemeyer> hazmat: Hmm
[14:03] <hazmat> its an image selection filter
[14:04] <niemeyer> hazmat: Do we really want that?
[14:04] <niemeyer> Hmm
[14:04] <hazmat> defaults to using what's current on the machine running the admin tools, but can be selected per environment 
[14:04] <hazmat> niemeyer, i think so, the caveat is we probably need a 10.10 selection or higher atm due to cloud-init feature changes (workarounds for which we have removed)
[14:05] <niemeyer> hazmat: This isn't clear to me
[14:05] <niemeyer> hazmat: Formulas target a specific release
[14:05] <niemeyer> hazmat: We shouldnt' be selecting the machine.. we should select the formula
[14:07] <hazmat> i see what you mean, sounds good, we'll need to capture this release metadata for image selection, i assume we'll be deploying formulas from multiple releases in an environment.
[14:09] <niemeyer> hazmat: Yeah, we'll have to handle multiple releases
[14:10] <niemeyer> hazmat: The metadata is in the repository too
[14:10] <niemeyer> hazmat: Not sure about the proper way to do it
[14:26] <hazmat> niemeyer, same mechanism i was about to expose to the end user
[14:43] <niemeyer> hazmat: How do you mean?
[14:55] <bcsaller> hazmat: I am fine with the other part of that branch coming later
[14:59] <hazmat> niemeyer, image selection encoded as formula metadata, a machine placement alg, using the formula metadata, via kw arg/image/machine type selection on the launch machine api of the provider interface, the low level is basically already done for ec2. it will be interesting to see what comes out of the sprint next week. we really need some cross-provider way of specing machine size.
[14:59] <hazmat> i'm curious if that sort of info is exposed via the orchestra api
[14:59] <hazmat> er. cobbler
[15:00] <niemeyer> Agreed.. but we need to sort out the distro selection first
[15:10] <hazmat> bcsaller, cool, could you update the merge proposal to reflect that
[15:10] <bcsaller> sure
[15:16] <hazmat> niemeyer, regarding upgrading formulas and removing files not in the new formula, for local state do we want to spec a location within the formula that we ignore, if we allow for formula contained state. 
[15:17] <niemeyer> hazmat: It feels wise to do so
[15:17] <hazmat> ie. ignore '/var' dir in a formula, before co-located formulas, i'd have said just stick it in the fhs somewhere.. its not clear that doesn't still work well but if we want to preserve the option
[15:17] <hazmat> of self-contained state
[15:17] <niemeyer> hazmat: Right
[15:18] <niemeyer> hazmat: There's another question regarding whether we should be killing things arbitrarily
[15:18] <niemeyer> hazmat: On upgrades
[15:18] <hazmat> realistically anything there installing is already on the machine. if we removal of a co-location, we'll need an uninstall hook perhaps.
[15:18] <niemeyer> hazmat: It feels like we should be more precise and only remove the files that disappeared from one version to the next
[15:18] <hazmat> s/we removal/we support removal
[15:19] <hazmat> niemeyer, we don't kill things for upgrades.. not sure what you mean?
[15:19] <hazmat> ah.. files
[15:20] <hazmat> niemeyer, yeah.. that supposes a notion of an install time manifest
[15:20] <hazmat> the formula dir manifest implementation is a dir walk
[15:20] <hazmat> ie always current
[15:25] <niemeyer> hazmat: We might even pick it out of the bundle
[15:32] <hazmat> niemeyer, sounds good
[15:32] <niemeyer> hazmat: The zip actually has the manifest already
[15:32] <niemeyer> hazmat: So it's just a matter of exploring it
[15:34] <hazmat> niemeyer, yup reusing the  local cache of downloaded formulas would simplify
[15:34] <niemeyer> hazmat: Hmm
[15:35] <hazmat> actually that will make it easier to support the upgrading against the same version
[15:35] <niemeyer> hazmat: I don't think we can trust the cache to be there, otherwise it stops being a cache
[15:35] <niemeyer> fwereade: Yo
[15:35] <fwereade> niemeyer, heyhey
[15:35] <hazmat> niemeyer, hmm. make sense, so we do need an install manifest and checksum recorded out of cache
[15:36] <fwereade> that was an unexpectedly gruelling many hours
[15:36] <fwereade> I'd forgotten what london is like
[15:36] <niemeyer> hazmat: Yeah, I think so
[15:36] <fwereade> but I think I'm actually ready to fly tomorrow
[15:36] <hazmat> fwereade, greetings
[15:36] <fwereade> heya hazmat
[15:36] <hazmat> fwereade, out of curiosity where are you normally based out of?
[15:37] <fwereade> hazmat, malta
[15:37] <hazmat> fwereade, nice
[15:37] <fwereade> yeah, it's lovely
[15:37] <hazmat> fwereade, care to help organize a sprint? ;-)
[15:37] <fwereade> whatever I can do to hlpe :)
[15:38] <fwereade> I can even spell things sometimes
[15:38] <fwereade> what do you need from me?
[15:44] <hazmat> fwereade, not much, but its not in the cards atm, we've got a couple sprint scheduled for the next few months.
[15:46] <fwereade> hazmat: cool, as long as it's not for Monday :p
[15:46] <niemeyer> hazmat: So, just to make sure, is the branch going in soonish?
[15:47] <niemeyer> hazmat: Just asking because Dustin mailed me about it
[15:47] <fwereade> hazmat: but in principle I'm happy to help however I can, just let me know
[15:47] <hazmat> niemeyer, i hope to have all my approved branches in by end of day
[15:48] <hazmat> which should solve most of the immediate issues jcastro brought up last week
[15:51] <hazmat> niemeyer, what do you think about closing out this milestone and setting up a new one
[15:51] <niemeyer> hazmat: I'd like to close it in the sprint in Austin, as originally planned
[15:51] <hazmat> niemeyer, sounds good
[15:51] <niemeyer> hazmat: There is still very important work that didn't land
[15:52]  * niemeyer looks at bcsaller
[15:52]  * bcsaller nods
[15:54] <niemeyer> hazmat: I'd also hope that simplistic pieces of the security work see the light of the day there
[15:54] <hazmat> niemeyer, hmm... i could start, but the spec still needs discussion
[15:54] <hazmat> niemeyer, what do you think about team conf call to discuss
[15:54] <hazmat> security
[15:55] <niemeyer> hazmat: Sounds good
[15:55] <niemeyer> I need lunch now, though
[15:56] <niemeyer> hazmat: Please feel free to book a time for us today
[15:56] <hazmat> niemeyer, sounds good cheers
[16:06] <m_3> Aaargh.... launchpad!
[16:07] <m_3> SpamapS: I need some repo naming help when you get back
[16:32] <kim0> o/ I'd like to see many Enmseble related sessions in Ubuntu cloud days → Please add a session to https://wiki.ubuntu.com/UbuntuCloudDays/Timetable
[16:46] <SpamapS> m_3: pong, got a few minutes now, sup?
[16:47] <niemeyer> SpamapS: Hey man
[16:48] <SpamapS> niemeyer: greetings earthling. :)
[16:48] <niemeyer> SpamapS: Re. the LXC work, we need a specification that describes what is the intended operating semantics and the way we want it to impact the several areas
[16:48] <niemeyer> SpamapS: Are you interested in championing it?
[16:49] <SpamapS> niemeyer: yeah thats a good idea. I already threw it together in my head. ;) just need to spit it out in rst :)
[16:49] <niemeyer> SpamapS: ... and get agreements :)
[16:49] <SpamapS> niemeyer: Its impact on anything except itself is *minimal*, and mostly involves fixing bugs
[16:49] <niemeyer> SpamapS: That's awesome
[16:50] <SpamapS> Though eventually I'm sure the LXCControl class I created would be useful for the separation work that is desired in the unit agents.
[16:52] <SpamapS> niemeyer: in fact I've gotten it all separated into branches which I'll propose for merging next week along w/ the bugs that are fixed
[16:53] <niemeyer> SpamapS: I'd appreciate reviewing the high-level problem first
[16:53] <SpamapS> niemeyer: meanwhile the spec for the provider and such can be subject to review separately
[16:53] <niemeyer> SpamapS: As we discussed over the sprint last week, there are a few different ways it can be made to work
[16:53] <SpamapS> niemeyer: the only bugs are things that were implemented in the ec2 provider that should be common to all providers.
[16:53] <niemeyer> SpamapS: So we should start by agreeing on which way we want it to
[16:54] <niemeyer> SpamapS: That's certainly neat no matter what
[16:54] <niemeyer> SpamapS: In fact, we'll have to do exactly that next week
[16:54] <niemeyer> SpamapS: So if you have well tested code splitting it off, I'd _love_ to have those available next week
[16:54] <niemeyer> SpamapS: Otherwise we'll be redoing that work again
[16:54] <SpamapS> niemeyer: sure, I don't have strong feelings about the ways it should work internaly. I just want to have a provider that works w/o amazon, and, preferrably, one that works w/o any net connection at all.
[16:55] <niemeyer> SpamapS: Right, +1 on that
[16:55] <niemeyer> SpamapS: The issue is not just internally, though
[16:55] <niemeyer> SpamapS: as we talked, the initial approach was to have a LXC representing a machine
[16:55] <niemeyer> SpamapS: We really want to have LXC representing a unit
[16:57] <SpamapS> niemeyer: yes, I'm perfectly fine with deprecating what I've already done once that work is ready.
[16:57] <niemeyer> SpamapS: Well, rather than deprecating what you do, I'd prefer to integrate what you do as a goal. :-)
[16:57] <niemeyer> SpamapS: Which is why, in general, it's important to have a spec and to debate a bit before actually diving in
[16:57] <SpamapS> niemeyer: that is, IMO, much more important to long term goals, and so, should be done more carefully. This provider is the way forward w/o touching ensemble's core functionality.
[16:58] <SpamapS> Its my little runt.. cute, but I don't expect it will live as long as its stronger brothers. :)
[17:00] <SpamapS> niemeyer: anyway, agreed, no more working on it until there's a spec and a gooddiscussion
[17:01] <SpamapS> niemeyer: anyway I need to run out now. Are any of the ensemble team going to attend the LXC sprint in Austin? I'll be there.
[17:01]  * SpamapS will read the answer to that later.. 
[17:01] <niemeyer> SpamapS: Yeah, we'll be there
[17:01] <SpamapS> ciao!
[17:01] <niemeyer> SpamapS: Cheers!
[17:24] <m_3> SpamapS: hey man
[17:25] <m_3> SpamapS: just having problems pushing stuff to lp
[17:26] <m_3> SpamapS: I think I've gotten some things pushed into other places coincidentally b/c there are already packages in oneiric with those names
[17:27] <m_3> SpamapS: but then I saw jamespage's pushes and totally lost any understanding I thought I'd gained
[17:27] <m_3> lp:~jenkins-formula-dev/principia/oneiric/ensemble/jenkins-slave
[17:27] <m_3> that one works in both 'principia' and 'ensemble' yet no 'trunk'
[17:28] <m_3> I'll just put it in +junk for now
[17:28] <m_3> no biggie
[19:25] <niemeyer> Borked
[19:26] <niemeyer> hazmat, bcsaller, jcastro, fwereade: Fail
[19:26] <hazmat> niemeyer, we're still on, can you rejoin?
[19:26] <bcsaller> niemeyer: I sent an invite 
[19:51] <hazmat> doh.. chrome crash
[19:52] <bcsaller> hazmat: if you can't see the link let me know
[19:52] <hazmat> bcsaller, dont' see it
[19:52] <hazmat> bcsaller, go tit
[19:52] <hazmat> er. got it
[19:54] <bcsaller> that worked pretty well
[20:07] <hazmat> bcsaller, agreed, that was fun
[20:08] <Ryan_Lane> hi guys. what's the license of the project?
[20:09] <hazmat> Ryan_Lane, AGPL for the core
[20:09] <Ryan_Lane> any specific license for formulas?
[20:09] <Ryan_Lane> anything AGPL compatible?
[20:09] <hazmat> Ryan_Lane, formulas licensed per individual authors wishes.. canonical formulas are like to be GPL afaics
[20:09] <Ryan_Lane> it isn't very clear in the documentation
[20:10] <hazmat> Ryan_Lane, indeed, perhaps even propretiary.. its a separate process
[20:10] <Ryan_Lane> no license is listed on launchpad either.
[20:10] <hazmat> hmm
[20:11] <hazmat> fixed re launchpad for ensemble
[20:12] <Ryan_Lane> great. thanks :)
[23:10] <pindonga> ac
[23:45] <_mup_> ensemble/trunk r266 committed by kapil.thangavelu@canonical.com
[23:45] <_mup_> merge sans-ami [r=bcsaller,niemeyer][f=803852]
[23:45] <_mup_> Enables the use of ensemble with standard ubuntu amis instead of pre-built images, 
[23:45] <_mup_> along with installation from the ensemble ppa as the default, while allowing 
[23:45] <_mup_> option of source install from lp branches.
[23:46] <adam_g> nice :)
[23:55] <_mup_> ensemble/trunk r267 committed by kapil.thangavelu@canonical.com
[23:55] <_mup_> merge hook-with-formula-dir [r=fwereade,niemeyer][f=761015]
[23:55] <_mup_> Hooks now execute in the formula directory. The formula directory
[23:55] <_mup_> can be referenced in hooks as environment variable ENSEMBLE_FORMULA_PATH
[23:57] <adam_g> nice x2