[02:43] <niemeyer> Quite painless after the initial issue was sorted out
[12:43] <niemeyer> Man, Unity is *awesome*
[12:59] <TeTeT> niemeyer: yeah, it's gotten much better through the development cycle. I showed it yesterday and today to LVM
[13:00] <niemeyer> TeTeT: I'm impressed indeed
[13:00] <niemeyer> TeTeT: It's not just different.. it feels great to use
[13:01] <TeTeT> niemeyer: I like the files & folder and applications dialog, very nicely done
[13:01] <niemeyer> Yeah
[13:01] <TeTeT> the first versions that I saw just had a search box, not very user friendly
[13:55] <niemeyer> TeTeT: Yeah, at least for some values of "user" :-)
[13:56] <niemeyer> TeTeT: I personally love being able to search for apps rather than browsing through menus blindly to find them
[14:10] <niemeyer> Hmmm.. we have to talk about the whole "expose" plan
[14:10] <niemeyer> There are some real blockers for using a normal service
[14:10] <niemeyer> It's feeling like a long and painful path
[15:18] <niemeyer> hazmat, robbiew: Mornings!
[15:20] <robbiew> niemeyer: hey
[15:21] <robbiew> niemeyer: is this the 1st qbr where you don't have to defend ensemble?
[15:21] <robbiew> lol
[15:22] <niemeyer> robbiew: I'm not sure.. I may still be invited for a call or something. :-)
[15:22] <robbiew> heh
[15:23] <niemeyer> robbiew: How're things going there?
[15:23] <robbiew> not bad...on an 11.10 Server requirements call right now..with OEM Services
[15:27] <niemeyer> robbiew: Nice
[16:06] <jimbaker`> i also like natty. installed it on my laptop, definitely a better ui exp with unity
[16:07] <jimbaker`> also reported two crashed apps so far - like others i have had problems with compiz
[16:42] <_mup_> ensemble/expose-services r185 committed by jim.baker@canonical.com
[16:42] <_mup_> Use iptables for firewall config and make changes via a built-in service
[16:52] <_mup_> ensemble/expose-services r186 committed by jim.baker@canonical.com
[16:52] <_mup_> Clarified how ensemble expose adds a relation to the exposer built-in service
[16:56]  * hazmat restarts to natty
[16:57] <jimbaker`> hazmat, good luck :)
[16:57] <jimbaker`> the only thing i really needed to redo for natty was to reinstall distribute, pip, and virtualenvwrapper because of the upgrade to 2.7
[16:58] <jimbaker`> after that all of my virtualenvs simply ported over w/o a problem
[17:51] <jimbaker> is everyone else able to run the mysql/wordpress example on ec2 against trunk? 
[17:52] <jimbaker> it is failing for me in the db-relation-changed hooks
[17:52] <jimbaker> when i switch to using my new-hook-semantics-4-remove-env-var branch (including environments.yaml change, virtualenv), np
[17:55] <jimbaker> hazmat, ^^^
[17:57] <hazmat> jimbaker, i haven't done run them on ec2 in about a week,  i can take a look after the standup
[17:57] <jimbaker> hazmat, ok
[17:57] <hazmat> how do you change timezones with unity..
[17:58] <jimbaker> hazmat, fortunately it got my tz right :)
[17:58] <hazmat> jimbaker, wait to you switch timezones :-)
[17:58] <jimbaker> but there have been some changes around the clock for sure
[17:58] <jimbaker> just click on the clock, you will see time & date settings
[17:59] <hazmat> jimbaker, sure, but it doesn't actually come up
[17:59] <hazmat> run the settings dialog that is
[18:00] <jimbaker> hmm, no problem for me changing the settings
[18:21] <niemeyer> jimbaker, hazmat: Can we have a call at some point today to talk about expose?
[18:21] <niemeyer> There are some obvious problems with the idea of using a normal service, and I'm starting to feel like we're digging ourselves a hole
[18:22] <niemeyer> It'd be nice to go back to an empty table and look at our requirements again, and then think of some simpler/straightforward ways to achieve it
[18:24] <hazmat> niemeyer, sounds good
[18:29] <jimbaker> niemeyer, sounds good too
[18:29] <niemeyer> brb
[18:41] <_mup_> ensemble/optional-hooks r186 committed by kapil.thangavelu@canonical.com
[18:41] <_mup_> switch warning to info log level, use failure hooks instead of missing hooks for hook error tests
[18:45] <jimbaker> hazmat, are you planning that we add get_agent_state(), or is that just out-of-date in the docs?
[18:45] <hazmat> jimbaker, where's that referenced from?
[18:46] <jimbaker> hazmat, internals/agent-presence.rst
[18:46] <hazmat> jimbaker, there's is an agent state node, but its usage and the exposed api is limited to presence only
[18:46] <hazmat> and only for agents directly associated to a domain context atm (ie. machine and unit, but not provisioning)
[18:47] <hazmat> the spec does cover context-less agents though
[18:47] <jimbaker> i'm going through bug 737949 to determine what status info is available for agent state
[18:47] <_mup_> Bug #737949: ensemble status should take into account unit and relation workflows and unit agent status <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/737949 >
[18:49] <hazmat> jimbaker, wrong tree
[18:49] <hazmat> jimbaker, they are two different questions
[18:49] <hazmat> one is there an agent process running for this domain object
[18:49] <hazmat> which is answered by the api in ensemble/state/agent.py its a mixin of unit, machine, etc.
[18:50] <hazmat> the second question, which the bug wants to ask, is what is the workflow state of the unit and its relations
[18:50] <hazmat> which can use the workflow api directly
[18:50] <jimbaker> hazmat, thanks for the clarification
[18:53] <hazmat> jimbaker, the information for the workflow is probably better accessed via constructing a unit lifecycle/workflow object like the agent
[18:54] <hazmat> for read only usage the state directory isn't strictly nesc.
[18:54] <hazmat> hmm.. i think
[18:54] <jimbaker> hazmat, right, the only thing i see now that's doing something like that is in test_workflow
[18:54] <jimbaker> specifically read_persistent_state
[18:54] <hazmat> also agents/unit.py
[18:56] <hazmat> jimbaker, so it needs a separate implementation of unitworkflowstate, relationworkflow state that only loads zk state
[18:56] <hazmat> via modifying load, and probably disabling store
[18:56] <hazmat> as external modifications will likely need a different mechanism
[18:57] <jimbaker> so global observability is preserved and tested, but no api as you said
[18:57] <jimbaker> to actually read it
[18:58] <hazmat> jimbaker, well there is an api to read it as provided, it just needs an override of _load/_store methods to defer to the correct implementations for an external process usage.
[18:59] <hazmat> ie. an api that needs a subclass implementation to utilize it for this case
[19:00] <hazmat> bcsaller, jimbaker, niemeyer_ standup?
[19:00] <jimbaker> hazmat, sure, just need to connect it to zk
[19:00] <jimbaker> hazmat, sure
[19:00] <jimbaker> re standup
[19:00] <bcsaller> online
[19:01] <hazmat> niemeyer_, ping
[19:01] <niemeyer_> hazmat: Hmm.. I'll need some 10~15 minutes, actually, if that's ok
[19:01] <niemeyer_> ?
[19:02] <hazmat> fine by me
[19:02] <jimbaker> ok
[19:02] <niemeyer_> I'm relocating to Claudio's place just to provide some company.. he's got to stay at home due to an issue in his leg
[19:03] <niemeyer_> brb
[19:16] <jimbaker> bcsaller, hazmat, niemeyer - everyone ready?
[19:16] <niemeyer> Yep
[19:17] <hazmat> sounds good
[19:17] <hazmat> niemeyer, you on skype?
[19:18] <niemeyer> hazmat: Spinning...
[19:18] <niemeyer> hazmat: Working
[19:44] <niemeyer> unit-set expose="port[/protocol] [port[/protocol]]"
[19:46] <niemeyer> export-port port[/protocol]
[19:59] <niemeyer> open/close-port port[/protocol] + exposed hook
[20:09] <niemeyer> jimbaker: /units/<internal id>/ports
[20:17] <hazmat> out of curiosity has anyone on natty gotten the bzr-pipeline plugin working?
[20:17] <hazmat> i guess i can try modifying the api compatibility by hand and hope it works
[20:19] <_mup_> ensemble/statemachine-multi-source-and-success-transitions r181 committed by kapil.thangavelu@canonical.com
[20:19] <_mup_> explicit action support and success transition support
[21:04] <jimbaker> SpamapS, btw, i really liked the discovery process you mentioned in your email for finding interesting services for ensemble
[21:21] <SpamapS> jimbaker: yeah, there's tons of helpful info already in the archive. :)
[21:44] <hazmat> niemeyer, jimbaker so one other benefit to the machine as service was that it made the notion of monitoring much easier as well
[21:45] <hazmat> which is a topic i think we've sort of left off for perhaps too long
[21:45] <hazmat> there's service specific monitoring, and then generic machine/container level monitoring
[21:45] <hazmat> the former we can do via relation hooks between the monitoring service and the other service.. the latter still seems like an open question to me
[22:02] <niemeyer> hazmat: Monitoring things which depend on a connection to ZooKeeper to function is somewhat easy
[22:02] <hazmat> niemeyer, not the sort of monitoring i was referencing.. more along the lines of munin/nagios 
[22:02] <hazmat> ie. hd full/memory/cpu/network
[22:03] <niemeyer> hazmat: I see.. we haven't really delayed I think.. this is just another service
[22:04] <hazmat> niemeyer, i'm not so that it doesn't need additional support of some form for the machine level stats
[22:05] <niemeyer> hazmat: How so?
[22:05] <niemeyer> jimbaker: The review queue is all yours ;)
[22:05] <niemeyer> jimbaker: I'll go over that first thing tomorrow
[22:05] <hazmat> niemeyer, well are we saying we need a unit of the this per service.. in the lxc case that's not quite right.
[22:06] <niemeyer> hazmat: Why not?
[22:06] <hazmat> ie. we ensemble deploy munin for example.. we need to install munin-node on each of the machines in the environment
[22:07] <hazmat> and configure them to point to the munin service
[22:09] <hazmat> ie. so say we split into two formulas munin-frontend, munin-node.. when we deploy the latter we don't really want it as a separate unit per se, we want it either in the existing unit (which can be tackled by formula specific monitoring support) or at the machine level
[22:09] <hazmat> what we don't want is creating a unit of the munin-node on arbitrary placement basis, as it will effectively be monitoring an empty container with just itself
[22:09] <_mup_> ensemble/config-pipeline r182 committed by bcsaller@gmail.com
[22:09] <_mup_> minor revisions around type validation
[22:13] <niemeyer> hazmat: I see, indeed there are some details to sort in this area