[02:43] Quite painless after the initial issue was sorted out [12:43] Man, Unity is *awesome* [12:59] niemeyer: yeah, it's gotten much better through the development cycle. I showed it yesterday and today to LVM [13:00] TeTeT: I'm impressed indeed [13:00] TeTeT: It's not just different.. it feels great to use [13:01] niemeyer: I like the files & folder and applications dialog, very nicely done [13:01] Yeah [13:01] the first versions that I saw just had a search box, not very user friendly [13:55] TeTeT: Yeah, at least for some values of "user" :-) [13:56] TeTeT: I personally love being able to search for apps rather than browsing through menus blindly to find them [14:10] Hmmm.. we have to talk about the whole "expose" plan [14:10] There are some real blockers for using a normal service [14:10] It's feeling like a long and painful path [15:18] hazmat, robbiew: Mornings! [15:20] niemeyer: hey [15:21] niemeyer: is this the 1st qbr where you don't have to defend ensemble? [15:21] lol [15:22] robbiew: I'm not sure.. I may still be invited for a call or something. :-) [15:22] heh [15:23] robbiew: How're things going there? [15:23] not bad...on an 11.10 Server requirements call right now..with OEM Services [15:27] robbiew: Nice [16:06] i also like natty. installed it on my laptop, definitely a better ui exp with unity [16:07] also reported two crashed apps so far - like others i have had problems with compiz === niemeyer is now known as niemeyer_lunch [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] hazmat, good luck :) [16:57] 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] after that all of my virtualenvs simply ported over w/o a problem === deryck is now known as deryck[lunch] === niemeyer_lunch is now known as niemeyer [17:51] is everyone else able to run the mysql/wordpress example on ec2 against trunk? [17:52] it is failing for me in the db-relation-changed hooks [17:52] when i switch to using my new-hook-semantics-4-remove-env-var branch (including environments.yaml change, virtualenv), np [17:55] hazmat, ^^^ [17:57] jimbaker, i haven't done run them on ec2 in about a week, i can take a look after the standup [17:57] hazmat, ok [17:57] how do you change timezones with unity.. [17:58] hazmat, fortunately it got my tz right :) [17:58] jimbaker, wait to you switch timezones :-) [17:58] but there have been some changes around the clock for sure [17:58] just click on the clock, you will see time & date settings [17:59] jimbaker, sure, but it doesn't actually come up [17:59] run the settings dialog that is [18:00] hmm, no problem for me changing the settings === deryck[lunch] is now known as deryck [18:21] jimbaker, hazmat: Can we have a call at some point today to talk about expose? [18:21] 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] 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] niemeyer, sounds good [18:29] niemeyer, sounds good too [18:29] 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] hazmat, are you planning that we add get_agent_state(), or is that just out-of-date in the docs? [18:45] jimbaker, where's that referenced from? [18:46] hazmat, internals/agent-presence.rst [18:46] jimbaker, there's is an agent state node, but its usage and the exposed api is limited to presence only [18:46] and only for agents directly associated to a domain context atm (ie. machine and unit, but not provisioning) [18:47] the spec does cover context-less agents though [18:47] 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 < https://launchpad.net/bugs/737949 > [18:49] jimbaker, wrong tree [18:49] jimbaker, they are two different questions [18:49] one is there an agent process running for this domain object [18:49] which is answered by the api in ensemble/state/agent.py its a mixin of unit, machine, etc. [18:50] the second question, which the bug wants to ask, is what is the workflow state of the unit and its relations [18:50] which can use the workflow api directly [18:50] hazmat, thanks for the clarification [18:53] jimbaker, the information for the workflow is probably better accessed via constructing a unit lifecycle/workflow object like the agent [18:54] for read only usage the state directory isn't strictly nesc. [18:54] hmm.. i think [18:54] hazmat, right, the only thing i see now that's doing something like that is in test_workflow [18:54] specifically read_persistent_state [18:54] also agents/unit.py [18:56] jimbaker, so it needs a separate implementation of unitworkflowstate, relationworkflow state that only loads zk state [18:56] via modifying load, and probably disabling store [18:56] as external modifications will likely need a different mechanism [18:57] so global observability is preserved and tested, but no api as you said [18:57] to actually read it [18:58] 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] ie. an api that needs a subclass implementation to utilize it for this case [19:00] bcsaller, jimbaker, niemeyer_ standup? [19:00] hazmat, sure, just need to connect it to zk [19:00] hazmat, sure [19:00] re standup [19:00] online [19:01] niemeyer_, ping [19:01] hazmat: Hmm.. I'll need some 10~15 minutes, actually, if that's ok [19:01] ? [19:02] fine by me [19:02] ok [19:02] 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] brb [19:16] bcsaller, hazmat, niemeyer - everyone ready? [19:16] Yep [19:17] sounds good [19:17] niemeyer, you on skype? [19:18] hazmat: Spinning... [19:18] hazmat: Working [19:44] unit-set expose="port[/protocol] [port[/protocol]]" [19:46] export-port port[/protocol] [19:59] open/close-port port[/protocol] + exposed hook [20:09] jimbaker: /units//ports [20:17] out of curiosity has anyone on natty gotten the bzr-pipeline plugin working? [20:17] 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] SpamapS, btw, i really liked the discovery process you mentioned in your email for finding interesting services for ensemble [21:21] jimbaker: yeah, there's tons of helpful info already in the archive. :) [21:44] 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] which is a topic i think we've sort of left off for perhaps too long [21:45] there's service specific monitoring, and then generic machine/container level monitoring [21:45] 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] hazmat: Monitoring things which depend on a connection to ZooKeeper to function is somewhat easy [22:02] niemeyer, not the sort of monitoring i was referencing.. more along the lines of munin/nagios [22:02] ie. hd full/memory/cpu/network [22:03] hazmat: I see.. we haven't really delayed I think.. this is just another service [22:04] niemeyer, i'm not so that it doesn't need additional support of some form for the machine level stats [22:05] hazmat: How so? [22:05] jimbaker: The review queue is all yours ;) [22:05] jimbaker: I'll go over that first thing tomorrow [22:05] 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] hazmat: Why not? [22:06] ie. we ensemble deploy munin for example.. we need to install munin-node on each of the machines in the environment [22:07] and configure them to point to the munin service [22:09] 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] 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] hazmat: I see, indeed there are some details to sort in this area