=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
[14:26] <hatch> kadams out today?
[14:28] <rick_h_> hatch: not on the calendar
[14:29] <hatch> hmm ok then 
[14:32] <frankban> uiteam: https://jujugui.wordpress.com/2014/11/13/juju-quickstart-1-5-0/
[14:32] <frankban> hazmat: ^^^ this also includes the existing environment handling changes you suggested 
[14:36] <hatch> frankban: any idea where tornado.options is defined? I'm not having any luck tracking it down - it appears to be the proper place to put the new ports to open for the guiserver
[14:36] <frankban> hatch: looking
[14:37] <frankban> hatch: so basically the charm configures the guiserver (tornado) upstart script. the guiserver options parser is in server/guiserver/manage.py:setup
[14:38] <hatch> frankban: oh so options are just flags?
[14:38] <hatch>     {{if insecure}}
[14:38] <hatch>         --insecure
[14:38] <hatch>     {{endif}}
[14:38] <frankban> hatch: no, options can be also parameters
[14:38] <hatch> --charmworldurl="{{charmworld_url}}"
[14:39] <hatch> but all done via the template correct?
[14:39] <frankban> exactly
[14:39] <hatch> ok got it thanks
[14:40] <frankban> hatch: that's the upstart configuration file, which is used to start and daemonize the guiserver. the you'll need to add those parameters to the guiserver too, and the parameters are defined in the module I mentioned above
[14:40] <frankban> hatch: add the parameters so that they are accepted by the guiserver
[14:40] <hatch> yeah I had gotten that far, it just didn't click how `options` was getting populated :)
[14:41] <hatch> now that's the missing piece
[14:42] <frankban> hatch: options is a global name in tornado, the parse_command_line() call automatically populates the options with the values from the command line
[14:42] <hatch> ahh I see
[14:43] <hatch> so my only problem with python so far is that there is no indication of the import location of the files you're importing simply from the name :)
[14:43] <hatch> maybe there is a trick to tracking them down besides grep?
[14:43] <rick_h_> hatch: so imports are grouped, stdlib first
[14:43] <rick_h_> then 'installed packages'
[14:43] <rick_h_> then 'local packages' (things you wrote usually files closely
[14:44] <hatch> ok so for example from tornado.ioloop import IOLoop
[14:44] <hatch> I don't see a folder here named tornado
[14:44] <hatch> or a file
[14:44] <frankban> hatch: that's not stdlib, it's an external package installed by guiserver in order to run
[14:44] <hatch> right
[14:44] <hatch> so how am I to know where this file is?
[14:45] <hatch> is that only available in the penv?
[14:45] <frankban> hatch: in the charm, if you run "make" the development environment is created
[14:45] <hatch> ok so what I was looking for wasn't available in the code anyways
[14:46] <hatch> I would have just had to know to go look for the external tornado dep api website
[14:46] <frankban> hatch: and it is created as a Python virtualenv in tests/.venv
[14:46] <frankban> hatch: this means that all the dependencies are actually installed there
[14:47] <hatch> so how would I find the source for tornado.options?
[14:47] <frankban> hatch: specifically in tests/.venv/lib/python2.7/site-packages/
[14:47] <hatch> this is what I'm getting at, I was looking for where tornado.options was defined
[14:47] <hatch> but it's not in our source tree
[14:47] <hatch> because it's only installed into the venv
[14:47] <hatch> is this correct?
[14:48] <frankban> hatch: tests/.venv/lib/python2.7/site-packages/tornado/options.py
[14:48] <frankban> hatch: yes correct
[14:48] <hatch> is this a typical python workflow? To not have deps source in the source tree?
[14:49] <frankban> hatch: yes
[14:49] <hatch> ok and where is it defined to pull down the deps?
[14:49] <hatch> *.pip files I guess
[14:50] <frankban> hatch: usually when you apt-get or pip install a python package, this is put in the global repository for python libraries (e.g. /usr/lib/python2.7/dist-packages)
[14:51] <frankban> hatch: virtualenvs are used to avoid installing everything globally, and instead you recerate a local place where to pip install packages, including a local python interpreter
[14:52] <hatch> yeah it's just a little odd that I have to go to a website to find the source then go to that website to read it
[14:52] <frankban> hatch: the venv is created by tests/00-setup
[14:53] <frankban> hatch: you don't have to go to the website, the packages are there, just in another dir, not the same as the code
[14:53] <hatch> ok so maybe my issue is that i need to run a file in /tests 
[14:54] <hatch> intersting that there isn't this functionality in pip like in npm :)
[14:54] <frankban> hatch: a quick trick to find where the code lives: you can execute the python present in the virtualenv: % tests/.venv/bin/python
[14:54] <frankban> then:>>> import tornado
[14:54] <frankban> >>> tornado.__file__
[14:54] <frankban> '/home/frankban/devel/juju-charm/sandbox/tests/.venv/local/lib/python2.7/site-packages/tornado/__init__.pyc'
[14:54] <hatch> well right - but you need to know which file actually sets up the venv first
[14:54] <hatch> with node projects it's simple you know you just run `npm  install` 
[14:54] <frankban> >>> from tornado import options
[14:54] <frankban> >>> options.__file__
[14:54] <frankban> '/home/frankban/devel/juju-charm/sandbox/tests/.venv/local/lib/python2.7/site-packages/tornado/options.pyc'
[14:55] <hatch> here you have to really dig for something which sets up the venv 
[14:56] <hatch> oh now I see because pip install does it globally by default
[14:58] <hatch> frankban: do you remember why we went with tornado over apache?
[14:59] <frankban> hatch: tornado is asynchronous
[14:59] <hatch> I'm not sure I understand...
[14:59] <rick_h_> hatch: because we run stuff that catching api calls to do things like bundle deployments and such with added code
[14:59] <rick_h_> hatch: so apache was just another layer we didn't need
[15:00] <hatch> ahh ok ok
[15:00] <hatch> yeah that makes sense
[15:00] <hatch> I forgot about our bundle hacks
[15:00] <hatch> heh
[15:01] <hatch> there is a weird bug in the GUI when deploying bundles where sometimes they dont' render where you dropped htem
[15:01] <hatch> I can't seem to reproduce it reliably however
[15:02] <hatch> or reproduce it frequently for that matter
[15:02] <hatch> (unfortunately)
[15:03] <frankban> hatch: https://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/view/head:/README.md#L170
[15:11] <hatch> http://www.cbc.ca/news/canada/saskatchewan/ground-stations-built-by-sask-firm-play-big-role-in-historic-comet-visit-1.2828928  :)
[15:12] <hatch> rick_h_: jcsackett see even the Rosetta people know we exist :P
[15:13] <jcsackett> hatch: bah, it's a canadian news outlet. can't be trusted.
[15:13] <hatch> lol!! 
[15:32] <hatch> kadams54: hey did you end up finding what you needed? 
[15:32] <kadams54> hatch, rick_h_: I've hit a wall on my current added services card. Going to need some help figuring out how to proceed.
[15:32] <rick_h_> kadams54: rgr, on a call atm 
[15:32] <kadams54> Apparently I had not yet hit <Enter> on that message; got distracted by a phone call.
[15:33] <hatch> hah - sure what's up?
[15:33] <hatch> can't find where the units are being updated?
[15:35] <kadams54> The units seem to be deleted entirely.
[15:35] <kadams54> The ghosted ones that is.
[15:35] <kadams54> Then the new, non-ghosted unit comes in and is handled by process_delta
[15:35] <kadams54> Which means it has no hide/fade/highlight flags.
[15:36] <kadams54> And since the ghosted one has already been deleted, there's no option to copy the flags over to the new unit.
[15:36] <hatch> why not? Can't you query its service to get the visibility status?
[15:37] <hazmat> frankban, which were those.. the bundle stuff using the -S for import?  .. what's initial support for the manual provider..
[15:37] <hazmat> i use gui with manual all the time.
[15:38] <hazmat> frankban, oh.. the don't bootstrap everytime thing..
[15:38] <hazmat> k
[15:38] <rick_h_> hatch: bring up your manual machine, run quickstart -i and fill out the manual fields to add a env for manual, and then it'll bootstrap/install gui
[15:38] <hatch> ^ hazmat
[15:38] <hatch> :P
[15:38] <rick_h_> bah, hazmat ^
[15:39] <frankban> hazmat: yeah the bootstrap strategy change
[15:40] <frankban> hazmat: re manual provider, quickstart lets you bootstrap all the environments you have, but now the manual provider is actually recognized, validated, etc
[15:41] <hatch> kadams54: ahh I see now where it's removed
[15:42] <hatch> so when it comes in you should be able to query the services's visibility status
[15:42] <hatch> then apply that to the units
[15:42] <hatch> no?
[15:42] <rick_h_> frankban: landscape called out the quick fixes for quickstart in the cross team call yay
[15:42] <rick_h_> frankban: so mad props
[15:42] <kadams54> hatch: True, though this makes me a bit leery.
[15:42] <hatch> why?
[15:42] <frankban> cool
[15:44] <kadams54> hatch: code smell. We have units all over the place: in the DB, on the service, on the machine, and we have to make sure that the flags get replicated into all those locations. Now I find out that some other part of the code is deleting the units and re-creating them from juju-core data, meaning we have one more spot where flags need to be replicated onto a unit.
[15:45] <hatch> yep
[15:45] <hatch> that's definitely not being refactored by Friday
[15:45] <hatch> there is a card to fix the unit handling
[15:45] <hatch> but it's at least a week of work
[15:46] <kadams54> I wish service.get('units') and machine.get('units') weren't ModelLists embedded on those models, but rather facades to db.units.filterByService and db.units.filterByMachine
[15:47] <hatch> there are performance implications to that
[15:47] <hatch> but atm I'm just concerned about getting this feature out Monday morning
[15:50] <hatch> if this bug can be fixed by a simple cached query on the service then lets do'er then move on to the other bug
[15:57] <Makyo> uiteam call in 4 kanban now
[16:27] <hatch> kadams54: for the record, I too wish it was better :)
[16:36] <kadams54> uiteam: looking for reviews and QA on https://github.com/juju/juju-gui/pull/655
[16:38] <Makyo> on it
[16:38] <hatch> frankban: in an effort to speed up this process can you tell me where the output from logging.info calls go to?
[16:39] <frankban> hatch: /var/log/upstart/guiserver.log
[16:39] <hatch> thanks :)
[16:41] <frankban> hatch: sometimes, when I need to hack on the unit, I just stip the guiserver service and run the upstart command in the shell, without daemonizing. that way you can see the output directly, and even add pdb debugger calls to the code you want to inspect
[16:41] <frankban> stop the guiserver even
[16:41] <hatch> interesting - I'll have to give that a try sometime
[16:45] <hatch> kadams54: +1's
[16:49] <hatch> frankban: https://gist.github.com/hatched/3f6c74fa6d024ee0e12c
[16:49] <hatch> the error is a little cryptic
[16:49] <hatch> have you ever seen this before?
[16:49] <hatch> Sorry to bug you, I'm just trying to keep moving forward here :)
[16:50] <frankban> hatch: Unrecognized option 'port' does not sound that cryptic ;-)
[16:50] <hatch> lol I mean...
[16:50] <frankban> hatch: did you define that option in manage.py:setup?
[16:50] <hatch> the traceback doesn't go very far but I think that it's being thrown from this line
[16:50] <hatch> logging.info(options.port)
[16:50] <hatch> oh no I didn't
[16:51] <hatch> I'll do that
[16:51] <frankban> hatch: cool
[16:52] <hatch> frankban: so now might be a good time to try out your technique 
[16:52] <frankban> :-)
[16:53] <hatch> frankban:  so now you'll need to educate me on where the charm is stored in the unit :-)
[16:54] <frankban> hatch: us ethe python interpreter to find that
[16:54] <frankban> python
[16:54] <frankban> import guiserver
[16:54] <frankban> guiserver.__file__
[16:54] <hatch> heh cool
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
[16:59] <hatch> frankban: nice got it running, thanks :)
[17:00] <frankban> hatch: cool!
[17:18] <hatch> aparently juju log fails when it's trying to output None
=== kadams54-away is now known as kadams54
[17:35] <hatch> right on - it's working :)
[17:39] <hatch> rick_h_: ok so....I'd like someone to look at this code before I get on the tests but I can't remember how to push it up to my own branch lol
[17:39] <rick_h_> hatch: bzr push lp:~hatch/charms/trusty/juju-gui/customport 
[17:39] <rick_h_> I think
[17:39] <hatch> ok lets see
[17:41] <hatch> rick_h_: nice, you were right
[17:41] <hatch> https://code.launchpad.net/~hatch/charms/trusty/juju-gui/custom-port
[17:41] <rick_h_> hatch: https://code.launchpad.net/~hatch/charms/trusty/juju-gui/custom-port/+merge/241716
[17:41] <rick_h_> diff should load shortly
[17:41] <rick_h_> frankban: if you're still around would love eyeballs on ^
[17:41] <rick_h_> frankban: but if your EOD have a good night
[17:42] <frankban> rick_h_: looking, wip right?
[17:42] <hatch> hmm not a lot of loc's for how long it took :/
[17:42] <rick_h_> frankban: rgr
[17:42] <frankban> hatch: for the final proposal please use lbox
[17:42] <hatch> frankban:  yes there are no tests
[17:42] <hatch> I can't use lbox actually
[17:42] <hatch> will have to figure out the reitveld process manually
[17:56] <frankban> hatch: done
[17:59] <hatch> frankban: thanks, looking
[18:01] <hatch> frankban: so config isn't a map?
[18:01] <hatch> re your suggestion to do `port = config.get('port')`
[18:02] <hatch> config = utils.get_config() must return an object then
[18:02] <hatch> interesting
[18:04] <hatch> frankban: thanks for the comments - glad to see I was on the right track :)
[18:04] <hatch> I'm going to grab some lunch now
[18:04] <hatch> bbl
[18:06] <frankban> hatch: get is a builtin method on python maps (aka dicts)
[18:06] <frankban> done for the day, food night all!
[18:07] <frankban> good night even!
[19:06] <hatch> kadams54: heyya how goes the new bug? Was it the unrelated function not working properly?
[19:06] <kadams54> Unrelated worked fine, but we shouldn't be toggling off highlight state for services unless they're actually highlighted.
[19:07] <kadams54> So that's fixed, tested, just linting and prepping push
[19:08] <hatch> ohh gotcha, cool - I was really hoping it wasn't some difficult problem heh
[19:10] <hatch> kadams54: I like your technique of finding the bug, writing a test, then fixing the bug 
[19:11] <hatch> juju debug-log
[19:11] <hatch> bleh
[19:25] <kadams54> uiteam: https://github.com/juju/juju-gui/pull/656 is ready for reviews and QA
[19:26] <hatch> cool will check it out
[19:28] <hatch> kadams54: uhhh what? How does this fix the issue? I'm glad it does...just...what? lol
[19:28] <kadams54> hatch: are you sure you want to know?
[19:29] <hatch> well...maybe you should add a comment in the code because looking at it there is no reason why it's there
[19:29] <hatch> know what I mean?
[19:29] <hatch> or no clear reason
[19:29] <kadams54> I thought "don't toggle things that are already set correctly" was clear enough.
[19:30] <hatch> so toggle highlight off, but only if it's not hidden and has highlight?
[19:32] <kadams54> Toggle highlight off if it's not already off and not hidden.
[19:32] <kadams54> If it's already off and we do an unhighlight, we end up with unintended consequences on downstream, due to the interplay between these states.
[19:32] <kadams54> For example, unrelated services becoming unhidden at the wrong time.
[19:33] <kadams54> I'll add a comment to that effect
[19:34] <hatch> kadams54: works great - can't find any more issues -
[19:34] <kadams54> yay
[19:34] <hatch> the clearing of the container column is a little abrupt though
[19:35] <hatch> it would be nice if there was some onboarding in there
[19:35] <hatch> ^ rick_h_
[19:35]  * rick_h_ reads to catch up
[19:37] <rick_h_> hatch: hmm, yea I thought we had some onboarding at one time about selecting a machine. 
[19:37] <rick_h_> hatch: let's get it up on comingsoon and we can send an email to the list about it and see if anyone has any feedback
[19:37] <hatch> sounds goo
[19:37] <kadams54> The onboarding is in the machine column, not the container column
[19:38] <rick_h_> kadams54: right
[19:38] <rick_h_> hatch: kadams54 thinking, the best experience would probably be that if you hid something and then unhid it that it would return to where it left off selection-wise
[19:40] <hatch> I am wondering though if that is how people will use it
[19:40] <hatch> they will probably click something else ?
[19:40] <rick_h_> hatch: yea, maybe. We can run with it and adjust
[19:40] <rick_h_> it's smaller adjustments from this point
[19:40] <rick_h_> let's get people using it 
[19:41] <hatch> kadams54: I +1'd so u just need one more
[19:41] <hatch> then people can hammer on it :)
[19:45] <hatch> the guicharm make unittest needs syntax highlighting
[19:48] <rick_h_> hah
[19:50] <hatch> rick_h_: is there a reason why these test files are prefixed with numbers?
[19:51] <hatch> 00-setup 10-unit11-server
[19:51] <hatch> etc
[19:52] <rick_h_> hatch: the test tool uses it to run them in the right order
[19:52] <rick_h_> e.g. boostrap, install, check stuff, build relation, etc
[19:52] <rick_h_> alphanumeric sorting ftw
[19:52] <hatch> ahh ok I figured there must be something :)
[19:53] <hatch> I like how the unit test runner has a 'verbosity' property
[20:10] <rick_h_> kadams54: looking at your branch next
[20:10] <kadams54> Makyo beat you to it, so it's landing now
[20:11] <kadams54> But feel free to hammer away at it more :-)
[20:11] <rick_h_> kadams54: ah all good then
[20:11] <rick_h_> kadams54: so after that next refactor card let's work on a release please. 
[20:11] <kadams54> +1
[20:12] <rick_h_> I just sent a status email and if we could do the release tomorrow or friday first thing that'd be perfect :)
[20:13] <hatch> rick_h_: could I pass this branch off to someone else? I feel like these tests could take me another day because I need to learn all about them 
[20:13] <hatch> I too would like this in the release
[20:14] <rick_h_> hatch: ok, can you send an email copying me to frankban asking for help in his am to get the tests going?
[20:15] <hatch> I feel real bad dumping this :/ I just don't want to miss the release 
[20:15] <rick_h_> hatch: but make sure we set aside time to go through it and see what gets done
[20:15] <rick_h_> hatch: all good, you've done some great stuff there. Think of it less on dumping and more of mentoring :) 
[20:15] <rick_h_> and here comes the snow
[20:16] <rick_h_> hmm, so does my other watch face clock go to slovenia and urulama or australia and huw
[20:16] <hatch> haha 
[20:17] <rick_h_> one for london, one for sydney, now I've got most of the team figured out :)
[20:19] <hatch> is huw on Sydney time? I thought he was further west
[20:19] <rick_h_> east actually I think
[20:19] <rick_h_> or something, it's all backwards 
[20:19] <rick_h_> google says he's +10 so that's sydney in the picker
[20:19] <hatch> lol
[20:20] <hatch> he must get really tired hanging upside downall the time
[20:22] <Makyo> :/
[20:22] <Makyo> We seem to be regressing.
[20:22] <rick_h_> Makyo: ?
[20:23] <Makyo> Oh, crap, that's overloaded.  Just meant hatch acting 12.
[20:23] <rick_h_> oic, sorry release stuff all over regressing makes me scared :P
[20:23] <hatch> bahaha
[20:23] <Makyo> YEah, I didn't realize, hah c.c
[20:23] <hatch> Makyo: shush and get your catdog out of the window ;)
[20:24] <hatch> btw there is also an absolutely hilarious cartoon called Catdog
[20:25] <Makyo> Yeah, I remember :)
[20:37] <hatch> rick_h_: email sent
[20:37] <hatch> did you want to chat about that card in tracking?
=== kadams54 is now known as kadams54-away
[21:23] <rick_h_> hatch: sure thing, just got off a call
[21:23] <rick_h_> hatch: standup room?
[21:24] <hatch> sure 1 min just relocating to a room with good enough wifi :P
[21:48] <rick_h_> Makyo: can you join the standup hangout?
[21:58] <huwshimi> Morning
[22:02] <hatch__> morning huwshimi
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away