[00:06] <_mup_> ensemble/expose-provision-machines-reexpose r296 committed by jim.baker@canonical.com
[00:06] <_mup_> Mocked version of verifying connection closed terminates topology watch
[00:09] <_mup_> ensemble/expose-provision-machines-reexpose r297 committed by jim.baker@canonical.com
[00:09] <_mup_> Removed need for mocking
[00:24] <_mup_> ensemble/expose-provision-machines-reexpose r298 committed by jim.baker@canonical.com
[00:24] <_mup_> Test clean up/comments; also now test what happens when the client is disconnected before the watch is even started
[00:42] <_mup_> ensemble/expose-provision-machines-reexpose r299 committed by jim.baker@canonical.com
[00:42] <_mup_> Comment
[00:43] <_mup_> ensemble/expose-provision-machines-reexpose r300 committed by jim.baker@canonical.com
[00:43] <_mup_> Removed unused import
[00:49] <_mup_> Bug #812619 was filed: Re-exposing a service does not work with the provisioning agent <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/812619 >
[12:00] <fwereade> does anyone know anything abut the config parsing in ensemble?
[12:31] <niemeyer> Morning all
[12:31] <niemeyer> fwereade: I'm sure someone knows about it :-)
[12:31] <niemeyer> fwereade: What are you looking for?
[12:32] <fwereade> niemeyer: I've written a test for the orchestra schema, and I can't get both that and the ec2schema tests to pass at the same time
[12:32] <fwereade> niemeyer: the problem is that we get an error for every schema we check
[12:33] <fwereade> niemeyer: and we don't necessarily get the one I'm testing for
[12:33] <fwereade> niemeyer: (that's controlled by the order in which we specify the provider schemas in the OneOf)
[12:34] <fwereade> niemeyer: am I missing something obvious? :)
[12:34] <niemeyer> fwereade: Hard to tell without knowing what the error is
[12:35] <fwereade> niemeyer: if I'm missing (say) orchestra-server, then we get an exception from coerce()
[12:35] <fwereade> niemeyer: quite rightly
[12:35] <niemeyer> fwereade: Can you please paste the error and the code somewhere?
[12:35] <fwereade> niemeyer: but we also get an exception when we attempt to coerce() to the EC2 schema, because we don't have (say) control-bucket
[12:36] <fwereade> http://paste.ubuntu.com/647260/
[12:36] <niemeyer> fwereade: Well, we shouldn't attempt to coerce an orchestra config to an EC2 schema
[12:36] <fwereade> niemeyer: agreed
[12:37] <niemeyer> fwereade: They have to be separate schemas
[12:37] <fwereade> niemeyer: hm, ok, so we just do a first pass to determine the type
[12:38] <fwereade> niemeyer: and then try to apply the actual schema we've detected
[12:38] <fwereade> niemeyer: it's not intractable, but I didn't want to lay heavily into that section of code without checking with someone
[12:39] <niemeyer> fwereade: Hmmm.. just a sec
[12:39] <fwereade> niemeyer: no rush, I was just about to have lunch anyway
[12:40] <fwereade> niemeyer: and I've got some unrelated issue with my VMs that I need to sort out before I can be confident it's worth proposing a merge
[12:41] <fwereade> niemeyer: (I have the cobbler communication tested, and I can boot machines, but they don't actually manage to install)
[12:41] <fwereade> niemeyer: talk later?
[12:44] <niemeyer> fwereade: I see what you mean
[12:44] <niemeyer> fwereade: This is a shortcoming in our schema library
[12:44] <niemeyer> fwereade: Let me ponder for a moment on the issue and we catch up later
[12:45] <niemeyer> fwereade: You're not blocked on this, right?
[12:45] <niemeyer> fwereade: I think you're doing the right thing, FWIW.. it's just the schema library itself that should be fixed
[13:29] <lynxman> hey guys, I have a question for you :)
[13:29] <lynxman> got ensemble module on Mac but when I execute it says
[13:29] <lynxman> ImportError: No module named zookeeper
[13:29] <lynxman> that I assume is not the txzookeper python library
[13:29] <lynxman> so which one should I look to import?
[13:30] <lynxman> zookeeper itself?
[13:36] <lynxman> ello? :)
[13:50] <niemeyer> lynxman: Hey
[13:50] <niemeyer> lynxman: Yeah, that's the C extension that is provided by zookeeper itself
[13:51] <niemeyer> lynxman: txzookeeper is a wrapper on top of that which "Twistifies" (ugh) the library
[13:52] <fwereade> niemeyer: that was my reading of the issue, but I thought it was worth checking ;)
[13:53] <fwereade> niemeyer: and no, I'm not blocked yet, but I should be in a little while
[13:54] <fwereade> niemeyer: I'll let you know when it bcomes urgent :)
[13:59] <lynxman> niemeyer: cool, so I'll just create the python extensions for that :)
[14:11] <niemeyer> fwereade: Thanks :)
[14:11] <niemeyer> lynxman: Super :)
[14:50] <RoAkSoAx> fwereade: howdy! do you think I should do something like this?: http://paste.ubuntu.com/647347/
[14:58] <fwereade> RoAkSoAx: sounds sensible to me
[14:58] <fwereade> RoAkSoAx: will make it easy to pull out whatever's common
[14:59] <fwereade> RoAkSoAx: btw, you remember we got everything running on my machine
[14:59] <fwereade> RoAkSoAx: seems we didn't quite, was wondering if you had a few minutes to point me in the right direction
[15:00] <fwereade> RoAkSoAx: I can launch a machine but the install doesn't complete
[15:01] <RoAkSoAx> fwereade: you need to change the IP of the proxy
[15:02] <RoAkSoAx> fwereade: in the preseed
[15:04] <RoAkSoAx> fwereade: that's what comes to my mind
[15:05] <fwereade> RoAkSoAx: the first errors I see are a couple of "debconf-copydb: cannot open question file"s
[15:06] <fwereade> RoAkSoAx: but it keeps doing stuff after that
[15:07] <fwereade> RoAkSoAx: it starts to look fatal around "cannot stat /etc/default/puppet", while setting up ubuntu-orchestra-client
[15:19] <lynxman> niemeyer: just FYI, it's done https://trac.macports.org/ticket/30237
[15:20] <RoAkSoAx> fwereade: remove orchestra-client from the preseed
[15:20] <RoAkSoAx> fwereade: or extra packages
[15:20] <RoAkSoAx> that is from the preseed *inside* the cobbler VM
[15:20] <RoAkSoAx> /var/lib/cobbler/kickstarts/ensemble.preseed I think
[15:26] <fwereade> RoAkSoAx: thanks: it took me an embarrassingly long time peering at the kickstarts dir on the host system before the penny dropped there
[15:28] <hazmat> lynxman, awesome
[15:29] <hazmat> lynxman, does the live check stuff mean it will auto pull the latest?
[15:29] <hazmat> hmm. probably not with the checksums
[15:31] <lynxman> hazmat: nope, we'll have to update manually for now
[15:32] <lynxman> hazmat: macports is like BSD ports, it requires static versions, but once it's there updating it is easier
[15:33] <_mup_> ensemble/trunk r276 committed by kapil.thangavelu@canonical.com
[15:33] <_mup_> merge deploy-tolerates-broken-formulas-bug-810765 [r=fwereade,jimbaker][f=810765]
[15:33] <_mup_> Ensemble deploy will behave nicely when formulas in a repository have broken metadatas, by ignoring them.
[15:36] <_mup_> ensemble/trunk-merge r270 committed by kapil.thangavelu@canonical.com
[15:36] <_mup_> merge trunk
[15:41] <_mup_> ensemble/security-node-policy-def r276 committed by kapil.thangavelu@canonical.com
[15:41] <_mup_> address review comments, inline owner_ace func, additional doc comments on rule signature.
[15:47] <RoAkSoAx> fwereade: heh it happens
[16:05] <niemeyer> lynxman: Woot!
[16:08] <lynxman> niemeyer: \o/
[16:08] <lynxman> niemeyer: as soon as it's live mac developers will be able to use and deploy ensemble as well
[16:08] <lynxman> (client side of course)
[16:08] <niemeyer> lynxman: Please keep us updated.. quite curious to see how that'll go
[16:09] <lynxman> niemeyer: will do :)
[16:10] <niemeyer> Alright.. I'll step out for lunch
[16:10] <niemeyer> Just off of a meeting
[16:10] <niemeyer> Oh
[16:10] <niemeyer> Btw,
[16:11] <niemeyer> For those who didn't receive it, we have a developer (all formula and core are welcome) meeting today at 17:30UTC for sync up
[16:11] <niemeyer> (voice)
[16:11] <niemeyer> In Google+
[16:11] <niemeyer> Please be here if you're interested
[16:12]  * niemeyer => lunch
[16:14] <_mup_> Bug #810808 was filed: Formula install hook never completes <Ensemble:In Progress> < https://launchpad.net/bugs/810808 >
[16:33] <kirkland> niemeyer: how does one attend this meeting?
[16:34] <kirkland> niemeyer: is it irc only?
[16:34] <kirkland> niemeyer: i see "(voice)" and "In Google+", but I don't see how to join
[16:36] <bcsaller> kirkland: I think someone has to start it which hasn't happened yet as far as I can see
[16:38] <kirkland> bcsaller: kthx
[16:39] <_mup_> Bug #812996 was filed: Deploy should support config options <Ensemble:In Progress by bcsaller> < https://launchpad.net/bugs/812996 >
[16:43] <hazmat> bcsaller, it looks like you have a conflict against trunk in that merge proposal
[16:47] <hazmat> kirkland, are you on google plus?
[16:47] <kirkland> hazmat: sadly, yes
[16:47] <robbiew> hangouts are cool...but setting them up sucks
[16:48] <robbiew> unless you create a damn circle for each individual friend...or always hangout with the same group </rant>
[16:48] <SpamapS> You don't have to "hangout" .. you can just video chat with somebody
[16:49] <fwereade> SpamapS: where's the fun in that?
[16:49] <robbiew> but if I want to video chat with 2 people...I need to hangout, right?
[16:49] <SpamapS> Probably
[16:49] <robbiew> if those two people are in my circles, i should be able to just select them and hang...but you can't 
[16:50] <robbiew> you have to invite them..and hope you have the right address for them that they've used with google +
[16:50] <robbiew> Beta crap
[16:50] <SpamapS> your worlds... will collide
[16:50] <robbiew> </rant..for real>
[16:50] <robbiew> I guess I'm getting what I paid for
[16:50] <robbiew> lol
[16:52] <kirkland> robbiew: you're paying with your own soul
[16:53] <hazmat> fwereade, niemeyer, jimbaker  .. we're all hanging out in hangout if your interested
[16:54] <jimbaker> hazmat, i've been following this discussion about the hangout - but is there a URL for it?
[16:54] <hazmat> jimbaker, you have to be logged into google plus, and it should appear there
[16:54] <jimbaker> let me check it again... i just joined yesterday
[16:56] <jimbaker> hazmat, looked around the page, just see something about creating a hangout
[16:59] <hazmat> jimbaker, i'll send another link
[16:59] <hazmat> jimbaker, what's your icon.. there are lots on google +
[17:00] <jimbaker> hazmat, my icon? ;)
[17:00] <hazmat> jimbaker, its hard to figure out which of the many is you
[17:01] <jimbaker> hazmat, i guess i'm the one who has not yet associated a picture w/ my account yet
[17:04] <hazmat> jimbaker, there are lots of those.. do you have profile info filled out?
[17:04] <hazmat> jimbaker, actually easier might just be sending me your gmail address via priv msg
[17:05] <jimbaker> hazmat, i just added two bits - my picture, and employment at canonical
[17:10] <jimbaker> btw, my desktop doesn't have audio input
[17:11] <jimbaker> i will have to switch over to my laptop instead
[17:14] <_mup_> ensemble/trunk r277 committed by kapil.thangavelu@canonical.com
[17:14] <_mup_> merge security-node-policy-def [r=niemeyer,bcsaller][f=810510]
[17:14] <_mup_> A security policy implementation that returns ACLs for zk nodes by path.
[17:20] <niemeyer> hazmat: Oh, wasn't it 17:30?
[17:20] <niemeyer> I'll join
[17:22] <niemeyer> Hmm
[17:22] <niemeyer> bcsaller, fwereade, jimbaker, m_3: ping?
[17:22] <jimbaker> niemeyer, hi
[17:22] <bcsaller> niemeyer: ready when you are
[17:22] <fwereade> niemeyer: heyhey
[17:22] <fwereade> niemeyer: we're all hanging out
[17:22] <niemeyer> fwereade: Where?
[17:23] <niemeyer> I don't have any invitations here
[17:23] <fwereade> niemeyer: google plus somewhere... not sure who set it up
[17:23] <niemeyer> fwereade: Someone has to invite me
[17:23] <niemeyer> fwereade: and bcsaller/jimbaker, I suppose
[17:24] <fwereade> niemeyer: done, I think
[17:24] <jimbaker> hazmat is the person who set up the hangout
[17:25] <jimbaker> i think the easiest way is for every person who wants to join the meeting to pm hazmat their gmail address, assuming they have one
[17:26] <niemeyer> fwereade: No, nothing here
[17:27] <fwereade> heh, bizarre
[17:27] <m_3> ney niemeyer... we're "hanging"
[17:27] <fwereade> niemeyer: just tried again, just in case
[17:28] <kirkland> hazmat: how do i get in?
[17:28] <fwereade> it's a shame niemeyer's not there to enjoy our cool party
[17:28] <fwereade> :p
[17:28] <niemeyer> Ah, got from bcsaller now
[17:28] <m_3> I think ben set it up... it appeared in my stream
[17:28] <bcsaller> just now, yeah
[17:29] <niemeyer> kirkland: We have our own party now! :-)
[17:29] <kirkland> bummer
[17:30] <m_3> hazmat: we switched from that hangout to a new one
[17:32] <niemeyer> SpamapS: ping
[17:32] <kirkland> robbiew: SpamapS: you guys coming?
[17:32] <SpamapS> Where do I go?
[17:33] <jimbaker> looks like i have a problem joining from my laptop... will try again
[17:33] <adam_g> can someone send invite to gandelman.a@gmail.com plzz?
[17:33]  * robbiew has no delusions about the lack of value he will provide to the discussion
[17:34] <niemeyer> hazmat: ping?
[17:34] <niemeyer> hazmat: Where are you?
[17:35] <hazmat> niemeyer, networking hicckup
[17:36] <SpamapS> Sorry guys, I want to be there, but I don't know where there is
[17:36] <m_3> SpamapS: invited
[17:37] <m_3> adam_g: invited
[17:38] <SpamapS> m_3: I have no evidence of any invitations. :p
[17:38] <bcsaller> SpamapS: not in your stream?
[17:38] <m_3> it shows up on the stream
[17:38] <m_3> go to ben's profile
[17:39] <SpamapS> well hidden
[17:42] <niemeyer> fwereade: I can hear you
[17:43] <fwereade> niemeyer: looks like it was actually foretelling the near future
[17:43] <m_3> SpamapS: bad audio
[17:43] <fwereade> trying to rejoin
[17:46] <fwereade> not looking good :/
[18:02] <m_3> SpamapS: bad audio again
[18:10] <SpamapS> my net connection has basically failed
[18:15] <RoAkSoAx> fwereade: still arou nd?
[18:15] <fwereade> RoAkSoAx: yep
[18:15] <fwereade> RoAkSoAx: what can I do for you?
[18:16] <RoAkSoAx> fwereade: want you to review something real quick
[18:16] <fwereade> RoAkSoAx: sure :)
[18:16] <RoAkSoAx> fwereade: http://paste.ubuntu.com/647512/
[18:17] <RoAkSoAx> fwereade: so from OrchestraSaveState __init__ I'm instancing OrchestraStorage which basically obtains the connection to the storage
[18:17] <RoAkSoAx> fwereade: so my concerns are, instancing this : # FIXME: Should this be done like this?
[18:17] <RoAkSoAx>         self._storage = OrchestraStorage(self)
[18:17] <RoAkSoAx> and in OrchestraStorage
[18:17] <RoAkSoAx> obtain the config like this:
[18:17] <RoAkSoAx> self.config = provider._provider.config
[18:17] <fwereade> RoAkSoAx: I think that should be a self._provider.get_file_storage
[18:18] <fwereade> RoAkSoAx: in general I think if we can do things via the provider we should
[18:18] <RoAkSoAx> fwereade: ok so I keep the get_file_storage function on the MachineProvider then
[18:18] <fwereade> RoAkSoAx: I think so
[18:18] <RoAkSoAx> fwereade: alright, cool, thanks!
[18:19] <fwereade> RoAkSoAx: a pleasure :)
[18:37] <adam_g> is this error message meaningful to anyone? i haven't seen it before:
[18:37] <adam_g> http://paste.ubuntu.com/647521/
[18:39] <SpamapS> whoa that does look confusing
[18:39] <SpamapS> are the hooks copied to some tmp dir?
[18:40]  * SpamapS prepares an upload of ensemble that runs the test suite during build
[18:41] <adam_g> SpamapS: the file in /tmp is some template script generated by ensemble
[18:42] <adam_g> http://paste.ubuntu.com/647525/
[18:49] <SpamapS> Interesting.. here are the failures when running the test suite ina clean chroot...
[18:49] <SpamapS> http://paste.ubuntu.com/647530/
[18:50] <SpamapS> exceptions.ValueError: Could not find AWS_ACCESS_KEY_ID
[18:53] <m_3> adam_g: the kill not finding the pid just means the hook exited without removing its pid file
[18:53] <m_3> just an unclean or abnormal exit for some reason?
[18:54] <adam_g> hopefully
[18:55] <m_3> what happens in non debug-hooks mode?
[18:55] <adam_g> same
[18:56] <adam_g> or at least i think.. let me check once more
[19:12] <_mup_> ensemble/expose-provider-ec2 r293 committed by jim.baker@canonical.com
[19:12] <_mup_> Merged trunk
[19:20] <_mup_> ensemble/expose-provider-ec2 r294 committed by jim.baker@canonical.com
[19:20] <_mup_> Merged upstream expose-provision-machines-reexpose and resolved conflicts
[19:25] <_mup_> ensemble/expose-provider-ec2 r295 committed by jim.baker@canonical.com
[19:25] <_mup_> Default to NotExposed for watched_units
[19:27] <_mup_> Bug #813112 was filed: test suite cannot run without an ssh key <Ensemble:New> < https://launchpad.net/bugs/813112 >
[19:28] <niemeyer> Alright!
[19:28] <niemeyer> That was a long call
[19:37] <niemeyer> fwereade: ping
[19:40] <jimbaker> good to see the firewall actually opening/closing ports in response to the use of ensemble expose/ensemble unexpose
[19:42] <jimbaker> niemeyer, the only issue with dividing up the branches is that there's no ec2 provider implementation in expose-provision-machines; this doesn't come into place until the branch i'm currently working on, expose-provider-ec2
[19:43] <niemeyer> jimbaker: Dividing which branches in this case?
[19:43] <jimbaker> the two branches i just mentioned, expose-provision-machines and expose-provider-ec2
[19:44] <jimbaker> given that MachineProvider is a subclass of object, we don't currently have a way of defaulting say an empty implementation
[19:44] <jimbaker> expose-provision-machines works fine with the dummy provider of course
[19:45] <niemeyer> jimbaker: Sorry, ECONTEXT
[19:45] <niemeyer> jimbaker: What's the issue you're trying to address?
[19:45] <jimbaker> niemeyer, the MachineProvider implementation is required to implement open_port, close_port, get_opened_ports
[19:46] <jimbaker> this is done with the dummy provider
[19:46] <niemeyer> jimbaker: Yes, the implementation is required.. for the implementation? :-)
[19:46] <jimbaker> and is changed with the ec2 provider in expose-provider-ec2
[19:47] <jimbaker> niemeyer, maybe i should have a branch called transitional that adds these empty methods, possibly throwing some sort of error like a provider error?
[19:47] <jimbaker> alternatively, this can be merged as a group into trunk
[19:47] <niemeyer> jimbaker: Probably not, if that's not required
[19:47] <niemeyer> jimbaker: Having just the dummy implementation, and then adding the ec2 one in a follow up sounds ok
[19:47] <jimbaker> niemeyer, sounds good
[19:47] <niemeyer> jimbaker: Unless you're detecting  a problem with doing it that I'm still missing?
[19:48] <jimbaker> niemeyer, the problem is that if you run expose-provision-machines against an ec2 provider, it will fail, due to the lack of implementation
[19:49] <jimbaker> so i think the cleanest way of addressing this is to just merge these branches as a group
[19:50] <jimbaker> once they are all approved
[19:52] <jimbaker> niemeyer, the other thing is that once in trunk, this will force some formula writers and presumably all formula deployers to consider the firewall
[19:52] <jimbaker> niemeyer, so this will be an important change to communicate on my part :)
[19:53] <niemeyer> jimbaker: That's doable too
[19:54] <niemeyer> jimbaker: Yes, that sounds reasonable, on both counts
[19:54] <niemeyer> jimbaker: We should also discuss the change
[19:54] <jimbaker> niemeyer, cool
[19:54] <niemeyer> jimbaker: To see if we have to introduce a migration path or not
[19:55] <jimbaker> niemeyer, my feeling is that in discussing the migration, it would be best to combine the one line + comments change for the wordpress example formula with the doc changes (mostly from draft to main)
[19:56] <jimbaker> that would be the branch after the one i'm currently working on
[19:56] <niemeyer> jimbaker: Hmm.. the example formulas don't really worry me.. what we have to discuss with SpamapS, m_3, adam_g, negronjl, and lynxman is the fact that their formulas will stop working
[19:56] <jimbaker> niemeyer, after expose-provider-ec2 and expose-migration (the branch just discussed), there's a firewall solution in place for ec2
[19:57] <niemeyer> Well.. not really stop working per se
[19:57] <jimbaker> niemeyer, correct
[19:57] <niemeyer> They'll just not open the firewall
[19:57] <niemeyer> Which doesn't sound like a big issue, but we have to talk
[19:57] <niemeyer> jimbaker: Can you please bring up that conversation in the mailing list?
[19:57] <jimbaker> niemeyer, right, they can always manually open the firewall using their favorite tool
[19:57] <niemeyer> Yep
[19:58] <jimbaker> niemeyer, i will do the mailing list discussion
[19:58] <jimbaker> or at least kick it off ;)
[19:58] <niemeyer> jimbaker: Thanks
[19:59] <jimbaker> niemeyer, then after all this dust settles, i can then work on supporting unexpose and expose hooks. but that's more for completeness than what i would imagine is a common use case
[19:59]  * hazmat goes into review mode
[20:01] <niemeyer> hazmat?
[20:02] <negronjl> from my point of view guys, change what needs to be changed in ensemble and let me know what changed.  I'll adapt the formulas to match the work.
[20:03] <negronjl> in other words...don't worry about my formulas.  Just let me know what changed and I'll adapt them to work.
[20:03]  * negronjl is out to a meeting
[20:04] <jimbaker> negronjl, it boils down to: open-port PORT[/PROTOCOL] in a hook script; ensemble expose SERVICE_TO_BE_EXPOSED
[20:04] <jimbaker> ensemble does the rest of the work
[20:04] <niemeyer> hazmat: Looking at that can isn't fun
[20:06] <hazmat> niemeyer, back
[20:10] <adam_g> when using add-unit, is formula uploaded from locall repository to new unit or is it fetched from bootstrap node such that all units are running the same revision of a formula?
[20:17] <m_3> jimbaker, niemeyer: +1 on what negronjl said (different answer later when things are in production tho!)
[20:20] <SpamapS> I wonder if there is some sort of kernel level event service that can be tapped to find out what ports a process is using.
[20:20] <m_3> adam_g: dunno, never tried to add-unit without upgrading changes first... big issue though
[20:20] <SpamapS> like inotify but for sockets instead of files
[20:22] <m_3> SpamapS: doesn't netstat have a mode where it continues watching sockets?
[20:24] <SpamapS> m_3: --continuous .. that polls tho
[20:25] <adam_g> m_3: i'm trying to add new units that have modified configuration. is this doable?
[20:25] <SpamapS> configuration?
[20:25] <SpamapS> do we have config settings in trunk yet?
[20:26] <SpamapS> I really want to start mucking with that
[20:27] <adam_g> i need each unit deployed to have a zone # assigned to it, and i'd like to be able to decide which zone a member joins when i deploy
[20:27] <m_3> adam_g: I've only been able to do that by adding the config info to an interface and letting another related service manage it
[20:28] <adam_g> i was thinking, in the meantime, of just hard-coding and updating it each time i deploy a new unit, but that doesn't work if they all share the same revision
[20:30] <m_3> other service can do 'relation-list' on a relation-joined and then send out new info across the board
[20:30] <m_3> can peer solve this?
[20:31] <adam_g> i'd like to decide which zones new units join, not the formula
[20:31] <m_3> yeah, that's just totally config
[20:33] <m_3> we'll get a 'deploy --config local.yaml' but I don't know if that'll be an option on add-unit
[20:37] <adam_g> i think another way would be to deploy the service once for each zone, and add-units to that services/zone
[20:37] <m_3> zone_manager service, or just curl it from somewhere... bad, worse
[20:38] <m_3> separate formulas?
[20:39] <adam_g> deploy --config zone1.yaml swift-storage swift-zone1
[20:39] <adam_g> deploy --config zone2.yaml swift-storage swift-zone2
[20:39] <adam_g> add-unit swift-zone1
[20:39] <m_3> absolutely if that's in there yet
[20:39] <adam_g> not yet, im just using some hax for now.
[20:40] <m_3> that's probably the best... I've mocked up some config-get calls already
[20:41] <m_3> we'll have to see what bcsaller did with add-unit and --config
[20:42] <bcsaller> I didn't, you configure the service, not the units
[20:42] <m_3> so in adam_g's previous example, will 'add-unit swift-zone1' pick up the config?
[20:43] <m_3> (that came from a local yaml?)
[20:45] <SpamapS> add-unit, no
[20:46] <SpamapS> oops, was scrolled back
[20:49] <m_3> I'm confused then... I'll dig trhough the branch to see what's up
[20:49] <bcsaller> m_3: service options are available available in all units and are the same 
[20:50] <bcsaller> all units of a given service 
[21:01] <_mup_> ensemble/expose-provider-ec2 r296 committed by jim.baker@canonical.com
[21:01] <_mup_> Doc strings, comments, test on EC2 error when accessing instances
[21:08] <_mup_> ensemble/expose-provider-ec2 r297 committed by jim.baker@canonical.com
[21:08] <_mup_> Docstrings for test_securitygroup
[21:12] <_mup_> ensemble/expose-provider-ec2 r298 committed by jim.baker@canonical.com
[21:12] <_mup_> PEP8
[21:35] <niemeyer> Extremely sleepy right now..
[21:35] <niemeyer> Will step out and lay down a bit
[21:44]  * negronjl is back
[21:53] <_mup_> ensemble/expose-provider-ec2 r299 committed by jim.baker@canonical.com
[21:53] <_mup_> Test for EC2 errors in security group ops
[21:56] <_mup_> ensemble/expose-provider-ec2 r300 committed by jim.baker@canonical.com
[21:56] <_mup_> PEP8/PyFlakes
[22:01] <hazmat> adam_g, formulas are uploaded to formula storage (s3) and downloaded from there for each deployed unit
[22:02] <hazmat> adam_g, environment's don't span ec2 regions 
[22:02] <hazmat> we'll need to work out some sort of capability for that in the future
[22:03] <hazmat> SpamapS, service config is almost there, but not yet fully in trunk, last bits are in review
[22:05]  * SpamapS will continue meditating in the corner until said review is complete
[22:06] <hazmat> SpamapS, i'm going to be looking at the lxc stuff and your branch next week, had a long chat with niemeyer about it an hr ago.
[22:08] <SpamapS> hazmat: I'm at your disposal if you have questions
[22:11] <hazmat> SpamapS, i definitely will, thanks
[22:28] <jimbaker> ok, i just proposed a branch that pulls all the pieces together for working with the firewall
[22:29] <jimbaker> in terms of doing this on ec2, that is
[22:35] <m_3> jimbaker: do you have a rough estimate of when ensemble will default to all ports closed behavior?
[22:35] <jimbaker> m_3, the branch i just proposed implements exactly that
[22:36] <jimbaker> m_3, it might be worthwhile checking it out so you can see the impact - but i think it's going to be super minimal
[22:36] <m_3> ok, I'll keep and eye out
[22:37] <jimbaker> m_3, re "when", only when it gets through the review process of course ;) - but the only big dependency has been approved by niemeyer and is awaiting a review by hazmat
[22:37] <jimbaker> (that would be expose-provision-machines)
[22:39] <m_3> thanks!
[22:43]  * hazmat digs back into reviews