[09:04] <kim0> Morning everyone
[12:51] <niemeyer> Buenos dias!
[13:07] <kim0> Buenos dias amigos :)
[13:39] <niemeyer> kim0: Que tal? :-)
[13:40] <kim0> :)
[13:48] <ahasenack> were you guys thinking about doing some presentation at Brazil's FISL?
[14:34] <niemeyer> ahasenack: It's a good question
[14:34] <niemeyer> ahasenack: It'd be quite handy
[14:34] <niemeyer> ahasenack: It seems to overlap with the platform sprint, though :(
[17:03] <jimbaker`> kim0, niemeyer - morning!
[17:03] <kim0> jimbaker`: o/ hey
[17:03] <jimbaker`> my talk at amazon went well
[17:03] <jimbaker`> i actually had a chance to explain ensemble to guido van rossum
[17:04] <kim0> jimbaker`: woohoo! sounds cool
[17:04] <jimbaker`> fwiw, he immediately made the connection to apparently a similar internal orchestration system used at google
[17:05] <kim0> jimbaker`: I suppose he didn't really reveal any interesting info about that system
[17:06] <jimbaker`> kim0, i'm afraid not ;)
[17:06] <kim0> yeah hehe
[17:07] <koolhead17> hi all
[17:07] <koolhead17> kim0: am yet to get the approval from eucalyptus website
[17:07] <koolhead17> jimbaker`: waoo
[17:07] <koolhead17> niemeyer: hi
[17:07] <kim0> koolhead17: #ubuntu-cloud and bug obino (he's from eucalyptus systems) :)
[17:08] <koolhead17> kim0: am there :P
[17:09] <kim0> :) I notice
[17:09] <koolhead17> haha
[17:32] <_mup_> ensemble/expose-service-watch r228 committed by jim.baker@canonical.com
[17:32] <_mup_> Merged trunk
[17:34] <niemeyer> jimbaker`: Morning
[17:34] <jimbaker`> niemeyer, morning
[17:35] <niemeyer> koolhead17: Hey
[17:37] <niemeyer> jimbaker`: So, expose now?
[17:37] <jimbaker`> niemeyer, indeed
[17:40] <niemeyer> jimbaker`: Ok, so as we discussed before UDS, the plan is to split it up in reasonable sized branches?
[17:40] <jimbaker`> niemeyer, exactly
[17:41] <niemeyer> jimbaker`: Ok.. can you please file bugs for the actual in progress branches as you go, and ensure https://ensemble.ubuntu.com/kanban/dublin.html reflects real activity?
[17:41] <jimbaker`> so i have branches for the machine's service units, watching a service, managing the open ports node
[17:41] <jimbaker`> for example
[17:42] <jimbaker`> niemeyer, i will update that accordingly
[17:42] <niemeyer> jimbaker`: Thanks
[17:44] <niemeyer> rog: Welcome
[17:44] <rog> niemeyer: hi! thanks.
[17:47] <niemeyer> On my end I'm pushing the lpad Launchpad library for Go still.. good progress there
[17:48] <rog> is there a link somewhere?
[17:49] <niemeyer> rog: Yeah.. it's not the latest stuff, but there's some good info here already:
[17:49] <niemeyer> http://goneat.org/lp/lpad
[17:50] <niemeyer> rog: This is almost complete in terms of the patterns we have to cover
[17:50] <niemeyer> rog: But the API is quite extensive, so there's some good work to get it all in place
[17:50] <niemeyer> rog: I'm actually planning to send golang-nuts a mail once I finish the details I'm working on right now
[17:50] <niemeyer> Asking for help
[17:51] <niemeyer> rog: a hand there would be welcome
[17:51] <rog> how's launchpad used within the context of ensemble?
[17:51] <niemeyer> rog: We'll back formulas there
[17:51] <niemeyer> rog: Source branches with the formula content
[17:51] <rog> seems sensible
[17:52] <niemeyer> rog: and will interact with Launchpad from the formula repository (Go)
[17:52] <rog> (unless it becomes a bottleneck, of course)
[17:52] <niemeyer> rog: That's not an issue.. is a concern for a long time
[17:52] <niemeyer> rog: Erm
[17:52] <niemeyer> rog: That's not an issue.. scalability is a concern for a long time
[17:53] <niemeyer> rog: The design of that API is two-layered
[17:53]  * rog loves the Go style of documentation
[17:53] <niemeyer> rog: There's a dynamic API in the bottom, which can do anything with Launchpad
[17:54] <niemeyer> rog: But is not ideal in terms of typing and documentation
[17:54] <niemeyer> rog: then, there's a static "model" layer which actually knows about which objects support which operations etc
[17:54] <niemeyer> rog: Which is more convenient to use
[17:54] <niemeyer> rog: IRCNick there is an example
[17:54] <niemeyer> rog: The Resource interface is the dynamic part
[17:55] <rog> i'd just realised that
[17:55] <rog> (not quite at the bottom on the doc page :-])
[17:55] <niemeyer> rog: As you can see, every model object is actually just a wrapper to Resource, which knows specifics about the given type
[17:56] <rog> i wasn't joking about liking go docs. it's just great to have it all in one place with links to the source.
[17:56] <niemeyer> rog: I'm now implementing an example of iteration over a list and custom operations in the model
[17:56] <niemeyer> rog: True!
[17:56] <niemeyer> rog: Once I finish this, I think we have all patterns covered, and just need to extend it to cover the whole API
[17:57] <rog> no inheritance! i've been dealing with some mac os objective C docs recently and the documentation is all over the place.
[17:57] <niemeyer> rog: Indeed!
[17:57] <rog> you don't describe what you mean by a "model"
[17:57] <niemeyer> rog: It's also cool because a Person wraps a Resource, and is *also* a Resource itself
[17:58] <niemeyer> rog: The model is the static layer
[17:58] <niemeyer> rog: Resource is the dynamic one
[17:58] <niemeyer> rog: So, e.g. IRCNick is part of the model
[17:59] <niemeyer> rog: I realize it's just specialization of generic terminology, but I guess it fits reasonably well in this case
[17:59] <rog> i'm not quite sure what you mean by the name "model" in this context
[17:59] <niemeyer> rog: IRCNick is part of the Launchpad object model
[17:59] <niemeyer> rog: Resource is lower level generic REST
[18:00] <rog> ah, so they're kinda of objects
[18:00] <niemeyer> rog: Yeah.. or types if you're into Go ;-)
[18:00] <rog> yeah
[18:00] <niemeyer> rog: This has the full Launchpad API docs:
[18:00] <niemeyer> https://launchpad.net/+apidoc/1.0.html
[18:01] <niemeyer> rog: This is the IRCNick backing, for the sake of understanding:
[18:01] <niemeyer> https://launchpad.net/+apidoc/1.0.html#irc_id
[18:02]  * rog didn't know about http PATCH methods
[18:03] <rog> i think maybe Entity might be a better name than Model
[18:03] <rog> Model implies it's modelling something - i found it a bit confusing
[18:04] <niemeyer> rog: The model is composed of entities
[18:04] <rog> but maybe i'm just not into the REST thing enough :-)
[18:05] <niemeyer> rog: I'm not sure it's related to REST.. the name just sounded generic enough and not too far off, so criticism accepted.
[18:05] <rog> niemeyer: so there's more than one entity represented by a Resource?
[18:06] <niemeyer> rog: Every type in the model is actually a Resource..
[18:07] <niemeyer> rog: More simply, you can think of a Resource as a JSON blob which is seen in a given URL
[18:07] <rog> that's what i thought
[18:07] <niemeyer> rog: But specific URLs will return the same "kind" of JSON blob
[18:07] <rog> yeah
[18:07] <niemeyer> rog: This may be helpful as well:
[18:07] <niemeyer> https://help.launchpad.net/API/Hacking
[18:08] <rog> Resource is fine, i think, but i think you could probably get rid of all instances of the term "model"
[18:08] <rog> i don't think it helps
[18:09] <niemeyer> rog: I'm fine with that
[18:09] <niemeyer> rog: But we'll need something else to put in its place :)
[18:09] <rog> e.g. // NewResource creates a new resource type.  Creating resources explicitly
[18:09] <rog> / is generally not necessary.  If you're trying to access a location in
[18:09] <rog> / the Launchpad API which doesn't have a dedicated type yet,
[18:09] <rog> / Link and Location methods on the Resource interface for more convenient
[18:09] <rog> / ways to create resources.
[18:10] <rog> i think "dedicated type" may be better than "static model"
[18:10] <rog> i like the idea anyway
[18:12] <rog> that's strange, why is the doc for Root.Me not next to the Root type
[18:12] <rog> ?
[18:13] <niemeyer> rog: Hmm.. it is?
[18:14] <niemeyer> rog: Regarding the term, I don't expect we'll be talking to people about that either way.. it's more about the internal organization than about how we'll expose it
[18:15] <niemeyer> rog, jimbaker, robbiew: I need to run an errand.. will be back to finish that stuff in ~1h
[18:16] <robbiew> ack
[18:16] <niemeyer> biab
[18:19] <rog> niemeyer: i was just talking from the point of view of understanding that package on its own. i think the API is pretty good - just that bit confused me.
[18:26] <_mup_> ensemble/expose-open-ports-node r227 committed by jim.baker@canonical.com
[18:26] <_mup_> Initial commit
[18:27] <_mup_> ensemble/expose-open-ports-node r228 committed by jim.baker@canonical.com
[18:27] <_mup_> Merged trunk
[18:41] <koolhead17> i have eucalyptus account now. kim0 next step please sir!! :)
[18:44] <kim0> koolhead17: hey .. that's cool
[18:44] <kim0> koolhead17: I guess the next step would be to make sure you can launch instances using euca-xxx tools
[18:45] <kim0> koolhead17: once that's ok, we'll try to use ensemble to launch those instances
[18:45] <kim0> for that, we'll need some help from devs here
[18:45] <koolhead17> okey.
[18:49]  * koolhead17 goes back to read eucalyptus beginners guide!!
[18:57] <_mup_> Bug #785343 was filed: Expose needs support for watching services and service units <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/785343 >
[19:00] <_mup_> Bug #785344 was filed: Expose needs to be able to retrieve service units for a machine <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/785344 >
[19:14] <_mup_> Bug #785352 was filed: Expose needs support for managing a service unit's open ports <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/785352 >
[19:25] <_mup_> ensemble/expose-open-ports-node r229 committed by jim.baker@canonical.com
[19:25] <_mup_> Doc strings
[19:25] <_mup_> ensemble/expose-open-ports-node r230 committed by jim.baker@canonical.com
[19:25] <_mup_> PEP8
[19:30] <_mup_> ensemble/expose-open-ports-node r231 committed by jim.baker@canonical.com
[19:30] <_mup_> Missing doc string
[19:43] <_mup_> ensemble/expose-service-watch r229 committed by jim.baker@canonical.com
[19:43] <_mup_> Removed sleeps
[19:57] <_mup_> ensemble/expose-machine-service-units r228 committed by jim.baker@canonical.com
[19:57] <_mup_> Tests
[19:58] <_mup_> ensemble/expose-machine-service-units r229 committed by jim.baker@canonical.com
[19:58] <_mup_> PEP8
[19:58] <_mup_> ensemble/expose-machine-service-units r230 committed by jim.baker@canonical.com
[19:58] <_mup_> Merged trunk
[20:09] <_mup_> ensemble/expose-machine-service-units r231 committed by jim.baker@canonical.com
[20:09] <_mup_> Better comments
[20:13]  * niemeyer waves
[20:23] <jimbaker`> niemeyer, http://ensemble.ubuntu.com/kanban/dublin.html is not updating
[20:24] <niemeyer> jimbaker`: Let me look at that
[20:24] <jimbaker`> niemeyer, also, do you want to have a standup today?
[20:25] <niemeyer> jimbaker`: Hmm.. not sure.. probably not unless you'd like to talk about something about the expose/unexpose support
[20:25] <jimbaker`> niemeyer, no, i think everything is going well on that plan
[20:26] <jimbaker`> i just submitted 3 supporting branches for review per earlier discussion
[20:27] <jimbaker`> the only thing that took time was making sure i got the sleep removal aspects solid, so i carefully looked through those tests
[20:27] <niemeyer> jimbaker`: Sounds great.. I'll have a look through those as soon as I manage to finish the broken test I have
[20:27] <niemeyer> jimbaker`: Hmm
[20:27] <niemeyer> jimbaker`: Ok
[20:29] <niemeyer> Actually, let me sort out the kanban first
[20:32] <niemeyer> rog: Btw, I forgot to mention MVC.. that's why I think model is suitable for the concept: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[20:33] <rog> niemeyer: yeah, i know about MVC but i think it's too abstract to be useful as a description here
[20:33] <niemeyer> rog: It's exactly the same idea I think
[20:34] <rog> the thing is, i don't think there's a need to invoke the name - there's no type that represents it.
[20:34] <niemeyer> rog: Agreed
[20:35] <niemeyer> rog: It's just useful as a high-level description of package organization really
[20:36] <rog> i don't think you need it. when you say "static model" you could say "dedicated type" or something similar and it would be more comprehensible i think
[20:37] <rog> using "model" only makes sense if you've couched the whole thing in terms of MVC, which you haven't
[20:37] <rog> AFAICS you've got a general purpose type (Resource) and a number of special-purpose types which layer on it
[20:38] <niemeyer> rog: The domain model of an application/library/whatever is a well understood concept I think.. but either way, this is all pretty irrelevant in the big picture
[20:38] <rog> those don't even need to be static types BTW
[20:38] <rog> sure, i just found that it made the docs for that package a bit hard to understand ("what does that term mean here?")
[20:39] <niemeyer> rog: Sure, we can avoid using the term in the docs
[20:39] <rog> 'cos in essence it's pretty simple and nice - it'd be nice if that could shine though!
[20:50] <niemeyer> Hah, sweet, problem fixed
[20:50]  * niemeyer does some real interactions with Launchpad
[21:10] <niemeyer> Burn Launchpad CPU, burn..
[21:22] <niemeyer> "Had 5732 results, iterated over 5732.".. good
[22:39] <niemeyer> Alright!
[22:40] <niemeyer> Iteration works, new lpad pushed
[22:40] <niemeyer> rog: Check out FindMembers/FindPeople/FindTeams, if you're curious
[22:41] <niemeyer> That's the good news..
[22:41] <niemeyer> jimbaker`: The bad news is I won't get to your branches today
[22:44] <niemeyer> jimbaker`: But please keep pushing this stuff
[22:53] <jimbaker`> niemeyer, not a problem
[22:57] <niemeyer> robbiew: Very cool, +1!
[22:58] <robbiew> huh..what?
[23:16] <niemeyer_> Ok, I need a nap.. I'll see y'all later/tomorrow
[23:18] <jimbaker`> niemeyer_, take care!