[03:45]  * hazmat pokes at upstart
[03:45] <hazmat> manual respawn
[04:03] <hazmat> SpamapS, re upstart.. i was experimenting and had this https://pastebin.canonical.com/46732/
[04:03] <hazmat> seems like i'm missing something
[04:03] <hazmat> upstart sees the job but won't run it
[04:13] <SpamapS> hazmat: initctl reload-configuration
[04:13] <SpamapS> hazmat: you shouldn't have to do that. But I think there may be something wrong w/ the inotify
[04:19] <hazmat> SpamapS, thanks
[04:20] <hazmat> SpamapS, the integration afaics at least for units, would be the machine agent dropping in new files per unit.. i looked at using instances, but we need several parameters.. still experimenting
[04:21] <hazmat> SpamapS, actually that was user error.. missed a sudo
[04:22] <hazmat> i think the inotify did pick it up
[04:23] <hazmat> hmm
[04:23] <hazmat> hmm.. i guess we'll still need to pass env vars for some scenarios where the value shouldn't be in a ps aux listing.
[04:24] <hazmat> but upstart definitely adds value
[04:27] <SpamapS> hazmat: Not sure I understand. You have ensemble's agent that needs to be running on the machine. Are you saying there are times you'll want two of them running?
[13:23] <niemeyer> Morning!
[14:17] <niemeyer> Woot, empty review column again
[14:38] <hazmat> niemeyer, nice
[15:37] <_mup_> ensemble/ensemble-alternate-regions r210 committed by kapil.thangavelu@canonical.com
[15:37] <_mup_> additional test verifying precendence of default-image-id over region
[15:59] <_mup_> ensemble/ensemble-alternate-regions r211 committed by kapil.thangavelu@canonical.com
[15:59] <_mup_> fix config test, to use prepulated data for authorized key, revert change to provider serialization, as authorized key is still required.
[16:21] <_mup_> ensemble/ensemble-alternate-regions r212 committed by kapil.thangavelu@canonical.com
[16:21] <_mup_> rename resolve_region_uri/get_region_uri, yank the static region url map for string interpolation template
[16:23] <_mup_> ensemble/ensemble-alternate-regions r213 committed by kapil.thangavelu@canonical.com
[16:23] <_mup_> merge trunk
[16:28] <_mup_> ensemble/expose-provisioning r210 committed by jim.baker@canonical.com
[16:28] <_mup_> Watch services in provisioning
[16:30] <_mup_> ensemble/ensemble-alternate-regions r214 committed by kapil.thangavelu@canonical.com
[16:30] <_mup_> document new ami per region, and precedence of ec2-uri over region.
[16:31] <_mup_> ensemble/trunk r210 committed by kapil.thangavelu@canonical.com
[16:31] <_mup_> merge ensemble-alternate-regions [r=niemeyer][f=768320]
[16:31] <_mup_> Allows for ensemble to work in different aws regions via
[16:31] <_mup_> environments.yaml specification of an environment machine provider
[16:31] <_mup_> region (us-east-1, us-west-1, eu-west-1, ap-northeast-1,
[16:32] <_mup_> ap-southeast-1). Also validates allowed region values as part of the
[16:32] <_mup_> ec2 environment schema.
[16:32] <_mup_> ensemble/expose-provisioning r211 committed by jim.baker@canonical.com
[16:32] <_mup_> Merged trunk
[16:36] <_mup_> ensemble/expose-dummy-provider r210 committed by jim.baker@canonical.com
[16:36] <_mup_> Cleanup
[16:36] <_mup_> ensemble/expose-dummy-provider r211 committed by jim.baker@canonical.com
[16:36] <_mup_> Merged trunk
[16:36] <_mup_> ensemble/ec2-deb-build r215 committed by kapil.thangavelu@canonical.com
[16:36] <_mup_> merge ensemble-alternate-regions
[16:37] <_mup_> ensemble/ec2-deb-build r216 committed by kapil.thangavelu@canonical.com
[16:37] <_mup_> merge trunk
[16:37] <_mup_> ensemble/expose-provisioning r212 committed by jim.baker@canonical.com
[16:37] <_mup_> Merged expose-dummy-provider
[16:40] <_mup_> ensemble/ec2-deb-build r217 committed by kapil.thangavelu@canonical.com
[16:40] <_mup_> extract ami to constant for debian/ec2-build
[16:43] <_mup_> ensemble/trunk r211 committed by kapil.thangavelu@canonical.com
[16:43] <_mup_> merge ec2-deb-build [r=niemeyer][f=769286]
[16:43] <_mup_> Updates all aws regions with new ensemble images, that utilize latest
[16:43] <_mup_> zookeeper release (3.3.3), this fixes several zookeeper python binding
[16:43] <_mup_> problems that caused agents to crash.
[16:52] <SpamapS> Dunno if you guys caught this, but it seems netns (as in, the network isolation part of lxc) has been removed from the lucid kernel in the latest SRU
[16:52] <SpamapS> Something to consider when testing LXC on lucid.. need to get the maverick or (better) natty backport kernel in order to have proper LXC
[16:57] <_mup_> ensemble/resolved-spec r190 committed by kapil.thangavelu@canonical.com
[16:57] <_mup_> resolved spec fixes per review.
[16:57] <_mup_> ensemble/trunk-merge r188 committed by kapil.thangavelu@canonical.com
[16:57] <_mup_> merge trunk
[16:58] <_mup_> ensemble/resolved-spec r192 committed by kapil.thangavelu@canonical.com
[16:58] <_mup_> fix an ec2 provider test pointing to an old ami :-(
[17:01] <hazmat> SpamapS, noted, though we're not really on lucid anymore at this point... everything is natty based atm
[17:02] <SpamapS> hazmat: hahahahahahahahahahahahahahahahaha
[17:02] <SpamapS> hazmat: sorry I just cackle when people think serious users will use anything non-LTS ;)
[17:02] <SpamapS> *even* in the cloud
[17:03] <hazmat> SpamapS, hmm.. true, but until we get ourselves working with the std ubuntu amis, they don't have many options
[17:03] <SpamapS> hazmat: I think its safe to say Ensemble will become what its supposed to become around 12.04 .. but 10.04 is going to be where people start hacking on it.
[17:04] <SpamapS> Sounds to me like ensemble should actually become part of the standard AMI's that we produce.
[17:04] <hazmat> SpamapS, we could produce/set those for lucid
[17:04] <hazmat> SpamapS, yeah.. that make things a bit easier.. 
[17:05] <SpamapS> Once its in main, we can do that.
[17:05] <SpamapS> Until then, ensemble will have to cheat a little.
[17:05] <hazmat> in for a penny, in for a pound ;-)
[17:05] <SpamapS> Either w/ cloud-init or its own "speshul" ami's
[17:05] <SpamapS> How's the packaging going?
[17:06] <SpamapS> Sounds like the zookeeper bits only affect the ami's you're working on..
[17:06] <hazmat> SpamapS, i finished by 'special' as in special ed.. zookeeper debs.. i need to go make and start fresh on a  clean deb for zk 3.3.3
[17:06] <hazmat> s/by/my
[17:06] <SpamapS> we're only using the special AMI's for the bootstrap node right?
[17:06] <hazmat> SpamapS, all the images have been remastered, and ensemble works now in different regions
[17:06] <hazmat> SpamapS, no.. we're using them for all nodes..
[17:06] <SpamapS> thats hot. ;)
[17:07] <SpamapS> oh thats not
[17:07] <hazmat> its more than a bit hokey.. 
[17:07] <hazmat> we don't need zk running on the other nodes
[17:07] <SpamapS> is that just because we haven't gotten around to the bit that will feed in cloud-config stuff for the agents?
[17:07] <hazmat> nor java installed
[17:07] <_mup_> ensemble/expose-ensemble-commands r215 committed by jim.baker@canonical.com
[17:07] <_mup_> Addressed review comments
[17:08] <hazmat> SpamapS, we have that, and originally we where using cloud-init for driving everything at instance startup.. but doing things like checking out ensemble,txzookeeper from trunk are still in there and take time.
[17:08] <hazmat> so same basic argument as the bootstrap.. 
[17:09] <hazmat> once we get zk, ensemble, txzoo in a ppa, we can move to just installing them in cloud-init 
[17:09] <hazmat> and ditch the 'special' amis
[17:09] <SpamapS> hazmat: checking out? Come on.. you've got a PPA and a .deb :)
[17:09] <hazmat> the latency for the bootstrap would still exist (installing java stack and friends).
[17:10] <SpamapS> hazmat: we have them in ~ensemble/ppa now
[17:10] <hazmat> SpamapS, :-) true, but at the moment its very helpful to ensure trunk is always working
[17:10] <_mup_> ensemble/expose-ensemble-commands r216 committed by jim.baker@canonical.com
[17:10] <_mup_> Modified too_many_args tests to update to argparse 1.2/python 2.7 error messages
[17:11] <hazmat> SpamapS, yeah.. we should discuss doing a real release based on that ppa for uds.
[17:11] <SpamapS> hazmat: this part really could get tricky
[17:12] <hazmat> living on trunk is probably more dev oriented, but considering how young and rapid the pace, its still our quickest way forward, but its not clear if we want to subject early adopters to the same.
[17:12] <SpamapS> hazmat: Its important that the bootstrap node know it can talk to the spawned machines.. so it should be very careful how and where it tells the machines to grab their agent
[17:12] <hazmat> SpamapS, indeed, that is a problem now
[17:12] <hazmat> trunk skew between deploys
[17:13] <SpamapS> I think the default would be to have the bootstrap node try to apt-get install ensemble=${binary:Version}
[17:13] <hazmat> i've got an open ticket that we should at least be recording the rev/release number per machine so its identifiable.
[17:13] <SpamapS> And have an environment and service override available for a different version if need be
[17:14] <_mup_> ensemble/trunk r212 committed by kapil.thangavelu@canonical.com
[17:14] <_mup_> merge resolved-spec [r=niemeyer][f=767964]
[17:14] <_mup_> ensemble resolved subcommand user documentation specification. 
[17:14] <SpamapS> hazmat: one interesting idea is to have the bootstrap node mirror the PPA at bootstrap time
[17:14] <SpamapS> hazmat: that would provide stasis for the environment.. just tell all nodes to pull from it.
[17:14] <SpamapS> hazmat: but that would also mean it becomes a SPOF
[17:15] <SpamapS> hmmm I like this idea tho
[17:15] <SpamapS> ensemble bootstrap --mirror=ppa:ensemble/ppa
[17:16] <SpamapS> hazmat: technically you could also have the bootstrap machine *create* an ami for the environment from that information alone
[17:19] <hazmat> SpamapS, if we can record the revno of the bootstrap node, we can use that to freeze subsequent deploys from an lp branch
[17:20] <hazmat> against a ppa its not as clear, do ppas always keep historical debs..
[17:20] <hazmat> time for some lunch errands
[17:23] <_mup_> ensemble/expose-ensemble-commands r217 committed by jim.baker@canonical.com
[17:23] <_mup_> PEP8
[17:24] <_mup_> ensemble/expose-ensemble-commands r218 committed by jim.baker@canonical.com
[17:24] <_mup_> Merged trunk
[17:37] <_mup_> ensemble/trunk r213 committed by jim.baker@canonical.com
[17:37] <_mup_> merged expose-ensemble-commands [r=niemeyer][f=767407]
[17:37] <_mup_> Implements "ensemble expose" and "ensemble unexpose" subcommands,
[17:37] <_mup_> which set and remove a flag znode, **/services/<internal service
[17:37] <_mup_> id>/exposed**, respectively.
[17:38] <_mup_> ensemble/expose-provisioning r213 committed by jim.baker@canonical.com
[17:38] <_mup_> Merged trunk
[18:53] <hazmat> i'm starting to feel like we should have a more general way of encapsulating these state requests, (debug/expose/resolved/logging/etc).
[18:53] <hazmat> we're adding lots of LOC reimplementing the same pattern over and over
[18:53] <hazmat> niemeyer, ^
[18:54] <niemeyer> hazmat: Which state requests, more specifically?
[18:54] <niemeyer> hazmat: Getting, saving, watching?
[18:54] <hazmat> niemeyer, debug/expose/resolved/logging are all marking states from the cli to denote a user request, that is completed by agent, get/set/clear/watch are common to all of them
[18:55] <niemeyer> hazmat: Indeed
[18:55] <niemeyer> hazmat: Good part of it is already abstracted away, though
[18:56] <niemeyer> hazmat: yield self._client.create(self._exposed_path)
[18:56] <hazmat> well ideally yaml_state.flush()
[18:56] <niemeyer> hazmat: Agreed, anyway.  I'm just saying that we're already on the way to abstracting them away
[18:56] <niemeyer> hazmat: Exactly.. the above is simpler still for this case, though
[18:57] <niemeyer> hazmat: Watching could get some love next
[18:57] <hazmat> niemeyer, maybe.. the duplication still feels like its missing an encapsulation pattern
[18:57] <niemeyer> hazmat: YAMLState was already awesome in that regard
[18:57] <hazmat> true
[18:57] <niemeyer> hazmat: Hmmm.. YAMLState.watch? :-)
[18:58]  * niemeyer teases hazmat
[18:59] <hazmat> niemeyer, perhaps.. i'm thinking of some sort of pattern where we could do   _debug_api = DebugRequest() \n set_debug = _debug_api.set(callback)  .. at the class level with watches etc.
[18:59] <hazmat> what a good pattern here isn't entirely clear.
[18:59] <jimbaker> niemeyer, indeed, i need something like a watch for the yaml state corresponding to opened ports
[18:59] <niemeyer> hazmat: I was pondering a bit over jimbaker's branch too
[18:59] <hazmat> we need watch callback separation and possibly set pre flush callbacks for validation
[18:59] <niemeyer> hazmat: The detail is that there's still some custom logic here and there
[19:00] <hazmat> niemeyer, yeah.. the resulting encapsulation would need to factor that out
[19:00] <niemeyer> hazmat: Like, "Oh, that's fine to ignore on conflicts..  ah, that's what the watch should return.." etc
[19:00] <niemeyer> hazmat: Right, and that's another abstraction layer
[19:00] <jimbaker> i see that kim0|vacation is presumably on vacation
[19:00] <hazmat> either as subclass behavior to a  generic yaml state request api or via pre invoke, and callbakcs
[19:00] <hazmat> jimbaker, yeah.. for this week
[19:00] <niemeyer> hazmat: There's nothing that another abstraction layer can't solve.. except the excess of abstraction layers..  so that saying goes. :-)
[19:01] <hazmat> niemeyer, which is solved by another layer ;-)
[19:01] <niemeyer> jimbaker: Hmmm, that's a clever assumption.. ;-D
[19:02] <hazmat> slightly offtopic... USG data center consolidation, move 2 clouds  http://online.wsj.com/article/SB10001424052748704729304576287431386089352.html?mod=WSJ_newsreel_politics 
[19:19] <SpamapS> hazmat: notice that there is no race between upstart's inotify and starting the job. start automatically looks for the config file before trying to start the job.
[19:20] <hazmat> SpamapS, nice, that's good to know, thanks
[19:42] <niemeyer> http://blog.rightscale.com/2011/04/25/amazon-ec2-outage-summary-and-lessons-learned/
[19:56] <hazmat> hmm..
[19:56] <hazmat> looks like natty will need a ppa kernel for lxc-attach
[20:44] <_mup_> ensemble/resolved-state-api r197 committed by kapil.thangavelu@canonical.com
[20:44] <_mup_> use properties for computed resolved paths
[23:37] <_mup_> ensemble/expose-provisioning r214 committed by jim.baker@canonical.com
[23:37] <_mup_> Setup watches incrementally from a service being exposed to ports being opened