[00:00] <jimbaker> SpamapS, nice, sounds very complementary to what i need
[00:00] <SpamapS> That way we can give everybody in the ensemble team access to modify things.
[00:01]  * SpamapS just made it exposable by adding open-port
[00:01] <jimbaker> good to see that functionality working out nicely
[00:02] <jimbaker> although it will be nicer once expose-cleanup lands
[00:11] <_mup_> Bug #833446 was filed: Schema library is needed in Go <Ensemble:New> < https://launchpad.net/bugs/833446 >
[01:34] <_mup_> ensemble/local-ubuntu-provider r326 committed by kapil.thangavelu@canonical.com
[01:34] <_mup_> refactor net/zk utils into classes, add local machine
[08:45]  * hazmat yawns
[13:24]  * hazmat bashes head against java classpath
[14:02] <niemeyer> hazmat: Don't waste your head on that one ;)
[14:03] <niemeyer> SpamapS, hazmat: What's the state of the fix-s3-port branch/change?
[14:03] <niemeyer> Robert provided some feedback on the merge proposal and it's sitting idle for a couple of weeks now
[14:03] <niemeyer> https://code.launchpad.net/~clint-fewbar/txaws/fix-s3-port/+merge/71289
[14:05] <SpamapS> I forgot to respond to him.. need to add tests but did actually address his initial concern.
[14:38] <hazmat> i built on SpamapS's branch with additional fixes (post the additional tests afaicr)
[15:19] <niemeyer> Lunch before meeting
[15:19] <niemeyer> biab
[15:19] <jimbaker> niemeyer, see you then
[15:31] <fwereade> failure on trunk: trivial fix http://paste.ubuntu.com/674572/
[15:31] <fwereade> someone approve?
[15:36] <fwereade> jimbaker: ping
[15:53] <hazmat> fwereade, +1
[15:53] <jimbaker> fwereade, hi
[15:53] <jimbaker> that was super annoying, i stepped outside i got stung by some sort of wasp
[15:53] <fwereade> jimbaker: just pinged yu because you'd spoken most recently 
[15:54] <fwereade> ouch :(
[15:54] <fwereade> jimbaker: I have my +1 now
[15:54] <fwereade> hazmat: thanks
[15:54] <jimbaker> fwereade, sounds good
[15:54] <hazmat> i missed that when i was doing the trivial yesterday :-(
[15:55] <hazmat> i reordered the params while doing output diffs for ftests
[15:55] <jimbaker> interesting, it of course worked for me ;)
[15:55] <jimbaker> i wasn't going to approve it otherwise
[15:56] <fwereade> hazmat: no worries, these cursed ordering things happen ;)
[15:57] <jimbaker> there are certainly more in our code
[15:58] <jimbaker> or specifically, our tests
[15:59] <jimbaker> ordering issues like these is but one more reason that doctests are flawed (but potentially nice for documenting apis, if not too strict)
[16:10] <niemeyer> Meeting time?
[16:10] <niemeyer> robbiew: are you joining today?
[16:10] <niemeyer> Daviey?
[16:10] <fwereade> niemeyer: sounds good
[16:10] <robbiew> can't...otp
[16:10] <robbiew> could I get a calendar invite? then I won't schedule over it ;)
[16:11] <niemeyer> robbiew: Same bat-time every week.. we'll try to sort out invites
[16:13] <robbiew> cool
[16:15] <_mup_> Bug #833906 was filed: go and python schema implementations could drift out of sync <Ensemble:New> < https://launchpad.net/bugs/833906 >
[16:15] <Daviey> niemeyer: I'm here watching :)
[16:15] <jimbaker> just waiting for g+
[16:15] <Daviey> ah, g+.. :/
[16:16] <Daviey> I can't do that this week.. Sorry.
[16:16] <niemeyer> Daviey: No worries.. pinged mostly because you demonstrated interest recently
[16:17] <Daviey> niemeyer: Oh, very much so... beta freeze today making my life interesting.
[16:18] <niemeyer> hazmat, fwereade, jimbaker: Should I start?
[16:18] <hazmat> niemeyer, got it
[16:18] <jimbaker> niemeyer, sounds good
[16:19] <niemeyer> hazmat: got it means you've already sent an invite?
[16:19] <jimbaker> but i still don't see the hangout
[16:19] <hazmat> invite sent
[16:19] <niemeyer> Yeah, cool
[16:20] <niemeyer> hazmat: We can hear you
[16:20] <niemeyer> hazmat: Can you hear us?
[16:20] <hazmat> niemeyer, no
[16:21] <jimbaker> are we on g+, because i don't see any active hangouts for hazmat or niemeyer 
[16:21] <hazmat> jimbaker, i might have the wrong email addr for you
[16:21] <jimbaker> james.edward.baker@gmail.com
[16:22] <jimbaker> hazmat, ^^^
[16:22] <niemeyer> jimbaker: Sent
[16:24] <hazmat> http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html#sc_configuration
[16:26] <niemeyer> hazmat: 
[16:26] <niemeyer>             } else if (key.equals("clientPort")) {
[16:26] <niemeyer>                 clientPort = Integer.parseInt(value);
[16:26] <niemeyer>             } else if (key.equals("clientPortAddress")) {
[16:26] <niemeyer>                 clientPortAddress = value.trim();
[16:36] <fwereade> g+ doesn't like me suddenly :/
[16:37] <fwereade> nope, it really doesn't want me to rejoin
[16:40] <hazmat> 127.0.1.1
[16:40] <niemeyer> hazmat: 127.0.0.1/8 <= loopback
[16:40] <niemeyer> 127.*.*.*
[16:41] <niemeyer> 10.0.0.0/8
[16:41] <niemeyer> 192.168.0.0/16
[16:41] <hazmat> 127.0.0.1 is bound in the container to the container, 127.0.1.1 is boudn to the host
[16:42] <niemeyer> 10.1.2.3
[16:44] <hazmat> 192.168.1*
[16:45] <hazmat> 192.168.122.*
[16:50] <hazmat> https://bugs.launchpad.net/nova/+bug/829880
[16:50] <_mup_> Bug #829880: object store doesn't like key with '/'  <Ensemble:Triaged by hazmat> <OpenStack Compute (nova):Confirmed> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/829880 >
[17:10] <niemeyer> fwereade: 
[17:10] <niemeyer> -    user_data = format_cloud_init(
[17:10] <niemeyer> -        ssh_key, packages=packages, scripts=INSTALL_SCRIPTS)
[17:10] <niemeyer> +    cloud_init = CloudInit()
[17:10] <niemeyer> +    cloud_init.authorized_keys = [ssh_key]
[17:10] <niemeyer> +    cloud_init.packages = packages
[17:10] <niemeyer> +    cloud_init.scripts = INSTALL_SCRIPTS
[17:11] <niemeyer> +    user_data = str(cloud_init)
[17:29] <niemeyer> http://goneat.org/lp/gozk
[17:34] <niemeyer> http://goneat.org/pkg/launchpad.net/gozk/#ZooKeeper.GetW
[17:35] <niemeyer> machine.AddUnit
[17:39] <niemeyer> hazmat: func (c listC) Coerce(v interface{}, path []string) (interface{}, os.Error) {
[17:40] <niemeyer> func (e error) String() string {
[17:41] <niemeyer> func (e error) String() string {
[17:41] <niemeyer>         var path string
[17:41] <niemeyer>         if e.path[0] == "." {
[17:45] <niemeyer> type Checker interface {
[17:45] <niemeyer>         Coerce(v interface{}, path []string) (newv interface{}, err os.Error)
[17:45] <niemeyer> }
[17:45] <niemeyer>         if reflect.TypeOf(v).Kind() == reflect.Bool {
[17:59] <SpamapS> I noticed bug 832043 was just marked 'Fix Released' .. does that mean full orchestra support has landed int runk?
[17:59] <_mup_> Bug #832043: can't deploy on orchestra <Ensemble:Fix Released by fwereade> < https://launchpad.net/bugs/832043 >
[17:59] <SpamapS> If so, thats reason enough for a feature freeze exception.
[18:15] <SpamapS> can somebody login here and let me know if they're allowed to administer jenkins or not: http://ec2-107-20-64-136.compute-1.amazonaws.com:8080/
[18:15] <jimbaker> SpamapS, checking
[18:16] <jimbaker> SpamapS, i see it, but i cannot administer
[18:16] <jimbaker> that would be a good thing ;)
[18:16] <SpamapS> did you login?
[18:17] <SpamapS> (top right link)
[18:17] <jimbaker> SpamapS, i don't have a login, and yes i tried
[18:17] <SpamapS> You don't have a launchpad account?
[18:17] <SpamapS> I find that hard to believe. :)
[18:17] <SpamapS> So it didn't send you to launchpad? :-/
[18:18] <jimbaker> SpamapS, ahh, i see this is in the context of open id integration
[18:18] <jimbaker> SpamapS, no that's not working
[18:18] <jimbaker> (and yes, i do have an lp account ;) )
[18:19] <SpamapS> whats your lp username?
[18:20] <SpamapS> jimbaker: when you say it did not work, it dodn't even try to redirect you to LP for openid, or it gave an error?
[18:20] <hazmat> SpamapS, login link fails.. Error
[18:20] <hazmat> Failed to login: null
[18:20] <jimbaker> SpamapS, to be precise - i'm seeing what hazmat just posted
[18:20] <jimbaker> and there's some brief activity where my browser is talking to launchpad
[18:21] <jimbaker> in terms of status flying by
[18:22] <SpamapS> tailing logs, can somebody try again?
[18:24] <jimbaker> i tried, i actually went through open id this time, but it still failed with Failed to login: null
[18:24] <SpamapS> jimbaker: it added you
[18:24] <SpamapS> jimbaker: you exist in Jenkins now
[18:24] <SpamapS> but you may not have any rights
[18:25] <jimbaker> you're right, i'm logged in
[18:25] <jimbaker> i can add projects
[18:25] <SpamapS> You can probably do anything
[18:25] <jimbaker> apparently so
[18:26] <SpamapS> If you have the 'Manage Jenkins' link then I have achieved great success. :)
[18:26] <SpamapS> jimbaker: now to figure out how to put that in the formula. :)
[18:27] <jimbaker> just installed the bzr plugin, so yeah it looks mostly there
[18:27] <jimbaker> just need to fix the failed to login noise
[18:27] <SpamapS> Not sure where thats coming from
[18:27] <SpamapS> I don't get it.
[18:27] <jimbaker> (when actually successful)
[18:27] <jimbaker> neither do i
[18:28] <SpamapS> well anybody in ~ensemble can play with that jenkins now. :)
[18:28] <jimbaker> SpamapS, sweet, i will definitely do so
[18:29] <SpamapS> jimbaker: I imported your ssh key, so you can also ssh to the box. But please document anything that you wouldn't consider "data" so I can put it in the formula.
[18:30] <jimbaker> SpamapS, sounds good
[18:54] <SpamapS> niemeyer: so, given Jay Pipes' response to the objectstore/swift question.. maybe we need an optional 'filestore-protocol:' parameter for the ec2 provider which will make file storage use swift and/or nova-objectstore instead?
[19:07] <niemeyer> SpamapS: Man.. I've been looking through my email to read whatever he said but I can't move fast enough
[19:07] <niemeyer> SpamapS: I've been answering things before reaching it :)
[19:08] <SpamapS> niemeyer: one more chainsaw to keep in the air
[19:12] <niemeyer> Yeah, I clearly misunderstood the goals of OpenStack in terms of AWS compatibility
[19:15] <SpamapS> feature parity is goal #1 .. AWS compatibility is counter to Rackspace's goals.
[19:24] <Daviey> SpamapS: what bug # is that?
[19:25] <SpamapS> bug 829880
[19:25] <_mup_> Bug #829880: object store doesn't like key with '/'  <Ensemble:Triaged by hazmat> <OpenStack Compute (nova):Confirmed> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/829880 >
[19:26] <Daviey> *sigh*
[19:27] <SpamapS> Daviey: btw, what time is beta freeze? I am trying to debug this LVM issue.. takes a while to iterate tho.. :-P
[19:34] <Daviey> SpamapS: 21:00 UTC .. so 2 hours.
[19:34] <Daviey> err, 1.5
[19:35] <Daviey> SpamapS: I would suggest doing it gently is better than rushing it.. It's probably not going to miss beta 1 if done by end of week.
[19:35] <SpamapS> Takes a good 10 minutes just to reproduce.. :-P
[19:36] <SpamapS> Actually it didn't happen
[19:36] <SpamapS> that was a pretty old image.. maybe its been fixed
[20:03] <niemeyer> jimbaker, bcsaller, hazmat: We need another review on this: https://code.launchpad.net/~fwereade/ensemble/cobbler-zk-connect-error-messages/+merge/72033
[20:03] <niemeyer> It's a bit large but there isn't much logic there, so shouldn't take too long
[20:10] <jimbaker> niemeyer, i will take a look after walking my dog
[20:10] <niemeyer> jimbaker: Cheers!
[20:17] <_mup_> ensemble/local-ubuntu-provider r327 committed by kapil.thangavelu@canonical.com
[20:17] <_mup_> better zookeeper management
[20:17] <_mup_> ensemble/local-ubuntu-provider r328 committed by kapil.thangavelu@canonical.com
[20:17] <_mup_> local-dev file storage
[20:18] <niemeyer> jimbaker: On expose-cleanup, you got [9] in the opposite direction
[20:19] <niemeyer> jimbaker: I was pointing out that you don't have to wait for deletion to finish on all of the removed groups before running another round
[20:19] <niemeyer> jimbaker: since it kills parallelism unnecessarily
[20:19] <niemeyer> jimbaker: You can wait for them to finish after _all_ of the groups have been deleted
[20:19] <niemeyer> jimbaker: Instead, you've moved backwards, and made it wait on each individual group's deletion
[20:24] <niemeyer> jimbaker: I've put these comments back in the review with [11] and [12]
[20:24] <niemeyer> jimbaker: Still +1 on it
[20:25] <niemeyer> Then, I just need a second review on go-schema, and that's eureka review-clean
[20:37] <jimbaker> niemeyer, thanks, sorry for my confusion there. but i will change it accordingly
[20:37] <niemeyer> jimbaker: No worries, it's looking very good overall
[20:38] <niemeyer> Coffee break
[20:38] <jimbaker> i will also review go-schema
[21:04] <_mup_> ensemble/local-ubuntu-provider r329 committed by kapil.thangavelu@canonical.com
[21:04] <_mup_> additional managed zk test, optional filtering if zk not installed via package
[23:34] <adam_g> hey, when using config.yaml and adding units to a service, is it possible to have different service units using differnet configuration values?
[23:35] <adam_g> ie, config.yaml contains 'some_parameter: value1' for the first and second service unit, but the third time add-unit, is it possible to have 'some_parameter: value2' either by editting config.yaml before 'add-unit' or setting it on command line?
[23:47] <niemeyer> adam_g: No.. I'm curious to understand the use case you have in mind, though
[23:47] <niemeyer> adam_g: Service units are supposed to be deployments of the same service, so the whole logic in terms of configuration and in terms of what the admin is presented goes around that conceptual representation
[23:48] <niemeyer> adam_g: Naturally, units can contain differences (e.g. one may be a master, etc).. but as far as the admin and other units are concerned, they are a cluster sharing a configuration that can be maniupated as a single block
[23:49] <niemeyer> adam_g: If you see this is somehow creating issues for you, it'd be very interesting for us to understand how that's the case
[23:49] <niemeyer> That said, I have to step out for dinner with friends right now
[23:50] <niemeyer> adam_g: If you have some notes on the topic, would you mind to please sparkle some debate in the list on it?
[23:50] <adam_g> niemeyer: sure
[23:50] <adam_g> my main use case for this:
[23:51] <adam_g> swift-storage nodes use a local block device, format it, and mount it somewhere to be used by the service.  as such, config.yaml has a 'block_device' argument that lets it know what storage to use
[23:52]  * Daviey glazes over whilst he tries to work out what is going on.
[23:52] <adam_g> if i'm creating a pool of storage nodes across 100 nodes, its likely the storage layout would differ from node to node
[23:53] <adam_g> but, i suppose being able to modify that on-the-fly during add-unit would be useless unless i could also specify the machine i'd like to use for the new unit