[12:53] <bac> hi frankban, you around today?
[12:53] <frankban> bac: yes
[12:56] <bac> cool.  might just be us.
[13:01] <frankban> bac: yeah. do you have any idea of how bundle annotations are supposed to work in a real env?
[13:01] <bac> frankban: i'm not sure what you're asking
[13:02] <bac> you talking about x,y annotations or something else?
[13:02] <frankban> bac: yeah sorry, x,y annotations
[13:03] <bac> frankban: the positioning seems to work.  gary fixed a bug on friday and i tested by deploying four really huge bundles and they were laid out correctly.
[13:03] <frankban> bac: in a real env?
[13:04] <bac> ah, sorry, no it was sandbox.
[13:04] <frankban> bac:  when you drag a bundle file and drop it in the gui canvas, the GUI seems to just pass the YAML contents to the server, and the server uses the deployer to start the import process. Looking at the deployer code ISTM that annotations are just ignored
[13:04] <frankban> :-/
[13:04] <bac> oh, not good
[13:13] <rick_h_> ugh, that sucks
[13:13] <rick_h_> and explains a lot
[13:18] <bac> rick_h_, frankban: have you seen the annotations ignored in a real env in practice?  i haven't done an actual bundle deploy against ec2 or other real envs.
[13:18] <bac> rick_h_: are you working today?
[13:18] <rick_h_> bac: yea, I did QA on release day in a real env and never got positioning to work
[13:18] <bac> darn
[13:19] <rick_h_> bac: no, just peeking in. I'm staying away today as I got sucked in on friday
[13:19] <bac> rick_h_: then go away!  didn't you read robbie's email?  :)
[13:19] <bac> rick_h_: i'm about to do the mjc deploy
[13:19] <rick_h_> bac: hah, yes I did. I think I did that on a sunday :P
[13:19] <rick_h_> bac: awesome!
[13:20] <rick_h_> bac: as a follow up, should we move comingsoon back to mjc at that point (and the new bundles ingest) or leave it at staging do you think?
[13:20] <rick_h_> I guess since it was moved to staging for the demo it should stay put until those are done from maaten and jcastro 
[13:20] <bac> yeah, i'd wait until an all clear.
[13:21]  * rick_h_ gets twitchy with comingsoon pointing at staging. Too many times of canonistack blowing things up on us
[13:21] <rick_h_> ok, running away. Thanks for the production update bac. /me will be so happy when all the moving parts setting back down a bit. 
[13:23]  * bac stuck waiting for fusion to download update
[14:14] <bac> adeuring: the new heartbeat information looks good!
[14:15] <bac> i may augment it to show when the bzr branch was updated.
[14:27] <bac> hi abentley, jenkins for charmworld is not seeing a recently landed change.  if i select 'build now' it asks for manual input of several items, which i'm uncomfortable setting, assuming it would just trigger the next one.  the trigger log shows that it has run after the landing of r456 but is not seeing changes.
[14:28] <abentley> bac: Looking, but standup about to start.
[14:28] <bac> ok
[14:29] <abentley> bac: What do you mean, not seeing changes?
[14:30] <adeuring> bac: thanks :)
[14:30] <bac> abentley: i mean the ScriptTrigger log ends with "Polling complete. Took 4 sec.
[14:30] <bac> No changes." and no build is triggered
[14:31] <bac> abentley: last build was 455 but 456 is available.
[14:31] <abentley> bac: The last thing it landed was 456: http://162.213.35.27:8080/job/charmworld-autoland-lxc/78/console
[14:32] <bac> abentley: i was looking at http://162.213.35.27:8080/job/charmworld-autoland-lxc/78/ for build #78 which says 455
[14:40] <luca___> Can anyone tell me what cloud credentials look like? I've asked rick_h_ but he's ignoring me!
[14:45] <abentley> bac: It says "The new revision is 456" and "juju set charmworld revno=456", so that means it committed r456 and instructed charmworld to deploy 456.
[14:45] <abentley> bac: That's at the bottom of the log.
[14:46] <bac> abentley: yes, i see that in the console log.  i do find it confusing that the main page i pasted above indicates it is processing r455.  i know you're not a jenkins apologist i'm just explaining the reason for my confusion.  thanks for clearing it up.
[14:49] <abentley> bac: That refers to the initial state of trunk, before it commits.
[14:52] <bac> ty abentley
[14:58] <abentley> bac: Jenkins is behaving as if we are doing test-after-commit, so it is saying "Oh, this is the new revision since my last test, and here are the changes".  It is somewhat my fault because of the way I set the build up.
[15:00] <abentley> bac: We could change it so that the pull is done as part of the script, rather than using the Jenkins Bazaar plugin.  I believe that would remove the "changes" info from that page, which would be less misleading.
[16:07] <frankban> bac: have you received my email to juju-gui-peeps? (testing if my smtp configuration work)
[16:08]  * bac looks
[16:09] <bac> frankban: i received Re: [Juju-gui-peeps] Visual placement of services in bundle deployment on real environment
[16:12] <frankban> bac: ok, with my listing of two bugs, right?
[16:12] <bac> yes
[17:03] <frankban> hazmat: ping
[17:03] <hazmat> frankban, pong
[17:03] <frankban> hazmat: the deployer does not support annotations, correct?
[17:03] <hazmat> frankban, not yet, this is just for gui positions?
[17:04] <frankban> hazmat: yes
[17:04] <hazmat> frankban, k, i can add some support in today
[17:05] <frankban> hazmat: that would be great! it is critical for us now that we support bundles
[17:08] <frankban> hazmat: in the next days I will work on a deployer branch (fixes for our import calls from the guiserver) and on a jujuclient branch (make EnvError pickable + optional ToMachineSpec support in deploy()). How does it sound?
[17:08] <hazmat> frankban, also fwiw re placement in bundles. http://pythonhosted.org/juju-deployer/config.html#placement
[17:08] <frankban> hazmat: cool
[17:09] <hazmat> frankban, afaik that covers the tomachinespec support for deploy
[17:09] <hazmat> there's a new release of jujuclient coming as well to catch up with core's recent api work
[17:10] <hazmat> frankban, re enverror pickable.. you mean json serialization support?
[17:10] <hazmat> frankban, there's a longer discussion  with rick_h_ about changing deployer to be more library based instead of cli (ie no more ErrorExit exceptions).
[17:10] <hazmat> fwiw
[17:12] <frankban> hazmat: re jujuclient I mean this diff -> http://pastebin.ubuntu.com/6377430/
[17:14] <hazmat> frankban, gotcha, okay
[17:15] <frankban> hazmat: long story short, the guiserver calls the deployer in a separate process, any exception should be propagated using futures, but to do that, the ProcessPoolExecutor pickles exceptions. That python bug prevents the exception to be correctly deserialized, an the diff is a quick workaround. do you want me to propose that, do you want to just include the fix in your next release?
[17:15] <hazmat> frankban, i'll just include it
[17:16] <frankban> hazmat: the branch is in https://code.launchpad.net/~frankban/python-jujuclient/pickable-enverror
[17:16] <frankban> hazmat: great thanks
[17:18] <frankban> hazmat: ok so I'll work tomorrow just on the deployer fixes for the guiserver, ok?
[17:18] <hazmat> frankban, sounds good
[17:20] <hazmat> frankban, 0.15 jujuclient uploaded has the exc fix and deploy() machine_spec support
[17:20] <hazmat> to pypi that is 
[17:21] <frankban> hazmat: awesome! :-)
[17:26] <frankban> hazmat: so, thanks a lot. so tomorrow I'll grab the deployer with annotations support if it is ready and work on the guiserver code there.
[17:26] <hazmat> frankban, sounds good
[17:26] <hazmat> frankban, does gui charm get deployer from pypi or cloud archive
[17:27] <frankban> hazmat: the gui charm includes the deployer tarball.
[17:28] <hazmat> frankban, ic, thanks
[18:20] <frankban> bac: when you have a minute later, could you please review and qa https://codereview.appspot.com/24600043 ? 
[18:20] <bac> frankban: sure
[18:20] <frankban> bac: thanks, have a nice evening
[18:20] <bac> you too
[18:46] <hatch> rick_h_,  hey I don't suppose you're kickin around?
[18:46] <rick_h_> hatch: around, what's up?
[18:47] <hatch> just working on huw's branch now and implementing your changes
[18:47] <hatch> but I'm wondering why onboarding is handled by the browser.js and not app.js?
[18:47] <rick_h_> hatch: couple reasons. One, it's only in the build viewstate, it's part of the browser experience in that way
[18:48] <rick_h_> hatch: and getting that viewstate info up out to the app was a pita and bad code smell
[18:49] <hatch> oh, I was under the impression that it was done over top of whatever would be there
[18:49] <rick_h_> hatch: no, it's only in build mode
[18:49] <hatch> but I guess it makes sense
[18:49] <rick_h_> hatch: so originally there was all this url hacky crap to check if it should show when it was in app.js
[18:49] <rick_h_> hatch: which got convoluted when you considered default view mode and such
[18:49] <hatch> cool, so that is another thing that can be simplified post fullscreen removal :)
[18:49] <rick_h_> hatch: so it was a MUCH simpler thing to move to browser.js and check viewmode directly
[18:49] <hatch> right
[18:49] <hatch> I knew there had to be a reason for it :)
[18:50] <rick_h_> hatch: what doesn't get simpler (once you get past removing everything and fixing all the state machinery bits)
[18:52] <rick_h_> hatch: that and I HATE app.js doing more work. It's a lot easier to test as it is now. 
[18:53] <hatch> :)
[18:57] <hatch> only 4 more hours to go, should be able to get this done before then :)