[01:26] <_mup_> ensemble/expose-provider-ec2 r278 committed by jim.baker@canonical.com
[01:26] <_mup_> Update mock expectations for launch
[01:32] <_mup_> ensemble/expose-provider-ec2 r279 committed by jim.baker@canonical.com
[01:32] <_mup_> Fix EC2MachineLaunchTest mocks
[01:39] <_mup_> ensemble/expose-provider-ec2 r280 committed by jim.baker@canonical.com
[01:39] <_mup_> Fix EC2BootstrapTest mocks
[01:46] <_mup_> ensemble/expose-provider-ec2 r281 committed by jim.baker@canonical.com
[01:46] <_mup_> Reuse security group listing
[03:58] <jimbaker> fwereade, glad in reading over it just now that your branch proposal is orthogonal to what i'm working on :)
[03:58] <jimbaker> looks like a nice change
[03:59] <fwereade> jimbaker, heh: it's actually a bit less horrifying thaan it looks
[03:59] <jimbaker> (i'm also touching the launch code, to manage security groups)
[03:59] <fwereade> ...but then I would say that, I've been breathing it all day ;)
[03:59] <fwereade> the security group stuff is totally untouched I think
[03:59] <jimbaker> fwereade, are you in miami?
[03:59] <fwereade> yeah
[03:59] <fwereade> it's nice :)
[04:00] <jimbaker> fwereade, cool. from one beachfront to another, i guess
[04:00] <fwereade> jimbaker, I actually came from the UK this time
[04:00] <jimbaker> fwereade, btw, i understand you worked on the ironpython c ext api work
[04:00] <fwereade> yeah, that was a lot of fun
[04:01] <fwereade> but babies are the great enemy of open source, as they say ;)
[04:01] <jimbaker> fwereade, cool. i work on jython. we plan to add that functionality sometime. probably next summer
[04:01] <fwereade> ah, nice
[04:01] <fwereade> definitely look me up
[04:01] <jimbaker> fwereade, oh sure. that's why i'm scheduling it out so far in advance ;) - i have 2 kids myself
[04:02] <fwereade> the last thing I did was a pile of abstraction intended to make that easier
[04:02] <fwereade> jimbaker, cool :)
[04:02] <fwereade> if I try really hard I might be able to remember how some of it works ;)
[04:02] <jimbaker> maciej gave me a nice rundown on his work last year to help on the pypy impl
[04:03] <fwereade> I seem to recall they took quite a different approach
[04:03] <jimbaker> but in general, it seems like cextapi is the right approach
[04:04] <fwereade> and frankly a better one... binary compatibility is kinda cool but it was never going to be a 100% solution
[04:04] <jimbaker> fwereade, i think the details will vary. we have a codegen system in place that we can leverage for jython
[04:04] <fwereade> jimbaker, excellent, we can put our respective codegen systems in a machine together and watch them fight it out
[04:05] <fwereade> take bets on the outcome :p
[04:05] <jimbaker> the more interesting question will be how to make cextapi lowcost
[04:06] <fwereade> I seem to recall that one thing that was especially painful in ironclad was chatty APIs with callbacks that kept having to set up managed contexts again and again
[04:07] <jimbaker> fwereade, there's a student working on invokedynamic support, it's looking quite promising for overall jython performance. for cextapi, it's about leveraging zerocopy with NIO bytebuffers and figuring out how to get the GIL cost down
[04:07] <fwereade> awesome
[04:07] <fwereade> I tried really hard to kill the GIL... no dice ;)
[04:08] <jimbaker> fwereade, yeah, i can see that as particularly bad. basically chattiness kills inlining
[04:08] <jimbaker> for the obvious reasons
[04:08] <fwereade> yep :)
[04:09] <fwereade> anyway, this has been a great day in which I keep losing track of time... but that then means I really must sleep ;)
[04:09] <fwereade> nn
[04:09] <jimbaker> fwereade, sounds good, take care!
[07:49] <kim0> Morning all
[10:46] <SpamapS> kim0: howdy
[10:46]  * SpamapS hasn't quite switched back to PDT yet :-P
[10:55] <kim0> SpamapS: hi there 
[10:55] <kim0> up early I guess
[10:55] <kim0> hehe
[10:56] <kim0> SpamapS: before the channel gets busy, is there any interesting topic you'd like to present in Cloud Days ?
[10:57] <SpamapS> kim0: ensemble seems like a good topic. ;)
[10:57] <kim0> hehe
[10:58] <kim0> I was thinking of doing a basic getting started with Ensemble, and Mark is doing node+mongo on ensemble
[10:58] <kim0> You can have the intro session if you want, or you can do something more exciting :)
[10:58] <kim0> SpamapS: You can add yourself to https://wiki.ubuntu.com/UbuntuCloudDays/Timetable
[11:00] <SpamapS> Yeah I'm just not sure what non-general topic should be covered.
[11:01] <kim0> SpamapS: do you know if orchestra is in a state that can be demo'ed somehow ?
[11:02] <SpamapS> kim0: no
[11:03] <SpamapS> and I'm hesitant to demo the LXC stuff I did because it may not ever see trunk in its current form.
[11:03] <kim0> well .. the people wouldn't see the code :)
[11:03] <kim0> it's just a demo
[11:05] <kim0> SpamapS: can I sign you up for LXC session, and you can change it later if you think of something else ?
[11:05] <SpamapS> no like, it won't even work the way I did it
[11:07] <kim0> ok np, I'm sure you'll find another cool topic :)
[11:07] <SpamapS> Dunno... seems like bad timing as everything is heavily in flux.
[11:08] <SpamapS> There are *tons* of formulas now tho.. that is quite interesting.
[11:08] <kim0> Yeah .. formulas are cool to demo :)
[11:09] <kirkland> SpamapS: yeah, i'm jetlaggin too
[11:09] <kirkland> kim0: actually, check with RoAkSoAx;  parts of orchestra are demo-able (even if the ensemble bits are not)
[11:09] <kim0> kirkland: thanks .. I sure will
[11:09] <kim0> RoAkSoAx: please ping me when you're up :)
[11:10] <kim0> wonder if Orchestra can be demo'ed on ec2 !
[11:10] <kirkland> kim0: certainly not the cobbler/pxe/install bits
[11:11] <kirkland> kim0: on ec2
[11:11] <kim0> I know someone who runs virtualbox on ec2
[11:11]  * kim0 scratches head
[11:12] <kim0> wasn't there some ajaxterm formula .. I think it'd be cool for such irc events .. cant find it in https://code.launchpad.net/principia
[11:17] <SpamapS> kirkland: ^^ you were working on byobu classroom weren't you?
[11:17] <kirkland> SpamapS: yeah, i was;  i'll finish it today, actually
[11:17] <kirkland> SpamapS: i'm giving a presentation in irc tomorrow
[11:17] <kirkland> SpamapS: and i'm planning on using that
[11:17] <kirkland> SpamapS: presentation is on dotdee
[11:18] <kirkland> SpamapS: but i'm going to point people to the URL/ajaxterm to watch
[11:25] <kim0> kirkland: I thought your dotdee session is today ? https://wiki.ubuntu.com/UbuntuDeveloperWeek
[11:25] <kirkland> kim0: so it is
[11:26] <kirkland> kim0: okay, i'll get right onto that formula :-)
[11:26] <kim0> hehe :)
[11:39]  * SpamapS looks at clock.. 4:40am .. to sleep, or not to sleep.. that is the question
[11:53] <kim0> life is too exciting to sleep!
[13:07] <koolhead17> SpamapS, don`t sleep :D
[13:07] <koolhead17> hello kim0 niemeyer and all :)
[13:08] <niemeyer> koolhead17: Yo!
[13:08] <niemeyer> koolhead17: How's it going?
[13:09] <RoAkSoAx> kim0: I'm here
[13:10] <kim0> koolhead17: hey o/
[13:10] <kim0> RoAkSoAx: Hey o/ 
[13:10] <koolhead17> niemeyer, am great. in love with buggy dbconfig-common
[13:10] <koolhead17> RoAkSoAx, hi :D
[13:10] <kim0> So we're having Ubuntu cloud days on the 25th-26th
[13:10] <RoAkSoAx> koolhead17: hi!
[13:10] <kim0> RoAkSoAx: Dustin was just telling me perhaps some parts of Orchestra might be ready for a demo
[13:10] <RoAkSoAx> kim0: \o/
[13:11] <kim0> can you dazzle the world with a session :)
[13:11] <RoAkSoAx> kim0: heh when?
[13:11] <koolhead17> RoAkSoAx, you had time to play with koan recently?
[13:11] <kim0> 25th or 26th :)
[13:11] <kim0> RoAkSoAx: here's the time tablet https://wiki.ubuntu.com/UbuntuCloudDays/Timetable
[13:11] <RoAkSoAx> koolhead17: yes
[13:11] <kim0> Would be awesome to grab a session
[13:12] <kim0> RoAkSoAx: I wonder if we can demo the pxe and deployment part somehow ?!
[13:12] <kim0> it's gonna be hard for sure
[13:12] <kim0> if that doesn't work .. feel free to demo any other part :)
[13:12] <koolhead17> RoAkSoAx, cool
[13:13] <kim0> RoAkSoAx: what say you 
[13:14] <RoAkSoAx> kim0: yeah I guess I could do that
[13:14] <kim0> Awesome! yipeee
[13:14] <RoAkSoAx> koolhead17: play with it every day
[13:14] <kim0> \o/
[13:14] <kim0> RoAkSoAx: so which part to demo .. or session title ?
[13:14] <koolhead17> RoAkSoAx, :D i need to learn a bit kvm/xen to do koan 
[13:14] <RoAkSoAx> kim0: I guess for that matter it would be cobbler rather than exactly orchestra
[13:15] <kim0> RoAkSoAx: still dazzling :)
[13:15] <kim0> RoAkSoAx: so please pick a session title
[13:15] <RoAkSoAx> kim0: ok, will do by the EOF as i'm gonna do a call in a bit
[13:16] <kim0> sure thing 
[13:16] <kim0> RoAkSoAx: thanks man .. cheers
[13:30] <jcastro> kirkland: ccze is that log prettyizer I showed you
[13:56] <kirkland> jcastro: awesome, thanks
[14:53] <niemeyer> Aram: Welcome!
[14:53] <Aram> hi!
[15:09] <robbiew> welcome Aram
[15:15] <SpamapS> RoAkSoAx: so did you guys give up on trying to use my branch? ;-)
[15:17] <fwereade> SpamapS, I fully expect to pull in all the meat from your branch, it's just the structure I've been going at with an axe ;)
[15:17] <fwereade> SpamapS, the pre-existing structure
[15:19] <fwereade> bzr diff
[15:23] <koolhead17> kim0, 
[15:24] <SpamapS> fwereade: awesome. :)
[15:24] <kim0> koolhead17: hey
[15:24] <SpamapS> fwereade: I'm glad you've got the fire in your belly necessary to blow apart that EC2 branch. It was a mess. :-P
[15:25] <fwereade> SpamapS, I love doing this sort of thing :)
[15:25] <fwereade> SpamapS, the tests seem really solid though, makes life *much* easier
[15:26] <fwereade> (and, ofc, we'll find out what assumptions I didn't even know I was making pretty soon ;))
[15:26] <koolhead17> kim0, do we have members from europe belin/athens/madris/rome
[15:26] <koolhead17> that way i could meet some of us
[15:26] <kim0> koolhead17: we? the global ubuntu community ?
[15:27] <SpamapS> fwereade: indeed.. ensemble has made me a believer in TDD ;)
[15:27] <kim0> I'm sure hell yeah :)
[15:27] <SpamapS> koolhead17: where are you based?
[15:27] <koolhead17> SpamapS, am from India. i am travelling to berlin for desktop summit and after that travelling to these places i mentioned earlier
[15:28] <koolhead17> i am thinking of having lug meetup in all the cities when i am there so that i can meet local linux folks
[15:28] <koolhead17> :P
[15:29] <SpamapS> koolhead17: By chance, most of the core ensemble devs are in the Americas somewhere. But there are tons of European Ubuntu folks. :)
[15:30] <koolhead17> SpamapS, yeah i know that. i am thinking of mailing the local lug for some meetup. let see if am lucky
[15:31] <RoAkSoAx> SpamapS: I did, though adding some bootstrap process at the moment
[15:32] <koolhead17> kim0, will we have ensemble logo in place soon. I would like to get it printed on my t-shirt :D
[15:32] <kim0> koolhead17: lol, robbie's one seems to be winning :)
[15:32] <RoAkSoAx> SpamapS: as discussed here with niemeyer , the idea is that ensemble bootstrap starts a new system that will run zookeeper as how it does it in ec2
[15:32] <koolhead17> i don`t like small e
[15:33] <koolhead17> it makes me feel internet explorer
[15:33] <koolhead17> :(
[15:33] <kim0> IE'ish 
[15:33] <kim0> yeah
[15:33] <koolhead17> so i asked robbie for capital E
[15:33] <koolhead17> :D
[15:33] <kim0> maybe it should be engraved like enlightenment or something
[15:33]  * kim0 jumps back to writing some stuff
[15:33] <koolhead17> well we need to do sumthing to the circle around that e
[15:33] <koolhead17> :P
[15:40] <SpamapS> RoAkSoAx: yeah thats fine. We had a debate in Dublin and decided it really didn't matter either way.
[15:40] <SpamapS> RoAkSoAx: or at least, the end of the discussion was "lets move forward from this because it doesn't matter for a proof of concept"
[15:40] <RoAkSoAx> SpamapS: yeah smoser updated me on the matter
[15:40] <SpamapS> RoAkSoAx: by system, I hope you mean a vm using koan. ;)
[15:41] <RoAkSoAx> SpamapS: yes
[15:41] <RoAkSoAx> SpamapS: for the PoC i'm working atm i'm using koan
[15:48] <SpamapS> RoAkSoAx: alright, so .. did you actually get something to boot?
[16:02] <RoAkSoAx> SpamapS: yeah more or less 
[16:02] <RoAkSoAx> will send you a difff later for you to see
[16:02] <RoAkSoAx> SpamapS: but yesterday we were concentrating on the best approach to pass coud-init stuff usoing the preseed
[16:02] <SpamapS> Yeah I'm wondering how that can be done too
[16:03] <SpamapS> At this point a late_command that acceps a massive base64 encoded string is probably the best bet unless you found something better?
[16:04] <RoAkSoAx> SpamapS: we have that already, hold on ;)
[16:05] <RoAkSoAx> SpamapS: http://paste.ubuntu.com/643355/
[16:05] <RoAkSoAx> SpamapS: http://paste.ubuntu.com/643356/
[16:05] <SpamapS> RoAkSoAx: I've had difficulty getting the system <-> actual mac bits working right
[16:07] <etneg> kim0: uploading a few rough concepts now
[16:07] <etneg> sladentoo ^^
[16:08] <RoAkSoAx> SpamapS: what do you mean exactly?
[16:09] <SpamapS> RoAkSoAx: I think I just figured it out actually
[16:11] <kim0> etneg: awesome :)
[16:12] <kim0> sladen: ^
[16:12] <SpamapS> RoAkSoAx: yeah, I didn't assign the MAC right before. Its working fine.
[16:13] <RoAkSoAx> SpamapS: ok ;) yeah you have to assign and interface first, and then the MAC address it is a tricky thing that's not being validated
[16:16] <etneg> launchpad takes awhile to send an email
[16:17] <etneg> i forgot my pass and wanted to reset, still havent received a confirmation code to reset..
[16:23] <etneg> k since its taking awhile to reset the password. cant post it in the bug now but here it goes
[16:23] <etneg> http://i54.tinypic.com/2yn00b6.jpg
[16:23] <etneg> 1 concept for it
[16:25] <etneg> http://i55.tinypic.com/sq34fs.jpg
[16:25] <etneg> ignore the colors pls, that was just to give an idea
[16:28] <etneg> and the last one http://i51.tinypic.com/28jguvt.jpg
[16:28] <etneg> ignore the coloring:D
[16:28] <etneg> comments, critique! if it sucks it sucks, but let me know!
[16:29] <kim0> etneg: thanks for the great work man :)
[16:29] <kim0> many options to choose from is always a good thing
[16:29] <etneg> kim0: sure:P
[16:29] <etneg> yeah
[16:29] <etneg> keep options open
[16:29] <kim0> sladen: ^
[16:29] <sladen> etneg: do you want me to link those into the bug report, or can you do it yourself directly?
[16:29] <etneg> but till someone colors it up not sure how it's going to look
[16:29] <etneg> sladen: i could but i forgot my password to login
[16:30] <kim0> The oxygen atom concept is still on the top of my list though :)
[16:30] <etneg> and was trying to reset, launchpad hasnt sent me the confirmation code yet 
[16:30] <kim0> etneg: check ur spam folder ?
[16:30] <etneg> empty
[16:30] <sladen> etneg: btw, you should submit something to the wallpaper contest
[16:30] <etneg> unless osomeone can color it out, i dont know if i could
[16:31] <etneg> i could do the concepts but not sure thats what they'd want
[16:34] <etneg> kim0: the oxygen atom idea is quite digitized though
[16:34] <etneg> mine are still in pencil
[16:34] <etneg> :P
[16:35] <kim0> yeah :)
[16:37] <etneg> from this http://i52.tinypic.com/t62vzl.jpg
[16:37] <etneg> to
[16:39] <sladen> etneg: details of the Ubuntu 11.10 contest at  http://design.canonical.com/2011/07/get-excited-and-make-things-wallpaper-edition/
[16:40] <etneg> to http://i55.tinypic.com/2bckrn.png
[16:40] <sladen> etneg: what's your username, I can try asking one of the Launchpad people to look at the mail and see how far it got
[16:40] <etneg> make s a huge difference in the coloring
[16:40] <etneg> mellgoth29@gmail.com
[16:41] <sladen> etneg: Launchpad doesn't seem to think there's anyone with that email address (I've tried subscribing it)
[16:42] <etneg> Forgotten your password?
[16:42] <etneg> We’ve just emailed mellgoth29@gmail.com (from noreply@launchpad.net) with instructions on resetting your password.
[16:43] <etneg> i dont have an account on launchpad, i just subscribed to the ensemble list, that was it and now to the bugs list so i can post it there
[16:43] <etneg> but i forgot my password so i can post to the lists
[16:43] <sladen> etneg: ahhh, no Launchpad account, that'll be why I can't subscribe you to the bug report :)
[16:44] <etneg> i'll  need a launchpad account to post to the bugs report?
[16:45] <sladen> etneg: yes, cunning spam avoidance mechanism
[16:45] <sladen> etneg: there are a couple of wish-list bugs about eg. enabling posting by Debian Developers, or GPG-signed emails without having an account first
[16:46] <sladen> etneg: or for allowing OpenID (my preference for a number of years)
[16:47] <etneg> ah ok
[16:48] <etneg> ah ok launchpad created
[16:49] <adam_g> need suggestions here on a formula im writing. ive got a serivce unit that has many clients relating to it. i need a hook that will fire (for each relation) after a minimum number of peer relations is reached, and again for every new relation added. any ideas? SpamapS m_3 ?
[16:49] <etneg> if i click show bugs by heat
[16:49] <etneg> i get an (Error ID: OOPS-2020AT233) 
[16:49] <sladen> etneg: I've used the example and added another comment to the requests for OpenID:  https://bugs.launchpad.net/launchpad/+bug/210943
[16:49] <_mup_> Bug #210943: Launchpad only permits user authentication via the Ubuntu single-signon OpenID server <feature> <lp-foundations> <openid> <openidrp> <Launchpad itself:Triaged> < https://launchpad.net/bugs/210943 >
[16:50] <sladen> etneg: and subscribed you to:  https://bugs.launchpad.net/ubuntu-branding/+bug/807100
[16:50] <_mup_> Bug #807100: Develop Ensemble logo (ensemble.ubuntu.com) <ubuntu-branding:In Progress> < https://launchpad.net/bugs/807100 >
[16:51] <etneg> sweet thanks sladen 
[16:51] <sladen> etneg: would you like to introduce + link to the latest sketches in your own words?
[16:51] <etneg> na na i just want post it and get some feedback i guess
[16:51] <etneg> possibly get someone to color it
[16:51] <etneg> :D
[16:52] <sladen> etneg: okay, perhaps just "here are three more colour sketches I did, I'd love feedback and anyone who can help with colouring them"
[16:52] <etneg> ok
[16:53] <sladen> etneg: well, maybe not colour sketches, if you want help colouring them :)
[16:53] <sladen> etneg: but this one with the Nemo fishes, I would definately put that foward for the wallpaper contest http://i55.tinypic.com/2bckrn.png
[16:54] <etneg> ohhh no way
[16:54] <etneg> someone else is using it
[16:54] <etneg> i just wanted to give a rough idea on how coloring makes a difference
[16:54] <etneg> i just did the pencil part and someone else did the coloring part
[16:55] <sladen> etneg: out of interest, what's using it?
[16:55] <etneg> noticed you
[16:56] <etneg> basically i got my fingers in every pie :P
[16:56] <etneg> but we were done with the wallpaper stuff, all finalised, so figured i'll do some logo stuff and bumped into ensemble:D
[16:58] <etneg> sladen: thanks for the headsup in the bugs list
[17:00] <robbiew> kim0 so what's the process with the logo?
[17:00] <robbiew> are we gathering submissions and then doing a vote?
[17:00] <robbiew> I don't think we want this dragging on for much longer
[17:02] <sladen> robbiew: the only basic requirement is that we shop it past marcushaslam (Ubuntu Brand Lead) to ensure that whatever is proposed fits with the brand (and we'll probably get ideas on how to improve it if not)
[17:03] <robbiew> sladen: uh...I don't think so
[17:04] <sladen> robbiew: *blink*
[17:04] <robbiew> this is more project oriented...nothing to do with wallpapers
[17:04] <etneg> ok done
[17:04] <sladen> robbiew: correct, this has nothing to do with wallpapers
[17:04] <sladen> robbiew: and the wallpapers has nothing to do with Ubuntu Branding
[17:04] <robbiew> neither does Ensemble, really
[17:05] <sladen> robbiew: but this here Ensemble logo probably has to tie in with the Ubuntu/Canonical brand eco-sphere to some degree (it would be good if you could clarify to what extent---there's a question about just that on the bug report)
....this seems overly complicated
[17:06] <sladen> robbiew: I think the Design Team would love to be useful, but need some metrics about how to be useful :)
[17:07] <etneg> oh we'll need canonical as part of the logo as well?
[17:07] <robbiew> they are useful
[17:07] <etneg> cause all of mine are geared towards ubuntu+ensemble
[17:09] <sladen> robbiew: right, so the Design Team's long-suffering techie sought to enquire 'A big question I'd like to know is how closely is this going to be tied to the Ubuntu or Canonical brands, or is it intended to be stand-alone? Eg. will it always be "Ubuntu Ensemble", or "Canonical Ensemble", or just "Ensemble".'  ( https://bugs.launchpad.net/ubuntu-branding/+bug/807100/comments/5 )
[17:09] <_mup_> Bug #807100: Develop Ensemble logo (ensemble.ubuntu.com) <ubuntu-branding:In Progress> < https://launchpad.net/bugs/807100 >
[17:09] <robbiew> it will be Ensemble
[17:09] <robbiew> just like Upstart is Upstart
[17:11] <etneg> if nobody can color mine i guess there's nothing much left to decide or vote
[17:11] <etneg> its the oxygen atom concept
[17:12] <robbiew> one point, and I believe niemeyer has made this before, is that ensemble is not just for clouds
[17:12] <robbiew> it's service orchestration
[17:12] <robbiew> which can occur on bare-metal machines as well
[17:12] <sladen> robbiew: https://bugs.launchpad.net/ubuntu-branding/+bug/807100/+addcomment?field.text=For+the+branding+it+will+just+be+Ensemble,+just+like+Upstart+is+upstart
[17:12] <_mup_> Bug #807100: Develop Ensemble logo (ensemble.ubuntu.com) <ubuntu-branding:In Progress> < https://launchpad.net/bugs/807100 >
[17:12] <etneg> but cloud is still part of it
[17:14] <robbiew> indeed...but doesn't define it
[17:14] <etneg> so where is cloud being defined?
[17:14] <etneg> or orchestration in any of the logos though
[17:15] <sladen> robbiew: https://bugs.launchpad.net/ubuntu-branding/+bug/807100/+addcomment?field.comment=For+the+branding+it+will+just+be+Ensemble,+just+like+Upstart+is+upstart  lets try that again
[17:15] <_mup_> Bug #807100: Develop Ensemble logo (ensemble.ubuntu.com) <ubuntu-branding:In Progress> < https://launchpad.net/bugs/807100 >
[17:15] <etneg> here's something to think about from an artistic point o view and not from a technical aspect
[17:15] <etneg> people give two shits about a 2hr lecture on how the logo was made, maybe 10% would care, 
[17:16] <etneg> rest is if the logo looks good, you're done
[17:16] <etneg> everyone's happy, and it'll stay in people's head
[17:16] <etneg> waht you want is people to remember it
[17:17] <etneg> not about the long explanation on bare metal machines or cloud or orchestration, sure the people designing it could think about all those aspects but the audience really just wants to see a nice good looking logo
[17:18] <etneg> atleasts in my experience:D
[17:18] <etneg> atleast
[17:19] <etneg> we could just have a plain E and then color it just enough to look good, but if it acually is well done, nothing else will matter
[17:19] <etneg> all the orchestration and cloud and any other theme we thought of would just slowly fit into it simply because people like it
[17:19] <etneg> like it= like the logo
[17:20] <robbiew> i guess...I'm staying out this
[17:20] <robbiew> good luck all!
[17:20] <etneg> ?
[17:20] <etneg> ohhh
[17:20] <etneg> you're the guy who designed the oxygen atom concept
[17:20] <etneg> heh
[17:22] <etneg> either way i think your idea is the winner, we got nobody to color mine
[17:22] <sladen> etneg: yup, meet superman^W^W robbiew, Server Team Lead 
[17:22] <etneg> oh ok
[17:22] <etneg> he isn't very happy at the moment lol
[17:23] <etneg> hi
[17:25] <etneg> ok i guess i can stop with the concepts then, instead of dragging this like robbiew  said, go with the oxygen idea even kim0 likes it
[17:25] <robbiew> not unhappy...just busy with some other stuff
[17:25] <robbiew> seriously...I'm fine with anything chosen
[17:26] <robbiew> not pushing my idea...I just don't want this to drag on for months
[17:28]  * etneg nods
[17:36] <kim0> Glad everyone is happy, and indeed let's finish this off
[17:48] <SpamapS> RoAkSoAx: how goes the battle? ;)
[17:55] <etneg> well anyohw nice working with you guys, if you need anything else let me know
[17:56] <etneg> later sladen , kim0 
[18:08] <smoser> RoAkSoAx, bug 810044 for the cloud-init race on mutiple interfaces
[18:08] <_mup_> Bug #810044: cloud-init will have race conditions for cloud-config with multiple network adapters <amd64> <apport-bug> <oneiric> <cloud-init:New> <cloud-init (Ubuntu):New> < https://launchpad.net/bugs/810044 >
[18:09] <smoser> SpamapS, i'd like your suggestions for upstart magic that would handle "all itnerfaces up" (i think there is something in upstart now for that)
[18:09] <SpamapS> No I'm supposed to add that.
[18:09] <SpamapS> the closest thing is 'started networking' because it comes after 'ifup -a'
[18:10] <SpamapS> err
[18:10] <SpamapS> stopped networking actually
[18:10]  * SpamapS curses the task
[18:10] <SpamapS> smoser: I'm supposed to be adding one for oneiric that happens when all statically configured interfaces are up.
[18:11] <smoser> you ahve a bug opne for that ?
[18:11] <smoser> that i cna reference?
[18:14] <serue_> yeah stopped networking is what i'm using in libvirt
[18:14] <SpamapS> Its in a blueprint
[18:14] <SpamapS> smoser: https://blueprints.launchpad.net/ubuntu/+spec/server-o-boot-experience
[18:38] <RoAkSoAx> SpamapS: just came back from lunch, should have something more solid later today
[18:38] <RoAkSoAx> smoser: let's see
[18:40] <SpamapS> RoAkSoAx: cool. I've been playing and I keep running into the "how do we know when to turn off netboot for a system" problem..
[18:40] <SpamapS> RoAkSoAx: seems like we need to have something that turns that off in the latecmd.
[18:40] <RoAkSoAx> smoser: so, as you mention, checking if we can access a public ubuntu archive give us the impression that there';s outside world connectivity?
[18:41] <smoser> well, it would indeed give that impression
[18:41] <smoser> but that could be useless information
[18:41] <smoser> especially in the case where it has an internal archive that it was told to use by the preseed.
[18:41] <RoAkSoAx> SpamapS: in the cobbler "system" you mean?
[18:42] <RoAkSoAx> smoser: right, but I mean, accessing an always available Ubuntu archive on the internet
[18:42] <SpamapS> RoAkSoAx: yeah, basically my box gets installed correctly and then reboots and because it is defined as a "system" it starts installing itself again rather than defaulting to local boot
[18:43] <RoAkSoAx> SpamapS: is that in a VM or in real HW?
[18:43] <SpamapS> real
[18:43] <smoser> SpamapS, i agree, you need something there.
[18:43] <smoser> RoAkSoAx, why would it matter real or virt?
[18:43] <smoser> the issue is that the system is set to netboot, and cobbler is told to netboot it.
[18:43] <smoser> cobbler needs to be told to stop netbooting it
[18:43] <smoser> how is this general problem addressed
[18:44] <smoser> it is not specific to ensemble , or even ubuntu
[18:44] <SpamapS> I think there's some snippets for kickstarts that do it
[18:44] <smoser> how?
[18:45] <SpamapS>     ## PXE JUST ONCE
[18:45] <SpamapS>     #if $pxe_just_once in [ "1", "true", "yes", "y" ]
[18:45] <SpamapS>         #if $breed == 'redhat'
[18:45] <SpamapS>             #set nopxe = "\nwget \"http://%s/cblr/svc/op/nopxe/system/%s\" -O /dev/null" % (srv, system_name)
[18:45] <SpamapS> thats from kickstart_done
[18:45] <smoser> that seems easy enough
[18:45] <smoser> no?
[18:45] <RoAkSoAx> SpamapS: yeah that's it with $pxe_just_once
[18:46] <SpamapS> but that is only in kickstart snippets
[18:46] <RoAkSoAx> but seems disabled by default
[18:46] <smoser> well we're providing our own preseed file.
[18:46] <SpamapS> the variable seems meaningless with pre-seeds w/o another snippet
[18:46] <smoser> and i can't imagine any case where you would want to install again and again
[18:47] <RoAkSoAx> I actually haven't run into the problem
[18:47] <SpamapS> if you have hardware that only PXE's when you ask it to, not by default, this isn't an issue
[18:47] <smoser> just put into our preseed 
[18:47] <smoser>   wget \"http://%s/cblr/svc/op/nopxe/system/%s\" -O /dev/null" % (srv, system_name)
[18:47] <SpamapS> smoser: that needs to be run as part of the latecmd
[18:47] <smoser> right
[18:47] <smoser> so let it be
[18:47] <smoser> by default
[18:47] <smoser> always
[18:47] <RoAkSoAx> SpamapS: that's easy to achieve
[18:47] <smoser> do not put this in ensemble though
[18:48] <smoser> just put it in the late-command by default
[18:48] <SpamapS> Right
[18:48] <smoser> (or early command)
[18:48] <SpamapS> late
[18:48] <smoser> meh. 6 in one half a dozen in the other.
[18:48] <SpamapS> I see some advantages to either
[18:48] <smoser> yeah
[18:48] <smoser> so i dont care
[18:49] <smoser> it does seem strange to me that the option to turn off pxe is not acl'd
[18:49] <SpamapS> smoser: couldn't you make cloud-init's nocloud seed data "pre-seedable" ..
[18:49] <smoser> ie, anyone can do that.
[18:49] <SpamapS> smoser: that way you wouldn't have to use latecmd.. you could just say  cloud-init cloud-init/nonet-base64 string asdflkja1383185a0easdfasdfffa09
[18:49] <smoser> SpamapS, there is no issue really with utilizing late-command multiple times.
[18:50] <SpamapS> smoser: its additive?!
[18:50] <smoser> ie, we could definitely do that in cloud-init though
[18:50] <smoser> the way we've got it now , it is easily additive
[18:50] <SpamapS> ah well then i'll stop bike shedding
[18:50] <smoser> hold on. let me dig it up
[18:51] <smoser> SpamapS,  see line 105 and 106 at
[18:51] <smoser> http://bazaar.launchpad.net/~smoser/+junk/cobbler-devenv/view/head:/cobbler-server/late_command.sh
[18:51] <smoser> just insert a :
[18:52] <smoser> # wget "http://%s/cblr/svc/op/nopxe/system/%s\" -O /dev/null % (srv, system_name) 
[18:52] <smoser> before the ensembel line
[18:53] <SpamapS> Not sure I understand how it is 'string true' .. but I'll take your word for it. :)
[19:00] <smoser> i dont know how you get 'srv' set in that snippit.
[19:00] <smoser> but i just tested rendering of:
[19:00] <smoser> http://paste.ubuntu.com/643453/
[19:01] <smoser> SpamapS, the 'true' is just part of the string
[19:01] <smoser> only there so that it is [apparently not very] obvious where you could insert additional commands
[19:02] <SpamapS> smoser: anything in 'sudo cobbler system dumpvars --name=x' is available
[19:02] <smoser> yeah, and i dont see any 'server' there. or anything that indicates my cobbler server
[19:02] <SpamapS> smoser: oh, srv is special
[19:02] <smoser> do you?
[19:02] <SpamapS> #set srv = $getVar('http_server','')
[19:03] <smoser> nice.
[19:03] <smoser> my cobbler thinks that
[19:03] <smoser> http_server : 127.0.3.2
[19:03] <smoser> dont know where it gets that
[19:04] <SpamapS> haha
[19:04] <SpamapS> I think thats actually in settings
[19:05] <SpamapS> server: cobbler
[19:05] <SpamapS> /etc/cobbler/settings
[19:07] <_mup_> ensemble/expose-provider-ec2 r282 committed by jim.baker@canonical.com
[19:07] <_mup_> EC2 port ops
[19:07] <RoAkSoAx> SpamapS: by any chance do you have a user-data sample file of an ensemble zookeeper machine?
[19:08] <RoAkSoAx> s/machine/instance
[19:08] <SpamapS> RoAkSoAx: it just installs zookeeperd
[19:08] <SpamapS> RoAkSoAx: the rest is some run commands to initialize the instance of zookeeper
[19:08] <RoAkSoAx> SpamapS: ok
[19:12] <smoser> http://paste.ubuntu.com/643466/
[19:12] <smoser> so that works.
[19:13] <SpamapS> smoser: *nice*
[19:14] <SpamapS> btw that is a truly glorious latecmd ;)
[19:14] <smoser> well, the really nice thing is that its so easy to tell whats going on
[19:14] <smoser> :)
[19:15] <m_3> RoAkSoAx: user-data from my bootstrap instance is http://paste.ubuntu.com/643463/
[19:15] <smoser> RoAkSoAx, we should add that "pxe-once" snippet to any preseeds we ship
[19:16] <RoAkSoAx> m_3: thanks!!
[19:17] <RoAkSoAx> smoser: yeah cool
[19:18] <adam_g> hey python people, any idea why this may be failing to install from install hook, but installs fine manually and cleansup fine with 'apt-get -f install' after failure?
[19:18] <adam_g> http://paste.ubuntu.com/643455/
[19:20] <smoser> i still think its strange that anyone can just turn off pxe boot for anyone else
[19:21] <SpamapS> adam_g: there are some transitions going on w/ python.. might be just borken in oneiric
[19:21] <adam_g> SpamapS: in what way? using the same AMI, manually installing the same packages (even executing the hook manually) works fine
[19:22] <SpamapS> adam_g: try it with 'apt-get -y install foo | cat'
[19:23] <SpamapS> adam_g: its possible that there's something broken in their config scripts that depends on the terminal.. though that sounds unlikely
[19:25] <smoser> DEBIAN_FRONTEND=noninteractive
[19:25] <SpamapS> yeah thats worth a go as well
[19:27] <adam_g> ive already set to noninteractive
[19:27] <adam_g> ill give natty a shot in a min
[19:27] <RoAkSoAx> SpamapS: http://paste.ubuntu.com/643476/ --> so this is just a test bootstrap procedure
[19:27] <RoAkSoAx> niemeyer: http://paste.ubuntu.com/643476/
[19:29] <SpamapS> +        #log.info("Run ensemble-admin --instance_id orchestra-server --admin_id %s" % self._admin_id)
[19:30] <SpamapS> RoAkSoAx: IIRC, ensemble-admin initialize is run as part of the scripts from common.. I think
[19:32] <RoAkSoAx> SpamapS: I have yet to fully discover ensemble :) but just wanted to provide a quick demo using what you worked on and the approach discussed here
[19:32] <RoAkSoAx> SpamapS: of course this needs to be integrated correctly with the refactoring that fwereade is working on
[19:33] <RoAkSoAx> smoser: http://paste.ubuntu.com/643476/ that's over SpamapS' branch
[19:36] <RoAkSoAx> smoser: so the only thing missing would be to install by default cloud-init in the target system to run what we are passing through the preseed right?
[19:37] <smoser> RoAkSoAx, yeah, so i have two thoughts on that.
[19:37] <smoser> in my preseeds i've had EXTRA_PACKAGES as a ks value
[19:37] <smoser> we *could* use that, similarly '$ENSEMBLE_PACKAGES'
[19:37] <smoser> but i think we can also just assume that cloud-init is in the packages list.
[19:38] <smoser> and i lean towards assuming it is.
[19:39] <SpamapS> I think for completeness of solution, ensemble bootstrap should actually install this preseed file if cobbler will allow it.
[19:40] <RoAkSoAx> SpamapS: unless we ship it with orchestra as an ensemble preseed
[19:41] <SpamapS> That seems like a good fallback. "Orchestra - Now with Ensemble Support" ;)
[19:45] <smoser> SpamapS, cobbler will not allow it
[19:45] <smoser> well, you can only change existing kickstarts.
[19:45] <smoser> i thik...
[19:45] <niemeyer> This code, in Jim's branch, looks awesome
[19:46] <smoser> maybe i'm wrong, but there was some limitation there.
[19:46] <niemeyer> http://paste.ubuntu.com/643484/
[19:46] <smoser> oh...
[19:46] <niemeyer> Let's have more of it
[19:46] <smoser> SpamapS, i think it is not desireable for ensemble to insert the kickstart itself
[19:46] <RoAkSoAx> i think we should have the kickstart provided
[19:47] <SpamapS> Ok. That is a simpler solution.
[19:47] <smoser> this is because in any real world situation, the admin will have a taylored preseed for their systems.
[19:47] <SpamapS> Eh, but thats just the kind of thing we don't want.
[19:47] <RoAkSoAx> and when we have system's in foo-available, we set the kickstart to the one for ensemble
[19:47] <smoser> it is the kind of thing we *do* want
[19:47] <smoser> and admins want
[19:47] <SpamapS> Err.. ok.
[19:48] <smoser> you buy a honking large server with a 3200RPM disk on / and a high end raid attached
[19:48] <SpamapS> (I'd err on the side of pure machines so we can continue to make assumptions in formulas)
[19:48] <smoser> you want to tell your preseed to use the high end disk
[19:48] <smoser> not jsut accept the defaults of the installer
[19:48] <SpamapS> smoser: I think we can do that w/ snippets
[19:48] <smoser> do what with snippets?
[19:48] <SpamapS> Well, s/that/what we need to/
[19:49] <smoser> well, we already have that basically
[19:49] <SpamapS> We can include an ensemble snippet, and a default pre-seed that does not disk config..
[19:49] <smoser> ensemble needs one hook in
[19:49] <smoser> you put that text in your preseed and you're good
[19:49] <smoser> we provide a documented example in orchestra that shows what it needs
[19:49] <SpamapS> Then let people make their own pre-seed that just includes the ensemble snippet.. rather than copy/paste
[19:49] <smoser> meh
[19:49] <RoAkSoAx> we can have a bsic preseed and also chainload another preseed or use snippets, it will work either way
[19:49] <SpamapS> Yeah, I'd keep the magic in the snippets
[19:49] <smoser> copy and paste a snippet or copy and paste a bit of code
[19:50] <RoAkSoAx> I think adding a snippet would be easier
[19:50] <SpamapS> a call to a snippet is going to evolve with releases and updates..
[19:50] <RoAkSoAx> indeed
[19:50] <SpamapS> copy/pasted code will not
[19:50] <smoser> thats possibly true, but a preseed file will *also* evolve with releases
[19:50] <SpamapS> tho one thing that sucks.. the snippets live in /var/lib don't they?
[19:51] <SpamapS> yeah.. suck.. that means if we update them in the package they don't get updated in your installation
[19:51] <smoser> and a snippet doesn't really solve all your problem.
[19:51] <SpamapS> a unicorn would
[19:51] <smoser> i think as much as possible we shoudl rely on only late_command
[19:52] <smoser> and so a snippet for late_command, that allows the user to add their own commands is not terribly prettier
[19:52] <SpamapS> Thats fair, but I'm concerned with people doing things in a weird way on these servers that will make formulas fail.. until we have container support in the machine agent, thats going to be a real danger.
[19:53] <smoser> they're going to do things.
[19:53] <smoser> and there are very good reasons for wanting to modify a preseed.
[19:53] <SpamapS> yeah, I want the default to allow them to do those things w/o copy/pasting something we need to change later.
[19:54] <smoser> but i dont think you can.
[19:54] <smoser> i'm saying keep it to only touching late_command
[19:54] <smoser> we can do just about anything inside of a late command
[19:54] <smoser> and we can inject anything we want in there.
[19:55] <smoser> and a snippet wouldn't help you there, really.
[19:55] <smoser> since its basically a patch collision on likely modified code
[19:55] <SpamapS> You can define a python function, with default arguments.. and the default kickstart would be something like
[19:55] <SpamapS> $SNIPPET('ensemble')
[19:55] <SpamapS> ## put your custom pre-seed here
[19:56] <SpamapS> $ensemble_latecmd() # Add an argument if you need to add late commands as well.
[19:56] <SpamapS> Now the magic is hidden in ensemble_latecmd()
[19:56] <_mup_> ensemble/expose-provider-ec2 r283 committed by jim.baker@canonical.com
[19:56] <_mup_> Adjust provider interface for port mgmt to take machine_id
[19:57] <smoser> SpamapS,  i don't folow
[19:57] <SpamapS> you can fix the magic, and even put it in a python lib which the snippet imports
[19:57] <smoser> oh. sure.
[19:57] <niemeyer> jimbaker: expose-provision-machines has a review
[19:57] <_mup_> ensemble/expose-provider-ec2 r284 committed by jim.baker@canonical.com
[19:57] <_mup_> Merged expose-provision-machines
[19:57] <jimbaker> niemeyer, thanks
[19:57] <niemeyer> hazmat: That's a good candidate for a review break: https://code.launchpad.net/~jimbaker/ensemble/expose-provision-machines/+merge/67623
[19:57] <smoser> so, sure. i'm fine saying a snipet.
[19:57] <smoser> and then on the late_command line using $ensemble_latecmd
[19:58] <smoser> but you still have cut and paste
[19:58] <smoser> so really you'd want
[19:58] <smoser> late_command string $SNIPPET('ensemble_latecommand')
[19:58] <SpamapS> $SNIPPET() is like an include
[19:59] <SpamapS> but yeah details details.. I do like having the explicit latecmd line there so its clear that this is where late_command is set.
[19:59] <smoser> and where the user would want to add their own.
[20:00] <SpamapS> yeah, that makes it easier not to screw up
[20:00] <smoser> so all you did is change what they will copy and paste. ;-)
[20:02] <jimbaker> niemeyer, looks good. re try-finally for observation, this is to ensure the observation happens even if there's an error (eg  ProviderInteractionError)
[20:02] <niemeyer> jimbaker: If you put at the top there's no possible error that may happen besides from itself
[20:02] <niemeyer> jimbaker: Is there a reason why it can't be at the top?
[20:03] <jimbaker> niemeyer, sure, but i also want it to happen last, otherwise the timing gets off
[20:03] <jimbaker> i should note, this only occurs with repeated looping
[20:04] <jimbaker> otherwise the ordering is unnecessary
[20:04] <niemeyer> jimbaker: This feels a bit vague
[20:04] <niemeyer> jimbaker: How does the timing get off?
[20:04] <niemeyer> jimbaker: What is depending on that order?
[20:04] <jimbaker> niemeyer, sorry i'm just recalling the torture :)
[20:04] <jimbaker> as you may know, i fully support the move to go based on this work ;)
[20:05] <SpamapS> smoser: yes I want to change what they will copy and paste so that it has no logic in it
[20:06] <smoser> $ENSEMBLE_COMMAND has no logic
[20:06] <smoser> only the spelling of the word
[20:06] <smoser> but this is not worth arguing
[20:06] <jimbaker> niemeyer, the observation is there to ensure that a specific sequence of activities associated with a particular event (open_close_ports) has completed. otherwise, it is possible for a callback to still be in process, which defeats the observation rationale
[20:07] <niemeyer> jimbaker: Cool, please just paste that as the answer to that review point then.  Thanks for the explanation.
[20:08] <jimbaker> niemeyer, sounds good!
[20:08] <niemeyer> jimbaker: In terms of the migration, it will certainly help us getting rid of those issues, but it's not a free pass to be lax in terms of understanding why/how things work right now.
[20:08]  * jimbaker doesn't want to write such complex code in twisted again
[20:09] <jimbaker> niemeyer, indeed
[20:10] <jimbaker> niemeyer, fortunately i think we have a very good pattern in place with this code. it is robust, if complex. it just needs some doc in place to explain the why behind the necessary complexity
[20:11] <jimbaker> so i will address that :)
[20:27] <niemeyer> jimbaker: Kind of.. there are still tricks in there which clearly are made out of explosions noted while testing
[20:28] <niemeyer> jimbaker: if not self._running, etc
[20:28] <niemeyer> jimbaker: StateChangeds..
[20:28] <jimbaker> niemeyer, sure
[20:29] <niemeyer> jimbaker: Hopefully the final pattern we'll get to will be more resilient ("if this call failed, then 
[20:29] <niemeyer> ..")
[20:29] <jimbaker> niemeyer, none of which seem to be necessary when the tests are just run once, only when looped. but justified after the fact
[20:30] <niemeyer> jimbaker: That's exactly my worry
[20:30] <jimbaker> also seen in supporting state code, so needing to add guards against topology changes
[20:30] <niemeyer> jimbaker: What you're really saying is "None of that fails when thing happen on that very precise order"
[20:30] <niemeyer> jimbaker: Which is artificial
[20:30] <niemeyer> jimbaker: I know.. your guards are sane
[20:31] <niemeyer> jimbaker: The problem I see isn't that you've put them in place.. but rather that I'm sure you've figured they were needed because things failed while running
[20:31] <niemeyer> jimbaker: This means it's still harder to come up with correct logic than it ought to be
[20:31] <niemeyer> jimbaker: We'll get there, though.. don't worry :)
[20:32] <jimbaker> niemeyer, yeah, i'm certainly looking forward to golang making it easier to express things deterministically
[20:35] <_mup_> ensemble/expose-provider-ec2 r285 committed by jim.baker@canonical.com
[20:35] <_mup_> Now pass in the machine_id to port ops in provisioning agent
[20:38] <SpamapS> niemeyer: I'm curious why only twisted is used for non-blocking code. I have zero experience w/ python threads.. but.. are they that useless?
[20:39] <niemeyer> SpamapS: It's a bit like the opposite
[20:39] <niemeyer> SpamapS: Twisted runs in a main thread
[20:40] <niemeyer> SpamapS: and it has a dispatching loop as most event based systems do
[20:40] <niemeyer> SpamapS: Like most Python code, though, Twisted is not thread safe
[20:40] <SpamapS> That much seems straight forward.. the couple of twisted based things I've written were just a protocol handler hanging off the reactor.
[20:40] <niemeyer> SpamapS: So it has its own thread, and it orchestrates calls between pending events
[20:41] <niemeyer> SpamapS: The trickiness comes when you want to execute a blocking call
[20:41] <SpamapS> Ah.. I recall it was a huge breakthrough when libevent became thread safe.
[20:41] <SpamapS> memcached got an order of magnitude faster w/o adding much code complexity.
[20:42] <niemeyer> SpamapS: The issue is that _everything_ happening through Twisted logic (deferreds), happens in that one thread
[20:42] <niemeyer> SpamapS: So if you call something that blocks within that one thread, it wedges the whole thing
[20:42] <niemeyer> SpamapS: So the right way to do it is to defer to a thread
[20:42] <SpamapS> Yeah.. as is the usual case with non-blocking event based systems.
[20:42] <niemeyer> SpamapS: (which is why I said it was the opposite)
[20:43] <SpamapS> I read a good white paper on why event based systems always start simpler than threaded systems, but usually end up more complex over time.
[20:43] <niemeyer> SpamapS: Even more when it's an after-thought
[20:45] <niemeyer> SpamapS: .. as in, Python itself as a language wasn't designed like that
[20:45] <SpamapS> http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/
[20:45] <niemeyer> SpamapS: Oh, that looks interesting, thanks!
[20:45] <niemeyer> SpamapS: I'm sending to Ubuntu One for the reading queue right now :)
[20:47] <niemeyer> "is being uploaded to your personal cloud." is sooooo cheesy, btw :-)
[20:47] <SpamapS> I don't let U1 tell me anything.. I ask it occasionally if it did something. ;)
[21:08] <adam_g> are there any published formulas that serve as a good example of peer relations vs require/provides?
[21:11] <SpamapS> adam_g: I think negronjl has some
[21:11] <SpamapS> adam_g: tomcat6 maybe
[21:11] <adam_g> cool
[21:13] <m_3> maybe cassandra?
[21:15] <SpamapS> Yeah I don't know if the cassandra formula is published just yet
[21:26] <niemeyer> adam_g: I'm not sure I'm really answering your question there, to be honest
[21:26] <niemeyer> adam_g: Are you trying to do a ring, or 1-N relationship?
[21:27] <niemeyer> adam_g: Both are doable.. I just want to make sure we're on the same page
[21:27] <adam_g> niemeyer: 1-N. the term "ring" is specific to swift in this case i think
[21:27] <adam_g> what you've described on the list sounds like a good solution. 
[21:28] <niemeyer> adam_g: Hmm, ok
[21:28] <niemeyer> adam_g: I wasn't sure because peer relations work within the same service
[21:28] <niemeyer> adam_g: So when you need two _different_ formulas/services, it's a 1-N relationship
[21:28] <adam_g> i basically need relation-changed to be fired on all nodes participating in the relationship
[21:28] <niemeyer> adam_g: Which just works.. you don't have to do anything about it
[21:28] <adam_g> ok wait.. 
[21:29] <adam_g> i'll have 1 swift-proxy that relates to many swift-storage-nodes
[21:29] <adam_g> when a new storage-node joins, i need relation-changed to be fired on all other storage-nodes to get the new ring configuration
[21:29] <niemeyer> adam_g: Ok.. are all the swift-storage-nodes deployed with the same service, or with different services?
[21:30] <adam_g> niemeyer: not sure i follow the question. they'll all be using the same swift-storage-node formula, if that means anything
[21:30] <niemeyer> adam_g: Or, in more simple words, how do you add a new swift-storage-node?
[21:30] <niemeyer> adam_g: Ok.. so you can have a peer relation
[21:30] <niemeyer> adam_g: and the list conversation makes sense
[21:30] <niemeyer> adam_g: Well, one more question:
[21:31] <niemeyer> adam_g: Do you want a change in _swift-proxy_ to affect all nodes?
[21:31] <niemeyer> adam_g: Or the nodes themselves to be self-aware?
[21:31] <niemeyer> (aware of the ring they're in)
[21:33] <_mup_> ensemble/expose-provider-ec2 r286 committed by jim.baker@canonical.com
[21:33] <_mup_> Mock test for EC2OpenedPorts
[21:33] <adam_g> the workflow is basically this. swift-proxy is alone with no ring config. storage-node joins. proxy configures ring with 1 node, sends config to storage-node1. storage-node2 joins. rign is reconfigured with 2 nodes, config is sent to storage-node1 + storage-node2
[21:33] <niemeyer> adam_g: Ok, that's a NOOP, I think :-)
[21:33] <niemeyer> adam_g: I mean, it just works
[21:34] <adam_g> in the context of peer relations?
[21:34] <niemeyer> adam_g: If you have one formula for swift-proxy, and one formula for swift-storage-node
[21:34] <adam_g> or in general?
[21:34] <niemeyer> adam_g: in general
[21:34] <niemeyer> adam_g: Then you do
[21:34] <niemeyer> adam_g: add-relation proxy storage
[21:34] <niemeyer> adam_g: You get a relation established between these
[21:34] <niemeyer> adam_g: Then, you can do
[21:34] <niemeyer> adam_g: add-unit storage
[21:34] <niemeyer> adam_g: add-unit storage
[21:34] <niemeyer> adam_g: and get a couple of new units (3 in total now)
[21:35] <niemeyer> adam_g: These are units of the same service (storage) and all of them are in a relation with the proxy
[21:35] <niemeyer> adam_g: When the proxy does "relation-set whatever=foo"
[21:35] <niemeyer> adam_g: all the units get the notification
[21:35] <niemeyer> adam_g: through relation-chagned
[21:36] <niemeyer> adam_g: Is that what you wanted?
[21:36] <adam_g> ok. that is exactly what i needed. 
[21:36] <adam_g> ive not used 'add-unit' yet
[21:36] <niemeyer> adam_g: Ok.. that's awesome.. it should just work
[21:36] <adam_g> but i think now would be a good time to start
[21:36] <niemeyer> adam_g: Oh, you should try it!  I personally find that one of the most awesome things about the model we have
[21:37] <niemeyer> adam_g: all of the units of a single service share the same relations and the same configuration
[21:37] <niemeyer> adam_g: Makes it trivial for the user to scale things up at will
[21:38] <niemeyer> ensemble add-unit <service-name>, profit
[21:38] <adam_g> ah
[21:38]  * SpamapS hearts add-unit too
[21:38] <adam_g> for another formula that has a provides/requires metadata layout, does add-unit 'just work' or it needs to be configured as peer relation?
[21:38] <m_3> adam_g: lp:principia/haproxy under the reverse-proxy-relation-xxx uses "relation-list" too
[21:39] <niemeyer> adam_g: add-unit just work for all kinds of relations
[21:39] <adam_g> great
[21:39] <adam_g> a second issue
[21:39] <niemeyer> adam_g: Of course, the service has to be aware of it needs to support multiple units in the same relation
[21:39] <niemeyer> adam_g: In the near future we'll define max-units
[21:39] <niemeyer> or similar
[21:39] <adam_g> instead of using relation-set to pass a KEY=VALUE to the peer, i need to send a gzip archive. :)
[21:40] <niemeyer> adam_g: Uh oh :)
[21:40] <niemeyer> adam_g: That's generally not great to be sending that way, but for now it should work to base64 encode it
[21:40] <niemeyer> adam_g: The detail to be aware of is that this is going to memory
[21:40] <adam_g> right
[21:40] <niemeyer> adam_g: I really want us to have a storage mechanism tied to Ensemble itself
[21:41] <adam_g> i was thinking of dumping it to s3 and passing the url via relation-set, but that'd require credentials 
[21:41] <niemeyer> adam_g: So that we can do integrated file storage operations like this at will
[21:41] <niemeyer> adam_g: yeah
[21:41] <niemeyer> adam_g: Is the file big?
[21:41] <adam_g> no, ~200k
[21:41] <niemeyer> adam_g: I'd say base64-encode it, to get going
[21:42] <adam_g> actually, s3 is a stupid idea. swift provides s3 storage. s3 is only an option when testing in ec2
[21:42] <niemeyer> adam_g: It's a nice problem to have :)
[21:43] <SpamapS> it would be useful if ensemble abstracted a shared file storage mechanism away, since it is guaranteed to have one available for formulas.
[21:43] <niemeyer> adam_g: 200k in memory won't be a big deal right now.. once we smooth out other corners, we can fix that in a more elegant fashion
[21:43] <niemeyer> SpamapS: Agreed
[21:43] <SpamapS> adam_g: What about just popping up a webserver on an alternate port and serving it up that way? I did that for mysql replication snapshots.
[21:44] <SpamapS> when slaves join I feed them a url to fetch the latest snapshot
[21:44] <adam_g> thats an option as a work around
[21:44] <SpamapS> niemeyer: https://launchpad.net/~gophers/+archive/go is that the official go pa ?
[21:45] <niemeyer> SpamapS: This is dying, pretty much
[21:45] <niemeyer> SpamapS: But it is
[21:45] <SpamapS> adam_g: It works pretty well really.. I lock it down so only the slaves can grab the snapshot
[21:45] <SpamapS> niemeyer: its not even working. :(
[21:45] <niemeyer> SpamapS: We'll be using packages from Debian
[21:45] <SpamapS> niemeyer: well I want it on natty
[21:45] <niemeyer> SpamapS: Why not?
[21:45] <SpamapS> W: Failed to fetch http://ppa.launchpad.net/golang/ppa/ubuntu/dists/natty/main/source/Sources  404  Not Found
[21:45] <niemeyer> Huh
[21:45] <SpamapS> oh wait
[21:45] <SpamapS> thats the other one
[21:45] <SpamapS> n/m
[21:45] <niemeyer> I have no idea about what'd be going on there
[21:45] <adam_g> SpamapS: seems strange to be worrying about a utility webserver from within a formula, tho. maybe it would make sense to run something like that on the bootstrap node, and formulas can publish to / grab from as needed
[21:45] <niemeyer> Ok
[21:46] <SpamapS> adam_g: in the case of the mysql server, that would be 100GB files.. :-P
[21:46] <_mup_> ensemble/expose-provider-ec2 r287 committed by jim.baker@canonical.com
[21:46] <_mup_> More mocks for EC2 port ops
[21:47] <SpamapS> adam_g: eventually I want the url to stream the results of mysqldump if its big.
[21:47] <niemeyer> adam_g: Yeah
[21:48] <m_3> adam_g: because of your proxy<->storage relation, you might not need real "peer" relations between storage nodes
[21:52] <_mup_> ensemble/expose-provider-ec2 r288 committed by jim.baker@canonical.com
[21:52] <_mup_> Change example formula
[22:02] <m_3> SpamapS: I've got an interface naming problem...
[22:02] <m_3> SpamapS: mysql provides relation 'db' with interface 'mysql'
[22:03] <m_3> SpamapS: postgresql provides relation 'db' with interface 'postgresql'
[22:03] <m_3> but now when something wants to consume these...
[22:04] <m_3> it needs to do two optional interfaces?
[22:11] <SpamapS> uh, no?
[22:11] <SpamapS> the relation name is meaningless
[22:11] <SpamapS> call it db-mysql and db-postgresql if they can do either/or
[22:12] <m_3> I'm getting no endpoints on add-relation unless I do something like
[22:12] <m_3> http://pastebin.com/9jaRyy3g
[22:13] <m_3> the formula doesn't care which db it is
[22:13] <m_3> oh, wait, I see what you mean
[22:14] <m_3> thanks
[22:14] <SpamapS> I suggest that you *always* explicitly say which relation you mean
[22:14] <SpamapS> the implicit stuff is cool, but leads to confusion
[22:14] <m_3> they still both have to be optional though
[22:15] <m_3> so it's the same difference if it's the same hooks
[22:16] <m_3> but I'll use the more specific relation names
[22:16] <SpamapS> optional meaning not "required" ?
[22:16] <SpamapS> I think the word Requires: is a bit misleading in the metadata.
[22:16] <SpamapS> many of these are just things that the service *can* use
[22:16] <m_3> optional: true
[22:16] <SpamapS> not that it must use.
[22:17] <SpamapS> is that a valid used metadata flag?
[22:17] <m_3> seems to be, but I guess it's redundant based on what you just said
[22:17] <m_3> it's not like it waits for relations before setting the service state to 'started'
[22:34] <SpamapS> m_3: right but when we start doing a lot of auto-resolution.. it may matter
[22:37] <m_3> SpamapS: yeah, looks like one of those planned lockdowns according to the docs
[22:38] <m_3> SpamapS: how long have you been up now?  you were in the logs waaaaay early