#juju-gui 2013-09-02
<rick_h> Makyo: http://paste.mitechie.com/show/1015/
<Makyo> http://www.youtube.com/watch?v=gxpfroru1To
<rick_h> jujugui can I get a review/qa please? https://codereview.appspot.com/13469043
<Makyo> jujugui https://codereview.appspot.com/13335048 requesting two reviews please
<Makyo> +IE10 QA
<bac> jujugui: re-enabling updates on comingsoon
<rick_h> bac: cool thanks
#juju-gui 2013-09-03
<huwshimi> luca__: http://10.20.69.166:2464/
<hatch> rick_h, done
<rick_h> hatch: woot!
<rick_h> .c
<hatch> Makyo, qa'ing now
<frankban> bcsaller: https://codereview.appspot.com/13309044 thanks!
<huwshimi> rick_h: What's the nose package I need to install to be able to run single tests?
<rick_h> huwshimi: https://pypi.python.org/pypi/nose-selecttests/0.4
<huwshimi> rick_h: Cheers
<rick_h> huwshimi: so you can bin/pip install nose-selecttests and then you can run tests with -t XXXXX
<rick_h> Makyo: https://codereview.appspot.com/13441046/
<Makyo> bcsaller, I landed your test fix as part of this branch, since my last one broke ci
<bcsaller> ahh, ok, I merged trunk and didn't see it so I did finally propose 
<Makyo> Still lboxing :)
<abentley> orangesquad, bac or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/use-latest-charm/+merge/183661 ?
 * sinzui looks
<benji> wow, fast on the trigger this morning 
<abentley> benji: 
<abentley> benji: Was basically done on Friday.
<sinzui> abentley, r=me
<rick_h> curses, no IE love https://developer.mozilla.org/en-US/docs/WebAPI/Using_Web_Notifications
<jcsackett> orangesquad: i have returned from having my stitches taken out. sinzui, i'll be free for our normal 1x1 time.
<sinzui> jcsackett, orangesquad: let's hangout in 9 minutes to do some orienteering
<abentley> sinzui: +1
<sinzui> jcsackett, adeuring https://plus.google.com/hangouts/_/538341c5065bcf63afe4dfc783cbb34db8a826b1?hl=en
<jcsackett> sinzui: thanks; fighting G+
<abentley> sinzui, abel: Test runs used to take 4 minutes.  Now, they take 3 hours: https://jenkins.qa.ubuntu.com/job/charmworld-merger-trunk/buildTimeTrend
<sinzui> abentley, adeuring Lp's test runs take 35 minutes. I think we need to save face and make runs fast again
<adeuring> sinzui: agreed...
<jcastro> hey guys
<jcastro> any word on when we'll have more readable URLs land?
<rick_h> jcastro: ummm...not at the moment. 
<jcastro> ugh, this sucks
<jcastro> ok then, I'm going to use the github URLs!
<frankban> hatch: https://ec2-54-226-194-198.compute-1.amazonaws.com/:flags:/serviceInspector/
<rick_h> jujugui review please? https://codereview.appspot.com/13443044
<bcsaller> hatch: when you have a minute can you look to see if you think I missed any topics in https://codereview.appspot.com/13415045
<abentley> sinzui: I think we could avoid Tarmac by using this: https://wiki.jenkins-ci.org/display/JENKINS/URLTrigger+Plugin
<sinzui> Yummy
<benji> call?
<bac> benji: i'm here
<benji> bac: what you talking about, Willis?
<bac> jujugui: are sprinters going to participate in our daily call?
<bac> benji: i mean, i'm here and willing to have a call
<benji> oh
<benji> I thought you were saying you were on the call already
<bac> no sir
<bcsaller> we are really busy trying to push back on having to do work ;)
<rick_h> bac: benji gary says yes we'll do a hangout shortly and will update
<rick_h> hangout url will be offered in the near future?
<bcsaller> hatch: I did send you a link before
<bac> rick_h: eta on "shortly"?  this hour?
<rick_h> bac: I *think* so 
<rick_h> bac: I interrupted his current conversation to bring this up and he said yes, he wants to chat and will send a url
<rick_h> but no specific timeline given atm
<bcsaller> rick_h: https://codereview.appspot.com/12323043/ has the instructions you wanted
<bac> benji: i'm getting F and E in trunk tests.  :(
<benji> :(
<bac> adeuring: benji and i notice 'make test' on charmworld is insanely slow.  is that a result of your es test fixes perhaps?
<adeuring> bac: I'm afraid so :(
<benji> bac: I made wait_for_green_status a noop and my subset of the tests went from 186 seconds to 6 seconds.
<adeuring> It's hard t
<adeuring> pproblem for me right now is that the tests a _cirrently_ fast again
<adeuring> without any apparent related change...
<bac> benji: i did the same and ran 'make test' in trunk resulting in
<bac> Ran 721 tests in 53.682s
<bac> FAILED (errors=19, failures=6)
<bac> adeuring: with trunk my tests ran for 10 minutes and didn't get past the first line of dots
<adeuring> crazy... abentley suggested to s/green/yellw/ in ElasticSearchLient.wait_for_green_status(). That might help butmight reintroduce the previous psurious failures...
<benji> bac: have time for a review? https://code.launchpad.net/~benji/charmworld/bundle-feature-ui/+merge/183709
<bac> benji: sure
<benji> bac: I assume its just you and me on charmworld now, right?
<benji> (after the orange guys finish up any branches they are working on)
<bac> benji: yeah.  glad we don't require two reviews
<benji> heh
<bac> abentley, sinzui: in the wait_for_green method, we're passing a timeout to client.health as an integer.  the docs for es looks like it wants a string that includes units, e.g. '30s'.  does the python client convert those?  it doesn't look like it to me.
<sinzui> bac: timeout â Number of seconds to wait for each request before raising Timeout
<sinzui> http://pyelasticsearch.readthedocs.org/en/latest/api/#module-pyelasticsearch
<sinzui> bac: abentley oh, but I see that some methods do want a string like '5m'
<sinzui> I think you are correct bac. The health check wants a string with units
<bac> sinzui: thanks for the link to docs!  i hadn't found them before.
<bac> sinzui: even if i wanted an integer, those docs say 'number of seconds'.  it looks like our code thinks it is milliseconds.
<bac> i.e. the default is 30,000
<sinzui> We have created a very patient test suite
<bac> sinzui: but we have impatient developers
<bac> oi, bin/es-update takes forever now too
<bac> benji: how do i see your new page?
<benji> bac: you have to go to a URL like /bundles/wiki-bundle/wiki/featured/edit
<benji> as far as I can tell there is no way to click through to a charm featured edit page so I didn't make a way to do it for bundles either
<bac> benji: so it has to be promulgated?
<gary_poster> bac, benji, hey.  I'm sorry I missed the call.  Do you want to have a quick call now to catch up, or talk tomorrow?
<bac> gary_poster: i'm free to talk now, if you have time.
<benji> bac: yep; that is the same as for charms (only promulgated charms can be featured)
<bac> benji: so do you have test data?  i've just been loading the two bundles from LP and neither are promulgated
<benji> bac: I did the same and it worked for me; maybe my understanding of how it works is flawed
<benji> gary_poster: I had just started lunch.  I don't think I have anything significant to discuss.
<bac> benji: when i try to go to http://127.0.0.1:2464/charms/precise/apache2-passenger/featured/edit i get 403 - Forbidden
<bac> when i try to login i get 'resource not found.'
<bac> benji: when you're back from lunch we should talk
<gary_poster> bac, benji, I don't know if you replied: the network kicked my off almost immediately after saying hi to you :-P
<gary_poster> sorry
<bac> gary_poster: we said we'd be glad to talk to you tomorrow since it is so late over there and benji is eating lunch.
<gary_poster> bac, cool, thanks. :-)  talk you you tomorrow, then
<bac> gary_poster: he and i are talking amongst ourselves frequently and don't have much to say
<gary_poster> ok cool bac.  I wanted to let you know what is going on here
<gary_poster> so will talk tomorrow
<bac> gary_poster: ok, have a good evening.
<gary_poster> thanks, have a nice afternoon!
<gary_poster> bye
<abentley> sinzui: my critical bugfixes have landed.  I would like to do a release.  Is it safe to do that?
<sinzui> abentley, it is
<benji> bac: I'm back
<abentley> jcastro m_3 marcoceppi: I believe the issues you reported Friday are all fixed.
<abentley> Well, the ones I was working on.  I don't know what other issues you might have reported :-)
<jcastro> abentley: which issue?
<jcastro> oh, the rack/rails one?
<abentley> jcastro: Yes.
<abentley> sinzui, benji, bac: I've deployed r377 to production.
<benji> k
<sinzui> thank you abentley 
<bac> benji: sorry i had to run an errand
<benji> no worries
<bac> benji: guichat?
<benji> sure
<abentley> sinzui: I am setting up a jenkins instance, and trying to run the test suite, but it is not installing pip.  Any ideas?  http://162.213.35.27:8080/job/Test%20charmworld/ws/bin/
 * sinzui thinks
<bac> benji: when you resolve your conflicts be sure to import pymongo into helpers
<sinzui> abentley, check the charm. I think there was a hack for pip...well maybe to install a specific pip lib
 * sinzui visits a meeting
<abentley> sinzui: pip is installed on the host, and the only reference to pip in the charm is a one-liner in config-changed that uses pip.
<sinzui> abentley, I have pip installed as /usr/bin/pip not /bin/pip
<sinzui> oh, but this in our tree
<abentley> sinzui: I have both.
<bac> benji: try this: http://staging.jujucharms.com/login/openid
<bac> abentley, sinzui: we have a problem:  http://manage.jujucharms.com/login/openid  gives a 404.  any idea what might've caused this problem?
<sinzui> bac: no, but I see staging is also affected
<abentley> sinzui: I wonder if it's related to your routes work?
<benji> bac: hmm, that's not good
<bac> abentley, sinzui: i'm trying r372, before sinzui's branch
<sinzui> bac, abentley, benji, surely this is caused by my URL changes to support juju-gui promulgated charms
<bac> 372 works
<bac> 373 breaks
<abentley> bac: confirmed.
<sinzui> bac Since login can happen against anything, we might need to specify series or "login" specifically
<sinzui> bac: we don't have a route for login, only logout. So routing's promulgated charm rule will always win
<sinzui> bac, we can bac my rev out, remove "# Unnamespaced promulgated charms" from routing, add routing for login add a factory/custom_predicate that knows charm series
<bac> sinzui: how does login work in the absence of the promulgated charm routing rules?
<bac> sinzui: is there a default that it hits?
<sinzui> I was just going to read how it works
<bac> sinzui: so there is an 'add_ubuntu_sso' after the routing is built.  i guess that adds a default
<sinzui> bac, I see, and it is always last :(
<bac> sinzui: but it looks like that call can be made in routes.py before the promulgated
<sinzui> bac, I agree. I don't know why it wasn't done like that. Maybe charmworld was intended to be separate
<bac> http://paste.ubuntu.com/6060075/
<bac> sinzui: i think that may work but i don't have any promulgated charms in my test data to see if that routing still works
<bac> sinzui: did you add test coverage for those routes?
<bac> not that our tests work or anything
<sinzui> bac, I certainly did!
<bac> \o/
<sinzui> bac, login is from the first week we joined the project.
 * sinzui find children
<abentley> I guess I just assumed that the last thing you add would have the highest priority.
<sinzui> abentley, I think the order of registration is the order of matching. I had to move rules when adding the new urls to not collide with historic urls
<sinzui> bac, did you tell charmers that they cannot qa/feature any charms at the moment?
<bac> sinzui: i did not
<bac> sinzui: i'm been caught up trying to get a fix
<sinzui> I will tell them, Thy might no ever know since featuring and QA is a rare activity
<bac> sinzui: you will send an email to juju or to ~charmers directly?
<sinzui> bac charmers is a highlight word in #juju.
<bac> benji: could you review and QA/test https://code.launchpad.net/~bac/charmworld/fix-login/+merge/183757
<benji> bac: sure
<bac> sinzui: if you could glance at ^^^ that would be nice too.
<sinzui> sure
<benji> bac: 
<benji> The branch looks good and QA passed.
<benji> Reply
<benji> s/Reply//
<bac> benji: cool.  did you try http://127.0.0.1:2464/precise/bonnie ?  (it passes)
<benji> nope, I did apache
<benji> bonnie looks fine too
<bac> benji: and all of the tests passed?
<benji> bac: oh, I forgot the tests (I'm really not feeling well all of a sudden).  Startin gth etests now.
<bac> benji: when that lands and is merged i can QA your branch.
<benji> bac: I didn't comment out the slow function, should I have?
<bac> benji: don't know.  nothing works on my vm
<sinzui> bac, can't you change the tests to wait for yellow?
<bac> sinzui: didn't help
<benji> the tests are slowly passing, so I'll give them some time
<bac> sinzui: my VM seems to be pathological wrt these timeouts
<sinzui> egads!
<bac> benji: in the good old days of say r370, how long did it take 'make test' to run on your machine?
<bac> mine was always about 74 seconds
<benji> I don't know exactly, but not much more than a minute.
<bac> yeah, so clock time mine isn't that slow.  i'm not sure why it causes the es stuff to go nuts
<m_3> abentley: thanks!!
<m_3> I'll test it this afternoon
<bac> benji: i also have this review stagnating: https://code.launchpad.net/~bac/charmworld/bundle-icon/+merge/183730
<benji> bac: looking
<bac> benji: did the tests ever finish?
<benji> still running
<bac> oi goi oi
<benji> bac: sorry, I don't have the mental accuity to understand that branch right now; the only thing I can think right now is that I'm surprised that much code is needed bceause we are already storing all the bundle's file at ingest time
<bac> benji: they werent' being put into gridfs
<bac> benji: but it can wait until tomorrow.
<benji> thanks
<benji> there are about 100 dots thus far
<benji> (no errors or failures)
<benji> bac: tests still running; I bet it takes 20 more minutes; I'll tell you when it finishes
<bac> sinzui: do you think it wise to try to push this branch to production tonight?  i'm unsure about webop coverage.
<sinzui> I can
<bac> sinzui: i'd like to shepherd it if you think it is feasible.
<bac> sinzui: gotta get it tested, landed, and on staging first
<benji> 200 dots or so
<bac> sinzui: after changing green to yellow i got
<bac> Ran 724 tests in 105.753s
<bac> FAILED (errors=7, failures=4)
<bac> benji: fwiw, i stopped elasticsearch, removed the storage in /var/lib/elasticsearch, and restarted it.  my test sped up a lot.
<sinzui> yuck
<sinzui> bac, I will have time to run your branch in about 10 minutes
<benji> bac: do you want me to try that or let this run finish?
<bac> benji: how many dots to go?
<bac> benji: and there are no failures yet?
<benji> bac: no failures, 220 dots; I don't know how many are left
<bac> oi.  well 724 tests.
<benji> yow
<benji> ok, I'm trying the speedup
<benji> bac: I don't think this is any faster.  I'm giving up.  I vote you merge your branch as-is and you and I work on the test issue as critical in the morning.
<bac> benji: ok.
<bac> benji: have a good night
<benji> thanks
<bac> sinzui: how often does tarmac run?  my branch was approved 31 minutes ago but has not merged
<sinzui> bac. every 10/15 minutes, but as abentley noted in the channel, Jenkins takes 3h to run the test suite
<bac> sinzui: oh, my
<bac> sinzui: sorry i missed that comment
<sinzui> I favour rolling back adeuring's changes. It takes too long to respond to a  real problem...Lp's test suite takes 35 minutes...thank you former yellow squad
<bac> sinzui: i'll do that tomorrow
<bac> it is insane
#juju-gui 2013-09-04
<rick_h> Makyo: http://jsbin.com/ENIbojO/1/ checking console logs
<gary_poster> rick_h, http://www.tasrestaurants.co.uk/pide.html
<antdillon> gary_poster, Do you by any chance have admin rights for juju.ubuntu.com?
<gary_poster> no, sorry antdillon 
<antdillon> gary_poster, Thanks
<gary_poster> ...for nothing ;-)
<bac> adeuring: the wait_for_green effort is not workable.  jenkins is taking over 3 hours to test and land branches.  sinzui and i decided it is best for now to revert your branch.  would you have time to prepare a rollback branch and propose it?
<adeuring> bac: yes, though "yellow" will help only partially. I think I have meanwhile an idea what is wrong: the core setup. /etc/elasticsearch/elasticsearch.yml allows to set the parameters number_of_replicas and number_of_shards. The default is 5 and 1, respectively, and at least our dev environment has no replicas...
<adeuring> Using the value 1 and zero helps. 
<adeuring> But I'd like to set this in create_index(), but xould not yet figure out the right parameters...
<huwshimi> luca__: Icons required: eye, spanner, cog (plus hover states if applicable) and trash can.
<adeuring> bac: can you have a look here https://code.launchpad.net/~adeuring/charmworld/set_n_replicas_and_shards/+merge/183846  (and please test the branch too ;)
<hatch> http://askubuntu.com/questions/73589/higher-screen-resolution-for-virtualbox
<huwshimi> jujugui: Can I have a review of my inspector changes? https://codereview.appspot.com/13521043/
<bac> adeuring: i ran your new branch and got:
<bac> Ran 726 tests in 88.575s
<bac> FAILED (errors=7, failures=4)
<bac> so it is faster
<adeuring> bac: great. Can you show me the errors?
<bac> adeuring: many refer to es client not having 'multi_get'.  http://paste.ubuntu.com/6062400/
<adeuring> bac: thanks. 
<adeuring> bac: WHich version of pyelasticsearch is installed on your machine? It's 0.6 on my machine and multgi_get is defined there.
<bac> adeuring: it is installed by charmworld setup in the venv.  requirements.txt:pyelasticsearch==0.6
<adeuring> weird...
<bac> i do not have it installed in my system python
<adeuring> bac: right; but it is  strange that class ElasticSearch defines a method multi_get() and we get a failure like this AttributeError... I'm just trying to figure out how this can happen
<bac> adeuring: i'll drop into pdb and see if i can figure it out
<Makyo> rick_h, https://gist.github.com/makyo/6436215
<benji> back and adeuring: let me know if there is anything I can do
<adeuring> benji: I am really puzlled by most of these errors: http://paste.ubuntu.com/6062400/ If you can reproduce them (using lp:~adeuring/charmworld/set_n_replicas_and_shards) and try to figure out what's causing them -- that would be great.
<benji> adeuring: I'll see if I can repro
<adeuring> thanks
<adeuring> be, bac: The last error (in test_search_charm_sort_newest) looks familiar. I think it is caused by search() not using any yorting by defualt.
<Makyo> hatch, huwshimi http://www.popvssoda.com/
<bac> adeuring: turns out my pyelasticsearch was still 0.4.1.  i didn't do a 'make deps' after it got upgraded
<adeuring> bac, benji: ah, that explains a few problems ;)
<benji> ooh
<benji> deps really should be a dependency of install
<benji> adeuring: after a "make deps" I only get one failure: http://paste.ubuntu.com/6062493/
<adeuring> benji: cool. can you reproduce this eror more or less reliably? In that case, could you try to add index_client.wait_for-green_status() before the get_:mapping() call in this test?
<benji> I'm doing a second run now to see.  If so I'll add that call and see.
<bac> adeuring, benji: running abel's branch i get only one failure http://paste.ubuntu.com/6062553/
<bac> different from benji's
<benji> heh
<benji> and my tests are still slow :(
<bac> that test fails in isolation?
<adeuring> bac: sounds great. I think we need a better test setup here. I can this error too occasionally... I believe that api_search() does not specify any sort order by default.
<bac> benji: still slow?  huh.  mine are at 100s or so
<benji> bac: I haven't checked that one
<bac> adeuring, benji: also, i have a simple fix to the openid log pollution in the test output
<benji> after a "make distclean"... wait!  I was running in the wrong darn branch
<adeuring> benji: did you try to restart the ES server?
<benji> bac and adeuring: ooh, and I noticed that I have two failures, not one.  And the one I missed is the same bac had
 * benji needs to go for a mind-clearing jog or something.
<adeuring> benji: I'll look into this "sort issue"
<benji> bac and adeuring: I get bac's failure when I run that test in isolation
<bac> adeuring: would you have a look at lp:~bac/charmworld/timeout-values ?  reviewing the documentation it seems for the health checks the timeout values should be strings
 * adeuring is looking
<bac> jcsackett: do you know if sinzui is in today?
<bac> jcsackett: do you have access to charmworld staging?
<bac> jcsackett: management access via juju, i mean
<adeuring> bac: Right, I think I've tried this before but then thought that I could specify integers (meaning milliseconds) too. But explicitly speicfying a unit sounds reasonable.
<bac> adeuring: other calls indicate they want an integer specifying seconds not milliseconds
<bac> adeuring: please merge that branch into yours for a single landing if you agree
<bac> adeuring: do you have access to staging via juju?
<adeuring> bac: sure, i'll merge it. But I am a bit puzzled that an integer would mean seconds, not millisecondes. And yes, I have meanwhile juju access to staging.
<bac> adeuring: i'm seeing this when trying to access staging
<bac> 2013-09-04 09:01:17,726 INFO Connecting to environment...
<bac> 2013-09-04 09:01:19,284 ERROR juju environment not found: is the environment bootstrapped?
<bac> when running  /usr/bin/juju status -e staging
<bac> adeuring: can you see if you can simply get status via juju?
<adeuring> bac: I'm getting the same error.
<bac> ugh
<bac> yay!
<bac> good morning sinzui!
<sinzui> Good? I am not going to commit to such an accusation. I will simply state the obvious. Morning bac
<bac> sinzui: it is good b/c you're here.  hey, both adeuring and i are inable to access staging via juju.  "juju status -e staging" reports the environment isn't up
<bac> s/inable/unable
<sinzui> ah
 * sinzui wonders if canonistack has toppled juju
<benji> bac and adeuring: test run time for me is 115s and on the last run I only got bac's failure
<adeuring> \o/
<bac> sinzui: the web app is running
<bac> benji: let's not call this 'bac's failure'
<benji> heh
<benji> "the bacobian abnormality"
<sinzui> bac, adeuring :( I was tempted to write kirkland to say canonistack has bad weeks and good months. We have completed a good month. This is out bad week
<adeuring> yeah... though I found one setup issue we had with elasticsearch since we began to use it...
<sinzui> bac, adeuring. I suspect the state server and possibly the agents are zombies. I have fixed this situation in the past by rebooting the the instances via nova
 * sinzui checks that he documented this
<bac> adeuring, benji: i propose abel disable the failing test, land the branch, and then leisurely try to fix the test.  the rest of us need the test speed-up now.
<benji> +1
<adeuring> ok, let me just save the fixes i have in place. ES is real fun to work with :(
<bac> benji: fwiw i'm now seeing the full suite run in ~90s
<sinzui> bac: I think this issue is like the first 3 reported problems in https://docs.google.com/a/canonical.com/document/d/190xKLPpEPSrlVix4D9eX_aTciiKFo12h0u7MpzqI28I/edit# . Per the doc, I just sshed and rebooted the state server (instance 0)
<benji> bac: sounds good (my machine is a tad slow, so I would expect mine to give slightly longer run times)
<rick_h> abentley: ping, got a sec to chat search?
<abentley> rick_h: sure.  juju-gui?
<rick_h> abentley: well figured I'd ask here. I noticed the docs note some extra fields to search on, summary, etc?
<bac> sinzui: i didn't realize i could ssh natively, thought i had to use 'juju ssh'.
<rick_h> abentley: but it comes back as not supported: http://staging.jujucharms.com/api/2/charms?summary=apache
<rick_h> abentley: and http://staging.jujucharms.com/api/3/search?summary=apache
<sinzui> bac, yeah. We always have the cloud's tools to use, but I too am not as versed in them as I am Juju
<rick_h> abentley: is this intended to work? I was looking at the bugs around m_3 about wanting to search more data and I was trying to see how we might do that currently.
<abentley> rick_h: What the docs mean is that if you do http://staging.jujucharms.com/api/3/search?text=apache, one of the the things searched is the summary field.
<rick_h> abentley: ooooh, ok. 
<bac> sinzui: can you grant me edit to that doc?
<adeuring> bac, benji, sinzui: so, here is the MP: https://code.launchpad.net/~adeuring/charmworld/set_n_replicas_and_shards/+merge/183846
<sinzui> bac: done
<benji> adeuring: I'll review it
<sinzui> The state servers logs still say they cannot talk to the zookeeper. Looks like the monkeys are loose.
<sinzui> abentley, bac, benji, adeuring. If I don't have this sorted out soon, I propose we redeploy the stack since that is 20 minutes at most
<benji> +1
<benji> adeuring: the branch looks good to me; I had a question that is bigger than the branch and shouldn't block its landing
<abentley> sinzui: This is probably not the right time, but now that canonistack has a much larger floating IP range, we can start looking at using gojuju instead of pyjuju.
<sinzui> abentley, I disagree. This might be the right time.
<sinzui> I think we want to ask webops if they are prepared to redeploy charmworld on juju 1.x
<adeuring> benji: thanks!
 * sinzui wants to remove pyjuju and zookeeper from his computers
<bac> sinzui: can you update that doc with instructions for what you tried?  i'm unsure.
<abentley> sinzui: Yes, maybe it's time.
<bac> adeuring: i thought you were going to include my timeout-values branch.  do you not think it is needed?
<bac> adeuring: but perhaps i should land it separately, so never mind
<adeuring> bac: sorry, simply forgot it :( 
<bac> adeuring: i'll do it once yours lands
<bac> better actually
<bac> adeuring: and thanks a million for figuring out the underlying problem!
<bac> benji, adeuring: please have a look https://code.launchpad.net/~bac/charmworld/timeout-values/+merge/183877
<adeuring> bac: on standup call right now; I'll look asap
 * benji looks
<benji> bac: looks good
<sinzui> bac benji: I am inclined to teardown the staging env and rebuild it with gojuju. bac you have an instance in it. Can I remove it too?
<bac> sinzui: yes
<benji> sinzui: sounds like a good idea; we need to be transitioning to gojuju
<bac> sinzui: there will be some setup changes
<bac> a missing cert, i believe, that gojuju wants
<sinzui> hmm
<sinzui> I need to learn about that. This is the script we used in the last few deploys of the stack: https://pastebin.canonical.com/91952/
<bac> benji: i'm back to looking at your bundle-feature-ui branch.  it has a conflict.
<benji> bac: oh, yeah; I had forgotten about that.  I'll look at it now.
<bac> benji: i've fixed it locally about three times...  :)
<bac> benji: your branch fails this test repeatedly: http://paste.ubuntu.com/6062793/
<benji> bac: yep, I'm seeing the same thing.
<bac> sinzui: does the charm deploy charmworld trunk or a fixed revno?
<sinzui> bac by default it deploys tip (-1). we call set to increment the revno
<bac> sinzui: cool, tip is what we want
<sinzui> I see staging is finally gone. I will update my config and try gojuju
<rick_h> jujugui review time please https://codereview.appspot.com/13237052
<jcsackett> sinzui: i'm looking at the audit charms card. i'm assuming anywhere a queue is referred to here, we're talking about charmworld tools?
<benji> bac: all tests are passing: https://code.launchpad.net/~benji/charmworld/bundle-feature-ui/+merge/183709
<bac> benji: great
 * bac reboots
<frankban> hatch: https://code.launchpad.net/~frankban/juju-gui/ci-activate-inspector/+merge/183898
<Makyo> jujugui https://codereview.appspot.com/13527043/ fairly small
<benji> Makyo: I'll take a look
<Makyo> benji, Thanks
<abentley> sinzui: Got a build running the tests: http://162.213.35.27:8080/job/test-charmworld/1/console
<frankban> Makyo: https://codereview.appspot.com/13313044
<bac> benji: at line 206 of your diff, does that assignment of form last until the end of the method or is the scope just the exception handler?
 * benji looks
<benji> bac: end of the method (that code was moved during the refactor, I don't think I touched it)
<sinzui> jcsackett, Yes, I believe queue == Tools.
<bac> benji: that is overly clever and confusing, i think.
<jcsackett> sinzui: ok; any idea what this "build 2nd queue or combined queue" means?
<sinzui> abentley, \o/
<jcsackett> seems like maybe a redundant bullet point, given the first one is about building a new queue? or is it referring to something else?
<benji> bac: I agree.  Smuggling return values through exceptions isn't exactly something that should be done lightly.
<benji> it's a pretty big refactor though (or at least a pretty big task to understand the form validation system)
<benji> I would be inclined to have a bug/card along the lines of "revamp and potentially replace form validation logic with third party library".
<sinzui> jcsackett, we want to re-review everything. charmers need a way to burn a list of charms down. The review criteria is more strict than the past. The goal is to record what needs to be done (bug reports?). charmers have a queue of MPs, but these are only the active development charms
<abentley> sinzui: 1x1?
<jcsackett> sinzui: ah, ok.
<sinzui> jcsackett, We can choose to build a new queue or augment the current queue. The effort is one time so we can plan for a way to get a list of items to do. We can discuss this later in a 1x1
<jcsackett> sinzui: sounds good.
<sinzui> abentley, yes our 1x1...but i need a few minutes to find caffeine
<abentley> sinzui: :-)
<sinzui> abentley, I am ready, shall I call?
<abentley> sinzui: sure.
<rick_h> abentley: so we want to put the owner on the charm token but I recall there was a reason that was bad?
<rick_h> jcastro: ^^ as well
<bac> benji:  http://127.0.0.1:2464/bundles/wiki/wiki/featured/edit  this url should work but doesn't b/c that bundle is not promulgated, right?
<abentley> rick_h: otp
<rick_h> we're pondering "If this is not a reviewed charm, put the owner name on the charm token"
<rick_h> abentley: rgr
 * benji looks
<benji> bac: I can't get that bundle to show up after I've cleared my DB.  Any hints?  I ran bin/enqueue --prefix '~charmers/charms/precise' --limit=100; bin/ingest-queued
<bac> benji: this is what i run: http://paste.ubuntu.com/6063136/
<bac> benji: but first i change charmworld.ini to limit to 10 instead of 110 charms
<benji> k
<benji> me thinks we need a script for setting up a dev DB; something like what you have there
<bac> jujugui are we having a call?
<bac> or am i having lunch?
 * bac roots for the latter
<gary_poster> bac benji I am in guichat.  I think.
<bac> gary_poster: yay
<hatch> ahoy Goodspud 
<Goodspud> Aloha 
<hatch> how are you?
<Goodspud> All is good in my world. I hear there are some of the crew on London? 
<Goodspud> Er, *in 
<hatch> yup - it's expensive here :P
<adeuring> bac, benji, abentley: could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/fix-more-spurious-failures/+merge/183919 ?
<hatch> jujugui could I get a review on https://codereview.appspot.com/13237053 plz
<bac> sinzui: what't the status of staging?
<sinzui> My deploy failed a few minutes ago. I see an error in my config
<benji> bac: was the "needs fixing" because of the overly clever form validation bit?
<Goodspud> Apologies hatch, I lost my connection on my phone 
 * benji suspects bac is lunching, so he does the same.
<sinzui> bac: sorry for the delay. I need to do a few hacks to deploy because the much promised public ips aren't here yet
 * benji is back after a short lunch
<benji> back let me know when you're around
<bac> benji: no, the needs fixing was due to the uncaught exception being raised.  sorry i wasn't clear.
<benji> bac: cool, in that case it is ready for you to look at again
<bac> dang, i should've said 'both'
<benji> bac: I don't follow.  "both" what?
<bac> benji: both issues.  assigning form in the exception and not raising the 404.
<bac> benji: but it looks good.  r=me
<benji> yay
<benji> bac: I'm looking at your bundles icon branch; do you have a moment for a call about it?
<bac> sure
<jcsackett> jujugui: is there a simple way to determine what series the juju-GUI app is running on within the app code?
<hazmat> jcsackett, it can look for itself within the env
<hazmat> jcsackett, ie examine its own charm, doesn't work against the fake/mems
<bac> how goes the battle sinzui?  (sorry i got disconnected and distracted.)
<sinzui> bac: ingestion just started. maybe 15 minutes?
<sinzui> bac: abentley: I think the authorized keys option is bad, or just obtuse: https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack/CanonistackWithJujuCore
<sinzui> ^ When I set it, such as with the staging key we use, I get locked out.
<sinzui> The successful setup lets juju choose keys
<abentley> sinzui: You're putting the contents of the public key there?
<sinzui> abentley, I added the path to the staging public key
<abentley> sinzui: The way I read it, it's not a path, it's the actual contents of the key.
<abentley> sinzui: That's why I said it would make distributing environments.yaml more convenient in the future.
<sinzui> abentley, a list of the keys? well I might tear this down in a few hours and try again
<rick_h> jcsackett: did you get it figured out?
<jcsackett> rick_h: not yet; made note of hazmat's suggestion, but that does nothing for sandbox mode.
<jcsackett> rick_h: working on it alongside other things; hope to deal with it tomorrow morning.
<rick_h> jcsackett: app.env.get('defaultSeries')
<jcastro> rick_h: I just found a shitty bug
<jcastro> rick_h: ok so in the jujucharms.com search box
<jcsackett> rick_h: well then.
<jcsackett> that's easier. :-P
<rick_h> jcastro: hopefully something we can address or have addressed. Lots of bug finding lately
<sinzui> bac: looks like mongodb has an agent-state error. charmworld is waiting to mongodb
<jcastro> search for "rabbit" = nothing. search for "rabbitmq" returns rabbitmq-server
<jcastro> how come rabbit doesn't return anything?
<rick_h> jcastro: yea, it matches full names, partial matches in fields like summary/etc
<bac> sinzui: ok
<rick_h> jcastro: because rabbit is part of the word. We don't tokenize it. I think it's something we'll look at changing as trying ot get better search, but not set in stone atm
<hazmat> jcsackett, another option its part of the config . and the charm can write it out, or default value from config for fake/mems
<hazmat> rick_h, default doesn't nesc. correspond to the gui series though
<jcsackett> hazmat: i think rick_h's approach fits my needs; we just want to grab the env series. i think my question garbled my intent.
<rick_h> hazmat: true, but for what jcsackett is doing I think works. It's basically a helper to plus up the series you're working 'in'. 
<hazmat> ah cool
<rick_h> for search results ranking a little bit
#juju-gui 2013-09-05
<luca___> if I want to add 20 units to postgres do I type "juju add-unit postgres"
<luca___> gary_poster: rick_h Makyo ^
<Makyo> juju add-unit -n 20 postgres I think
<Makyo> luca___, juju add-unit postgres -n 20
<Makyo> luca___, Or either works.  The docs are conflicting :P
<luca___> Makyo: I see, thank you
<luca___> someone needs to juju add-unit luca's brain -n 20
<Makyo> If I could scale up like that, I imagine this would all be a lot easier.
<Makyo> hatch, http://www.youtube.com/watch?v=mC4Z8uIoVcQ
<Makyo> For whenever.
<huwshimi> rick_h: http://10.20.69.166:2464/
<luca__> huwshimi: Scale up with these constraints?
<huwshimi> Does anyone remember writing this comment in the inspector CSS? "The height of each list is 35px so setting this to help the auto max height script."
<rick_h> huwshimi: I think that is from the auto adjusting height stuff right?
<huwshimi> rick_h: If you get a chance could you come over and explain what's going on there?
<rick_h> huwshimi: yea
<huwshimi> rick_h: No hurry
<rick_h> yea, trying to figure out if we're having an 'all' meeting or not
<Makyo> frankban, categoryWrapperNode.filter(function(d) { return d3.select(this).classed('landscape-needs-reboot'); })
<sinzui> jcsackett, hangout?
<benji> bac: I finished my Makefile branch: https://code.launchpad.net/~benji/charmworld/makefile-tweaks/+merge/184105
<benji> I would enjoy a review if you have time.
<bac> benji: ok.  i'm reviewing abel's branch atm
<benji> thanks
<bac> benji: my icon2 branch is ready too.  i'm going to kill the initial MP
<benji> bac: I'll review it 
<benji> (just let me know when and where)
<huwshimi> If anyone wants to review my charmworld redesign branch it's here: https://code.launchpad.net/~huwshimi/charmworld/charmworld-styling/+merge/184078
<huwshimi> Don't worry, it's only a 11,237 line diff.
<benji> huwshimi: I'll take a look.
<benji> If I'm not back in three weeks tell my family that I love them.
<Makyo> frankban, https://gist.github.com/makyo/6450487
<huwshimi> benji: Haha, thanks. My apologies.
<benji> I wonder if I can get this diff up on Rietveld.  It would be nice to do this as an in-line review.
<bac> benji: makefile branch approved but with one question about use in production.
<benji> cool, I'll look
<hatch> gary_poster, review done
<gary_poster> thank you I saw hatch :-)
<bac> benji: looks like huwshimi's branch breaks the makefile wrt css
<benji> bac: yeah, I was just noticing the same thing
<bac> benji: quick, land yours and maybe that'll fix it
<benji> heh, I doubt it
<huwshimi> bac, benji: Oh did I not remove some bootstrap paths or something?
<rick_h> hatch: can you QA my branch that gary reviewed please? https://codereview.appspot.com/13368049/
<bac> huwshimi: there is a rule that depends on theme.less but it has been removed
<huwshimi> oops
<bac> huwshimi: so is the css all static now?  not less and not generated?
<huwshimi> bac: Yeah, in fact we just load the CSS hosted on ubuntu.com
<benji> eww, the charm is written in shell script
<Makyo> hatch, https://codereview.appspot.com/13563043
<jcsackett> sinzui: so, juju is now throwing "found no instances" i assume because i'm no longer shuttled. however, nova lists nothing for me as well. do we have nothing live, or is my nova lying?
<sinzui> jcsackett, you are being lied to. There nova list shows me 6 staging machines, 2 qa machines and a bac instance
<jcsackett> sinzui: ok, so juju is probably configured right, but not canonistack itself. interesting.
<sinzui> This morning I source orange stack, set JUJU_HOME to the dir to my env.yaml, ran sshuttle, did juju status
<benji> huwshimi: If you can fix that make issue it would help me in the review (I'm trying to get the diff up on Rietveld so I can do in-line comments)
<huwshimi> benji: Sure, will take a look now.
<benji> cool
<jcsackett> sinzui: right, i was going to shuttle, but i don't want to ping you every time i need to get the IPs to do so. so time to debug nova.
<bac> huwshimi: thanks for the rework of the charm and bundle pages.  sorry they were such a mess to start.
<bac> adeuring: may i assign the ES test problem card to you on the kanban board?
<adeuring> bac: well... not sure if this fits into the tasks I am supposed to works on in the next time. sinzui: ^^^
<bac> adeuring: i figured your current branch did the work.
<bac> adeuring: i'm just trying to clean up the board and thought you should get credit for work already done.
<adeuring> bac: no, not at all. I suspect that we need to not only use the ES call health() but to also check the index status, as descriibed here http://www.elasticsearch.org/guide/reference/api/admin-indices-status/
<abentley> orangesquad: Here's a blog post that I believe describes how the launchpad jenkins plugin is used.  http://qualityhour.wordpress.com/2012/06/14/continuous-integration-with-jenkins-and-launchpad/
<bac> benji: i think you can just remove the CSS rule from huwshimi's makefile.  the css is all static now.
<benji> bac: he's looking at it; I figured he would know what was up better than I
<adeuring> bac: the challenge with this APU call is to figure out what information is relevant. And perhaps also, _if_ this URL provides relevant information...
<huwshimi> bac: No problems at all!
<huwshimi> benji: I've got caught up here a bit. I think you can probably remove any/all css rules there, but I was going to grab Rick to make sure I wasn't breaking anything, but he's caught up with something now.
<benji> huwshimi: ok, I'll take a look
<adeuring> bac: ah, i misunderstood your question. I thought you refered to email. Yes, the pending MP should fix some problems that occur even when the ES server is "stable".
<jcastro> hey gary_poster 
<jcastro> I found an interesting thing
<jcastro> https://chinstrap.canonical.com/~liam/cassandra-setup.jpeg
<jcastro> I asked the guys in IS to make me a diagram on how we do cassandra for a blog post
<jcastro> and this is what they came up with
<jcastro> but like the GUI doesn't show units and relationships together, so the diagram looks rather lame in comparison
<jcastro> I know we don't really target "make it look impressive when there's a ton of units" as a use case
<jcastro> but I thought I'd point it out
<Makyo> hatch, https://codereview.appspot.com/13515044
<Makyo> jujugui Review please for flagging a service as charm_changed https://codereview.appspot.com/13560043/
<gary_poster> jcastro, hey. Fair enough. :-)  Yeah, I don't expect we'll get a unit view any time soon.
<bac> sinzui: now that staging is up and happy, i'd like to get production on the same rev 381.  anything i should know besides just following your google doc?
<sinzui> bac: Nothing special today
<bac> okey doke, off to file an rt
<sinzui> bac: I ponder making staging again at EOD because I think we want to use a floating IP. I will also need to land a branch to make migration 18 safe for fresh deploys.
<huwshimi> benji: Did you have any luck with the makefile?
<benji> huwshimi: yep, tests running now
<huwshimi> benji: Great!
<benji> huwshimi: tests passed
<benji> I'm going to try to get this up on Rietveld now.
<huwshimi> benji: Have fun!
<huwshimi> benji: I think 10,000 lines of that review are removing bootstrap, so it's not as bad as it seems.
<bac> benji: are you going to be able to get to my bundle-icon branch or should i ask an orangish person?
<benji> bac: oh, I didn't know it was ready.  I asked for you to tell me where it was when it was ready.
 * benji looks at the backscroll to see if he missed something.
<bac> benji: yeah, it's been ready.  sorry i didn't give you an url...its in the normal spot
<bac> benji: https://code.launchpad.net/%7Ejuju-jitsu/charmworld/trunk/+activereviews
<benji> thanks
<bac> benji: only 244 lines of that are code, the rest svg
<benji> cool, looking now
<Makyo> jujugui https://codereview.appspot.com/13566044 quick review please, I broke zooming :(
<benji> bac: the branch looks good
<bac> thanks
<benji> bac: I added a card for the docstringageddon
<bac> benji: great.  we're much better at making cards than finishing them.  :(
 * bac points finger at self
<benji> heh
<bac> benji: no call today, right?
<benji> as far as I know
<bac> nice.  /me -> lunch
<Makyo> jujugui quick fix for services appearing to jump on drag https://codereview.appspot.com/13547045
<benji> Makyo: I did a review (no QA)
<bac> hi sinzui, fyi production has been updated https://pastebin.canonical.com/96998/
<bac> we should have a charm icon contest.  i vote bip for most engaging.  http://manage.jujucharms.com/charms/precise/bip
<bac> hi benji, there is a problem with your makefile for the run target.  es_update instead of es-update.  i've fixed it in my branch.
<benji> bac: ooh, thanks; I'll sneak a quick change into trunk
<bac> benji: something is clearing out my local db between runs.  could it be a change to the makefile?
<bac> benji: could be an undesired behavior in production.
<benji> bac: I don't see how.  
<benji> bac: between runs i.e., "make run"?
<bac> benji: perhaps 'make test' / 'make run' cycles.
<bac> benji: a mostly mechanical change: https://code.launchpad.net/~bac/charmworld/singularize-bundle/+merge/184181
<benji> bac: I'll take a look.  Re. db clearage: I just did a "make run" and checked that the apache charm page worked, did a "make test" (the tests passed), and then another "make run" and the apache page was still working
<bac> thanks for the review benji
<benji> my pleasure
<bac> benji: it is ES that is getting blown away.  do a run / test / run and then do a search for 'precise'
<bac> benji: i wonder if it is es-update.  it sure takes a long time now
 * bac dogs walk
<benji> bac: yep, I think I have the same thing happening, all searches return no results
#juju-gui 2013-09-06
<Makyo> rick_h, https://codereview.appspot.com/13560043/
<rick_h> jujugui small tiny review and qa please https://codereview.appspot.com/13289049
<Makyo> rick_h, https://gist.github.com/makyo/6461440
<raywang>  hi, does anyone know how to change juju gui's admin password?
<rick_h> raywang: it's the environment admin password
<rick_h> raywang: if you change that in your environments.yaml it'll change in the gui
<raywang> rick_h, yeah, i know, but i need to change it :)
<raywang> rick_h, but i already have a running env deployed by juju
<rick_h> raywang: :( talking here souds like your out of luck 
<rick_h> raywang: if you change the admin password in the environment.yaml I'l told you have to re-deploy the environment
<rick_h> I'l means I'm
<raywang> rick_h, well, user sometimes need to change the password then. it's necessary to have this functionality :)
<rick_h> raywang: yea, so there's work to be done to support multiple users down the road and that might do what you want
<raywang> rick_h, agreed :)
<rick_h> but right now, there's not a way we know of to change the admin password for the environment 
<rick_h> without the reploy your environment story. 
<raywang> rick_h, ok, thanks for the information :)
<rick_h> sorry I don't have better news
<raywang> np :)
<Makyo> hatch, rewrite core in node pls
<rick_h> jujugui another tiny review please, and QA as well https://codereview.appspot.com/13588043 with an easy QA of "get up a ghost to deploy a charm"
<bcsaller> https://codereview.appspot.com/13418046/ has the proposed databinding reset support gary wants
<benji> bcsaller: do you need a review?
<bcsaller> benji: that would be great
<benji> will do
<bcsaller> benji: thanks for the review
<benji> my pleasure
<bac> morning
<rick_h> morning
<frankban> guihelp: https://codereview.appspot.com/13358045
<bac> frankban: i'll do it
<Makyo> frankban, I'll get the other.
<frankban> thanks bac and Makyo 
<bac> hi frankban, i'm attempting to do qa on your landscape link branch.  how do i get a unit to show the link?
<frankban> bac: using improv --landscape, but do that only if you are very interested, Matyhew already did QA.
<bac> frankban: ok
<frankban> bac: thanks
<sinzui> orangesquad, bac, benji: Does anyone have a few minutes to review the migration 18 fix: https://code.launchpad.net/~sinzui/charmworld/migrate-new-index/+merge/184292
<benji> sinzui: sure
<bac> rick_h: is the charmbrowser letter-spacing scrunchiness a known issue?
<rick_h> bac: yes, we're looking at it. It seems to be due to r1015 and trying to verify that's true and if so figure out what it did
<bac> okey doke
<bac> rick_h: tip:  look for "scrunchy: true" in the css and turn it back off.
<rick_h> bac :)
<rick_h> jcsackett: ping, don't land you brnach please
<rick_h> I'm working on updating the charm token to make the result of that suck less
<benji> sinzui: Looks good.
<sinzui> thank you benji
<sinzui> abentley, you can use https://code.launchpad.net/~sinzui/charmworld/migrate-new-index/+merge/184292 for testing jenkins integration
<abentley> sinzui: It's not approved yet.  My scripts are supposed to trigger when status is approved.
<abentley> sinzui: Or were you inviting me to approve at my leisure?
<Makyo> hatch, https://codereview.appspot.com/13527048/diff/7001/app/widgets/charm-token.js
<rick_h> bac: problem identified, update coming
<Makyo> bac, +1
<jcsackett> rick_h: ok, in standup, can you talk at 10?
<rick_h> jcsackett: sure thing
<Makyo> jamie___, http://comingsoon.jujucharms.com/:flags:/upgradeCharm/
<hatch> bac, I need frankban's branch so I'm going to go do that review
<bac> hatch: don't.  i did it just forgot to send
<hatch> oh haha ok then :) thanks!
<bac> done
<rick_h> jcsackett: so I'll land that filter branch. Hit a token update blocker in that the related api doesn't provide the owner/series info in the call so I can't fill out those tokens
<bac> hi huwshimi, will you be landing your charmworld restyling branch soonish?
<huwshimi> bac: I would like to. I need to fix up the makefile and make a couple of simple changes and then I'll try and land it. I'll get to that in half an hour or so.
<bac> huwshimi: ok.  i think i'll start my work using your current version as a pre-requisite branch
<bac> i need to add some stuff to bundle.pt and don't want to fuss with the old nasty one
<huwshimi> bac: Great. Remember that the make won't work yet though.
<bac> rt
<bac> huwshimi: theme.css has gone away, right?  if so, could you update .bzrignore and hacking.rst to remove mentions?
<huwshimi> bac: OK will do.
<bac> huwshimi: i'm adding some comments to your merge proposal.  if you want to defer the one about the 'readme' section feel free.
<huwshimi> bac: OK thanks I'll take a look
<bac> rick_h: will gary be around later?
<rick_h> bac: no idea tbh. I'd imagine, but they're in mgt stuff atm
<rick_h> jujugui review time please https://codereview.appspot.com/13239049
<jcsackett> rick_h: looking.
<jcsackett> rick_h: we don't need shouldShowIcon anymore?
<benji> bac: I have a small branch up for review: https://code.launchpad.net/~benji/charmworld/fetch-bundle-head-via-api/+merge/184329
<bac> benji: ok.  will look in a bit
<benji> thanks
<jcsackett> rick_h: nm, found where it was added back in.
<bac> benji: what would you think about making bin/test (possibly moved) a static file so we could more easily make it smarter?  i'd like something like 'bin/test -d' as shorthand for specifying all the pdb stuff.
<benji> bac: sounds good to me; the main reason it isn't static now is that I preserved the use of $(INI), but that really looks like unnecessary indirection to me
<benji> (unless the charm overrides it to set its own INI file, in which case we need a honkin' big comment at the top of the Makefile)
<bac> benji: you are the slayer of unnecessary indirection
<benji> next time I do fantasy LARPing that'll be my name
<bac> benji: avatar?  https://plus.google.com/photos?pid=5920530088824285986&oid=117034961047606128906
<benji> lol
<rick_h> jcsackett: yea, ordered those because it was annoying me :)
<rick_h> jcsackett: thanks for looking
<benji> that's a cool photo of a cool statue
<rick_h> jcsackett: ping, so did the text move under the icon in your note there?
<benji> I like how you maintained context by including the graves in the bottom of the frame, it makes the picture unfold like a story
<jcsackett> rick_h: no, the text is aligned with itself, to the left; the whole text block now looks a little unbalanced on the small size b/c text is aligned with icon at the top but no at the bottom. like i said, it's not wrong, it just looks weird to me.
<rick_h> jcsackett: ok cool yea that's signed off by UX and 'as designed'
<rick_h> jcsackett: thanks, just wasn't sure if I was reading it right
<rick_h> jcsackett: so submitting my branch now, your branch can go after that
<jcsackett> rick_h: no problem. i thought it was probably intended, which was why i said it's not a block.
<rick_h> jcsackett: let me know if you don't get to it and I'll submit it later
<jcsackett> rick_h: awesome, thanks.
<rick_h> jcsackett: all done
<benji> bac: I have a few free minutes, do you want me to work on the staticification of bin/test or do you already have something started?
<bac> benji: i have not started
<benji> k
<bac> benji: fyi, i've just made quote/unquote_yaml idempotent.  it was previously modifying in place but then return results leading to confusion.
<benji> sounds good
<benji> that's one of the things I don't like much about mutable datastructures; it's easy to fall into that kind of trap
<bac> benji: yeah.  best to pick your poison but not do both
<benji> yep
<bac> benji: we're not having a call, i assume? if not, i'm going to lunch at the top of the hour
<bac> oi, should do your review first
<benji> nope, no call as far as I am aware
 * benji notices that (on QWERTY keyboards) "aware" is typed with only the left hand.
<bac> benji: did
<benji> thanks
<bac> benji: consider:  tesseradecades, aftercataracts, and sweaterdresses
<bac> is there nothing wikipedia doesn't know?
<benji> does wikipedia know if there is anything wikipedia doesn't know?
<huwshimi> bac: Not going to get to that branch today :(
<sinzui> jcsackett, Can you check you email and help with a test I outlined?
<jcastro> hey rick_h 
<jcastro> since the keyboard on HN thing worked
<jcastro> how about submitting a juju one for me?
<jcsackett> sinzui: checking now; sorry for the delay, i was lunching.
<sinzui> jcsackett, np, we need to eat
 * sinzui needs to eat less often though
<jcsackett> sinzui: bootstrapping now. 
<jcsackett> sinzui: i verify both seeing desert in the nova list and the pem.
<sinzui> ^ abentley the gremlins are in your setup
<abentley> sinzui: I am seeing if this fixes it: http://askubuntu.com/questions/327177/cannot-bootstrap-due-to-precise-images-in-regionone-with-arches-amd64-i386
<sinzui> abentley, jcsackett, I get the expected CA in environment configuration since jcsackett did not send me the certs. 
<sinzui> abentley, oh, that implies you are not seeing canonistack properly. It does have.
<abentley> sinzui: it does have what?
<sinzui> abentley, canonistack does have the simple streams metadata. I was able to select an image based on the defaults in the env and via constraints.
<sinzui> abentley, I am somewhat stumped at the moment. I will do some searching too
<sinzui> jcsackett,  bac: what version of juju do you have?
<bac> sinzui: for juju-core i build my own
<jcsackett> sinzui: 1.13.3~raring-amd64
<sinzui> okay. We might need to keep our versions close. abentley just upgrades from 1.12. I suppose bac will tell us if he breaks
<benji> bac: I couldn't discern quite what it was you wanted to do to the script so I just made it static so it is easier to manage (but in scripts/ instead of bin/ because making bin/ a mixture of generated and static files would have been a pain): https://code.launchpad.net/~benji/charmworld/static-bin-test/+merge/184359
<bac> benji: i was thinking having it take a simple argument like '-d'  and then turn on all of the pdb stuff
<benji> bac: what constitutes pdb stuff?
<benji> (and nosetest already has a -d)
<bac> benji: the extra goo inserted for 'make testdebug'
 * benji looks
<bac> benji: is it superfluous?
<benji> nope, not really superfluous, I guess the desire is motivated by the zope.testrunner's -D flag which acts like a combination of --pdb and --pdb-failures
<benji> bac: I'd say we add --with-id unconditionally and expand --pdb into both --pdb and --pdb-failures; how's that sound?
<bac> good
<bac> as long as there is no downside to --with-id unconditionally
<benji> I can't see one.  The nice upside is that --failed will re-run only tests that failed the last run even if you forgot to run with --with-id
<benji> bac: how about it now https://code.launchpad.net/~benji/charmworld/static-bin-test/+merge/184359
<bac> benji: i'm glad you wrote line 38 and not me
<bac> benji: done.  nice.  thanks.
<benji> heh
<benji> bac: I started early and took a short lunch because I need to run some errands this afternoon.  If there is anything more I can do for you today, I need to do it soon. ;)
<bac> benji: i'm trying to finish up a branch but won't do it in time
<benji> bac: no worries, I'll catch you on the flipside
<bac> benji: have a good weekend
<benji> thanks, you too
<rick_h> jcastro: just back, what's going on?
#juju-gui 2014-09-01
<urulama-afk> mhilton: hi there
<mhilton> oh hello
<frankban> urulama-afk: morning
<frankban> mhilton: morning and welcome!
<mhilton> Hi and thanks.
<frankban> urulama-afk: are you still reviewing the branch?
<urulama-afk> frankban: i'm actually out today
<frankban> urulama-afk: IC, ok!
<frankban> mhilton: since urulama-afk is out, feel free to ping me for any question.
<frankban> urulama-afk: do you know if Roger handed off his current extra-info branch?
<rick_h_> morning party people
<rick_h_> mhilton...doh left
<rick_h_> oh the email, it burns!
<frankban> rick_h_: morning
 * frankban lunches
<rick_h_> with that I run to make up some breakfast and coffee
<frankban> guihelp: I need two review for https://codereview.appspot.com/139010043 (quickstart/trivial)
<frankban> anyone? thanks
<Makyo> frankban, on it.
<frankban> Makyo: thanks
<frankban> guihelp: I'd also need two reviews for go code at https://github.com/juju/charmstore/pull/86 , if you're available/interested, thanks!
<frankban> juju-gui call today?
<frankban> rick_h_, Makyo ^^ ?
<Makyo> frankban, it's a national holiday for US+Canada, and urulama-afk is out as well.
<frankban> Makyo: yeah I know, ok
<frankban> Makyo: thanks for the review
<rick_h_> Makyo: you're in today?
<rick_h_> frankban: yes, want to do the call and intro martin and such
<rick_h_> oh, guess I missed the call wtf
<frankban> rick_h_: there was no call, we can reschedule it
<Makyo> rick_h_, no, just heard the ping while cleaning, saw the review was quick.
<rick_h_> frankban: that's ok, guess I'm too deep in email to listen to my alarms going off anyway. 
<rick_h_> frankban: will pick up tomororw
<rick_h_> bah, tomorrow
<frankban> rick_h_: :-) sounds good
<rick_h_> frankban: ty for the QS updates
<frankban> rick_h_: thanks for the review!
<hazmat> is there a known rendering issue on gui and icons? every time i click through tabs on a charm i get flickering around the icon,  sometimes double painting
<rick_h_> hazmat: there's a bug about it and some fun trying to replicate it. 
<hazmat> http://i.imgur.com/Te0ZZhc.png
<rick_h_> hazmat: it seems to be a limited versions of chrome atm and the latest dev chrome people couldn't replicate it
<hazmat> rick_h_, also charmworld seems to have a wedged ingest
<rick_h_> hazmat: looking. I looked earlier and it seemed to be working and processing. At least the charm counts were going.
<hazmat> rick_h_, last ingest was from 8/30 per changes view but  there's at lesat a half-dozen more recent from https://code.launchpad.net/charms
<rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1358671 is the icon bug for tracking/input
<mup> Bug #1358671: Charm icons not rendering properly <juju-gui:Triaged> <https://launchpad.net/bugs/1358671>
<rick_h_> hazmat: k, looking
<hazmat> rick_h_, thanks
<rick_h_> hazmat: no vangaurd atm on charmworld, will try to catch one or get one of the AU folks tonight. (The US ones are probably on holiday today)
<rick_h_> hazmat: it does move but it's only moving one queued charm every few mins vs many per minute
<rick_h_> hazmat: so guesssing a pipe is clogged somewhere. Will have to get logs and IS help
 * rick_h_ does an EOD dance and steps away
<huwshimi> Morning
<rick_h_> morning huwshimi 
<huwshimi> rick_h_: Hey
#juju-gui 2014-09-02
<rick_h_> morning all
<frankban> morning rick_h_ 
 * frankban lunches
<rick_h_> frankban: did you take a peek at the updates to the charm from hazmat? Can those be landed? (around the proxy settings)
<frankban> rick_h_: yes I reviewed the branch. hazmat mentioned he want to wait for further live tests/qa before landing those. I assured my availability to do a charm release after those changes are landed
<rick_h_> frankban: ah ok, missed the waiting stuff. I added a card to tracking on that for now thanks
<frankban> rick_h_: thanks
<hazmat> frankban, there are some fixes post the initial pull request, let me update
<hazmat> nevermind there in the merge proposal
<hazmat> frankban, should i go ahead and just merge to  lp:~juju-gui/charms/trusty/juju-gui/trunk ?
<hazmat> or do you want a separate mp targeting that branch first
<frankban> hazmat: please go ahead and merge it into the dev branch, I'll work on a charm release in the afternoon
<hazmat> ugh.. i forget how slow bzr is ;-)
<frankban> heh, the charm repo is pretty big also
<rick_h_> luca: do you have hover over info for https://bugs.launchpad.net/juju-gui/+bug/1360169 
<mup> Bug #1360169: Hover overs are missing from most of the interface <juju-gui:Triaged> <https://launchpad.net/bugs/1360169>
<rick_h_> luca__: oh, guess this was going on yesterday, it got caught up in my email backlog and seemed longer than that
<hazmat> frankban, done
<frankban> hazmat: thanks
<rick_h_> frankban: after that gui charm release feel like helping wrap up MV this week?
<frankban> rick_h_: sure no problem
<rick_h_> frankban: awesome
<rick_h_> hazmat: charmworld seems chugging along happier today. Is your stuff all set?
<hazmat> rick_h_, yup. all good, thanks
<frankban> hazmat: charm released
<hazmat> frankban, danke
<hazmat> er. grazie ;-)
<frankban> :-)
<hatch> yaaaaaaawwwwnnnnn
<hatch> morning all
<urulama> good morning, hatch :)
<rick_h_> morn
<hatch> so glad to be back at work...needed a break from the holiday haha
<rick_h_> frankban: hatch up for a pre-standup chat?
<kadams54> hatch: per your comment on PR#523â¦ can you point me to the HTML for the boolean checkboxes? I found some style rules for .config-field.boolean in juju-inspector.less, but am failing to find the corresponding HTML.
<hatch> rick_h_: frankban sure just lemme grab my coffee, 2 mins
<frankban> rick_h_: sure
<rick_h_> frankban: hatch ok, meet you in the standup room
<hatch__> rick_h_:  technical difficulties, trying again
<hatch__> kadams54: service-configuration.partial or something
<kadams54> Thanks, I did look at that but wasn't 100% sure it was the right place. I'll comment further on the PR.
<rick_h_> jujugui call in 2
<rick_h_> jujugui kanban away please
<hatch> lol
<hatch> what's martins nick?
<rick_h_> mhilton and he's not in here atm
<hatch> ahh ok I see in the other channel 
<hatch> kadams54:  is there a website somewhere which outlines 'why' your approach works? I think my feelings will be assuaged if I can read up on this technique vs the more commonly known single element one 
<hatch> the css is quite a bit more complex so I'm worried about future dev coming in and not knowing what's going on
<kadams54> hatch: http://code.stephenmorley.org/html-and-css/styling-checkboxes-and-radio-buttons/
<kadams54> Covers both approaches
<hatch> I should really look into how google does the paper elements stuff
<hatch> they have some really cool radio/checkboxes 
<kadams54> I can do some digging into thatâ¦
<hatch> kadams54:  ok so how about if you just put a comment in the css with this url to explain the technique?
<kadams54> hatch: sounds good.
<kadams54> I was thinking I could also add classes to the <span>s which could also clarify their purpose.
<hatch> ahh yeah that could also help
<hatch> it is pretty cool though
<kadams54> hatch: soâ¦ paper cheats.
<kadams54> hatch: it ditches <input> all together in favor of a combination of <div>s and a <canvas>.
<hatch> animated gifs?
<kadams54> Hah, no.
<hatch> oh haha, really? 
<hatch> interesting....
<hatch> kadams54:  probably because styling inputs on mobile is le'stupid and canvas is going to be pixel perfect every time
<kadams54> hatch: https://gist.github.com/kadams54/5e52c25281b364f97b8f
<kadams54> I think they only use canvas for the ripple effect that happens when you toggle a button.
<kadams54> All the more traditional stuff is all <div>s
<kadams54> They seem to rely heavily on aria markup to make up for the lack of semantic markup.
<hatch> I think that the ripple is just layered on top of whatever it's containing
<kadams54> http://www.polymer-project.org/components/paper-radio-button/demo.html
<hatch> we should use these heh
<hatch> so pretttttyyyy
<kadams54> hatch: Yeah, the ripple is the canvas. The button itself is just two <div>s, .offRadio and .onRadio.
<kadams54> .onRadio gets a "fill" class when active.
<hatch> interesting
<hatch> well in any effect, I've +1'd it
<kadams54> I suspect the animation is just CSS transitions
<kadams54> Not sure how I feel about ditching basic HTML elements all together.
<hatch> yeah - I'm guessing that's because of mobile 
<hatch> styling input elements on mobile is really poorly supported
<kadams54> More so than on desktop?
<kadams54> I mean, we're already basically hiding the native element and then either sticking in a background image or styling some <span>s to take its place.
<kadams54> Largely because desktop browsers vary pretty widely in how (or in the case of Safari, even if) they support styling form elements.
<hatch> yeah because you have to remember that there are about 1M different browsers on android 
<hatch> and that most are complete garbage and don't get updated....ever
<kadams54> *sigh*
<hatch> it's better now with chrome on android 
<hatch> but I'm guessing that there are a lot of people who are still using the default browser
<hatch> no whatever free phone they 'bought' :P
<rick_h_> jujugui make sure you get your travel filed. I think I approved everyone that requested. If you've not please do that and let me know if you hit issues
<hatch> oh crap I forgot heh thanks
<hatch> rick_h_:  my flights when searching on flights.google changed $700 in one day 
<hatch> they went back down again
<hatch> but I was like....wth
<rick_h_> hatch: then file now :P
<hatch> lol
<rick_h_> I thought I approved yours :P
<hatch> you did, I just guessed on the price because of that
<hatch> (it's down again)
<hatch> BUY BUY BUY
<hatch> ehh but the flights suck....
<hatch> jujugui, just confirming, the airport is BRU ?
<rick_h_> mhilton: did you find the invite for leankit?
<rick_h_> mhilton: make sure to check the spam folder
 * rick_h_ finds email to make sure he didn't typo the email addr
<kadams54> jujugui: looking for a second review/QA on https://github.com/juju/juju-gui/pull/523
<kadams54> rick_h_: ready to chat about constraints when you are.
<rick_h_> kadams54: k, on the phone atm but can chat later. Not sure when this one will be over
<urulama> jujugui: bye, have fun
<rick_h_> urulama: have a good night
<rick_h_> kadams54: call is over, want to chat now or after lunch?
<kadams54> Just getting ready to grab lunch, so after?
<rick_h_> kadams54: rgr
 * rick_h_ goes to lunch
<Makyo> jujugui need some reviews and QA: https://github.com/juju/juju-gui/pull/527 (turned out way easier than I initially made it)
<kadams54> Makyo: I'll take a look
<Makyo> kadams54, thanks, will look at yours as well.
<hatch> lazyPower:  noone wants to answer your AU question :) 
<hatch> probably because the answer would suck lol
<hatch> ok reviews done, conflicts resolved.....now to qa again
<Makyo> kadams54, good catch, I should've noticed that.
<kadams54> Makyo: np
<hatch> jujugui fyi chrome's latest update adds a complex 'ssl warning' page like FF has had for a while - it's now a multi step process to dismiss 
<rick_h_> hatch: :(
<hatch> very
<hatch> jujugui in testing my branch after pulling in the latest develop changes I can no longer place a unit on a 'root container' - is this to be expected? 
<hatch> I don't recall this limitation so - bug?
<rick_h_> hatch: hmm, seems like it. Can you git biset from where you're at on that one please?
<hatch> yep on it, will report back
<rick_h_> hatch: ty much
<hatch> could have been a bad conflict resolution here as well..
<rick_h_> kadams54: back from lunch?
<kadams54> Yup
<rick_h_> kadams54: standup hangout?
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1364549
<mup> Bug #1364549: Cannot destroy services with no deployed units <juju-gui:New> <https://launchpad.net/bugs/1364549>
<kadams54> rick_h_: joining
<hatch> rick_h_:  https://bugs.launchpad.net/juju-gui/+bug/1364558
<mup> Bug #1364558: Unable to place an unplaced unit on root container <juju-gui:New> <https://launchpad.net/bugs/1364558>
<rick_h_> hatch: k thx
<rick_h_> Makyo: hatch either of you QA kadams54 branch so it can land?
<hatch> Makyo:  did according to the pr
<Makyo> Yes +1
<rick_h_> Makyo: ah, looks like you did, can you add a little more on that qa note per our friday chat the other week
<rick_h_> kadams54: and this can shipit then?
<Makyo> Ah, sure
<rick_h_> Makyo: ty much
<kadams54> rick_h_: yup
<hatch> lunching
 * rick_h_ runs away for today night all
<hatch> cya rick_h_
<hatch> jujugui lf a review and qa on https://github.com/juju/juju-gui/pull/524 plz and thanks (before something else lands and causes more conflicts :P )
<hatch> rick_h_:  any preference to my next card?
<huwshimi> Morning
<hatch> morning huwshimi
<hatch> huwshimi:  if you have some time today it would be awesome if you could review and qa https://github.com/juju/juju-gui/pull/524
<huwshimi> hatch: Sure!
<hatch> thanks - the code is pretty cryptic without the whole thing in your head so really the important parts are that it qa's properly :)
<huwshimi> hatch: OK no problems :)
<hatch> I hope we have some time after 1.0 to do some refactoring on this now that we know how it's supposed to work
<hatch> we can dramatically simplify it with a rewrite ....er....refactor.....er.....enhancement :P
<hatch> huwshimi:  also your travel should have been approved (assuming you filed for it) rick said this morning just fyi
<huwshimi> yep, just about to confirm my flight
<hatch> it's going to take me 16H
<hatch> how about you? :)
<huwshimi> 28
<huwshimi> Might be 33 on the way back
<hatch> jeesh
<hatch> huwshimi:  you must be really high up in your airliner frequent flyer program :)
<rick_h_> hatch: either one of the bugs (unable to place on a root container, add to my canvas not working in MV) or the limiting options based on provider or the ecs conflict work needed. 
<hatch> rick_h_:  the add to canvas in mv is not a bug....at least I couldn't reproduce it
<rick_h_> hatch: frankban is taking up one of the issues (limiting based on provider or ecs/conflict stuff) so might see what card is taken in the morning
<hatch> yeah that'll work
<rick_h_> hatch: so it works for you? You see unplaced units or machines start to appear?
<hatch> machines appear
<rick_h_> oh heh yea I guess it does. wtf
<hatch> I'm also not sure about the closing the inspector help text thing....what does that mean?
<rick_h_> awesome then, yay
<hatch> :)
<rick_h_> hatch: so every time you close/reopen the inspector by clicking on a service you get that help text
<rick_h_> I think that after you dismis it, it should stay dismissed
<rick_h_> I figured that's more a UX front thing that we could get huwshimi or kadams54 or someone to peek at
<hatch> sure
<hatch> one more 
<hatch> q
<rick_h_> shoot
<hatch> machines should not have roll over hover states - don't we want to allow them to drop on machines?
<hatch> I have an unplaced unit, I drop it on a machine, it asks me to create a container....etc etc etc 
<rick_h_> hatch: sure, but right now the roll overs completely hide the create machine. I was thinking that what we could do is enforce the clicking of the machine first
<huwshimi> was just about to ask the same question :)
<rick_h_> and then you can drop on root container
<rick_h_> but right now no one notices the create machine/container header because as soon as you drag you run over machines and they get bright big color changes
<rick_h_> I talked to ale/luca about it this morning and they're pondering things but we agreed to start out by trying to hide the hover grey background change
<rick_h_> at least then all options are treated equal
<rick_h_> and there's less moving bits to distract you
<hatch> hmm interesting...
<hatch> ok thanks for clearing those up :)
<rick_h_> np, happy to entertain other ideas
<hatch> I have none, I just didn't think it was an actual issue, but I see now how it could be
<huwshimi> rick_h_: Maybe could you add a few more details to the card, just so whoever picks it up knows what to do?
<rick_h_> heh, it's a case of it bugged the heck out of me in QA so I made noise to UX :P
<rick_h_> huwshimi: sure thing
#juju-gui 2014-09-03
<hatch> haha no it's fine, it makes sense 
<huwshimi> Also the card "When constraints are hidden, they still show upon selecting the machine." is that bug you're seeing or do you want it to still show for the selected machine?
<rick_h_> added
<rick_h_> huwshimi: so if you hide containts from the list, but select a machine
<rick_h_> they should show up, at least per the designs
<rick_h_> it's a bug I'm seeing currently, hiding constraints will never show them even when you select a machine token
<huwshimi> Ah yes, I understand
<huwshimi> "disable add container for anything but MAAS" is a massive, massive card
<rick_h_> huwshimi: :) well it's a few cards there, but yes. It's one of the 2 big paths this week. 
<rick_h_> that path and the ecs/data binding conflict path
<rick_h_> and then qa/polish
<rick_h_> morning party people
<jrwren> any Canary users? might want to skip updates right now. Its unstable for me.
<rick_h_> jrwren: thanks, good to now
<rick_h_> know
<hatch> jujugui I need one review (no qa needed) https://github.com/juju/juju-gui/pulls
<hatch> https://github.com/juju/juju-gui/pull/524
<kadams54> lol
<rick_h_> hatch: looking
<hatch> rick_h_:  thanks - the code is pretty cryptic without the whole picture in your head unfortunately 
<rick_h_> hatch: ok, I'll just wander around confused a bit and ask lots of questions :P
<hatch> haha
<hatch> rick_h_:  you can remove a unit from a machine?
<rick_h_> hatch: certainly
<hatch> hmm I never tested that one
<hatch> or made any changes to that...lemme see if it works
<rick_h_> hatch: yea, sec let me get the visuals on that
<hatch> hmm you can't remove uncommitted units 
<rick_h_> does this work for you? https://drive.google.com/drive/u/1/#folders/0Bzj8yHKHrx6pNkVUTkNPd3RWNTQ/0BwDPGKe0SiMbU0RfOXZIXzJlODg/0B7XG_QBXNwY1V3B3dDNvYXJGRE0/0B7XG_QBXNwY1NEtGaHJYZGM4enM/0B7XG_QBXNwY1aVh1cC0wU0JRaW8
<rick_h_> this was part of that talk around the more menu on each unit in the container view
<hatch> hmm removing a unit via the inspector also removes the host machine in sandbox
<rick_h_> yea, I can't drop another unit on the root container atm to get the two units listed and see if the more menu appears for each
<rick_h_> but I'm guessing it's nothere, but yes, you can remove a unit from a container/machine via the container view 
<rick_h_> hatch: so I'd suggest we get the root container thing fixed up so we can QA and identify any bungs around that 
<hatch> I'd really like to get this landed - it's been conflicted 3 times already :)
<rick_h_> hatch: understood :/ I guess it's progress and we need a couple of things worked on/fixed for the delete scenario
<rick_h_> hatch: ok +1 on landing with follow up card created for 'updating machine token when unit is deleted from container  view'
<hatch> yeah atm you can't delete a unit only the container
<hatch> and you can't delete the container because the unit is assigned
<hatch> hah
<rick_h_> wheee
<hatch> removing a unit via the inspector breaks the mv
<hatch> *sigh* filing a bug
<rick_h_> :/
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1364956
<mup> Bug #1364956: Removing a unit via the inspector creates a sticky remove unit command in the deployer bar <juju-gui:New> <https://launchpad.net/bugs/1364956>
<rick_h_> ty, updated
<hatch> rick_h_:  testing this stuff in a real env is really difficult because it allows us to do things that aren't supported that put things into a funky state
<hatch> like creating lxc containers in ec2 for instance
<hatch> it 'works' but then can't delete it because it can't communicate with it
<hatch> so maybe we should make sure we have the proper functionalities enabled
<hatch>  / disabled
<rick_h_> hatch: yes, agreed. frankban is working on that card now
<hatch> oh, cool
<hatch> rick_h_:  think we can get an orange box to test this on pre-release? 
<hatch> even if they just plugged it into the wall in London? :)
<rick_h_> hatch: well luca is getting one but not sure when. 
<rick_h_> hatch: but if I can get caught up I want to get my MAAS setup turned on which we could test it on
<hatch> ahh - I'm just thinking on how we can test the maas stuff
<hatch> oh alright
<rick_h_> hatch: yea, the idea is the maas setup I have at home. 
<hatch> jcsackett:  you betta today?
<rick_h_> http://maas.jujugui.org/
<rick_h_> but it's down for the count atm
<jcsackett> hatch: "better" may be overstating the case, but i'm here. :p
<hatch> jcsackett:  well then! drink lots of beer
<hatch> that's how you fix a cold right?
<jcsackett> somehow i doubt that would have the desired effect. :p
<hatch> haha
<hatch> jcsackett: your card in review, did that land already?
<hatch> and....did you want the card "unable to place a unit on a root container" it was caused by the "do not drop on deleted containers" branch 
<jcsackett> hatch: yes, it landed, and sure.
<hatch> ok cool, I'm just trying to pick my next :)
<rick_h_> jcsackett: the card there is important. If you need to run please ping and handoff. 
<rick_h_> jcsackett: and glad you're feeling able to move
<jcsackett> rick_h_: i don't anticipate crashing today, but if i feel like i'm going down for the count i'll let people know.
<rick_h_> jcsackett: ty much
<jcsackett> rick_h_: you talking about the card hatch just mentioned, or the one i'm sharing with brad at the top of the board (that's actually marked important?)
<rick_h_> jcsackett: the one hatch mentioned, though I'm eager to hear about what's up with the one you're sharing with brad. 
<jcsackett> rick_h_: i can catch you up on that now if you like, or in standup.
<rick_h_> jcsackett: all good. Is that done and have a review? 
<rick_h_> jcsackett: just waiting to land/deploy?
<jcsackett> rick_h_: needs a review from marco (who i've just pinged in eco); then charmworld itself needs updating, then deployment.
<jcsackett> the charmworld update/deploy part is a second card.
<rick_h_> jcsackett: there's no MP linked in the card external link or review tags. 
<rick_h_> what's the charmworld update needed?
<rick_h_> oh shoot I didn't send out my comment on that branch
<rick_h_> damn LP -> github differences
<jcsackett> rick_h_: i've updated the card, but to land we need review outside of this team. marco just acked.
<rick_h_> jcsackett: cool
<jcsackett> rick_h_: once charmworldlib is updated and the 0.4.2 release is made, then bac has an update to use that that i can review and land. then the deploy funtimes.
<rick_h_> ic, so the charmworld update is the dep updated
<rick_h_> jcsackett: gotcha ty for the catch up :)
<jcsackett> rick_h_: yw.
<rick_h_> jujugui it looks like a fresh utopic lxc only has python3 in it. So going to add some stuff to the board for checking on and updating quickstart and our charm. 
<rick_h_> jujugui probably first with just addingn py2 as a dep and then looking at updating from there. 
<hatch> wow that took a while....3's been out for what? 7 years? :P
<rick_h_> mhilton: thanks for the pointer there on the changes. Glad quickstart seemed to get a ways into working before it broke in py3
<rick_h_> hatch: well there's a LOT of python code to update before the distro can change the default
<rick_h_> hatch: but yea, it's been 5yr ish I think? 
<hatch> it's actually because everyone changed to node
<rick_h_> though everyone agrees py3 didn't really get usable until 3.2
<rick_h_> lmao
<hatch> so there was noone to port the code
<mhilton> rick_h_: Except it isn't python 3, at least no on my machine 
<rick_h_> mhilton: oh? I saw utopic and assumed it was a fresh-ish install with py3
<rick_h_> mhilton: ok, can you update the bug with the python version info as well please?
<rick_h_> mhilton: doh, yea the traceback shows 2.7 
<mhilton> yeah sure. I installed it just before the utopic beta came out
<rick_h_> mhilton: ok, will keep chasing after your bug there. 
<urulama> jrwren: quick hangouts?
<jrwren> urulama: yes.
<urulama> jrwren: https://plus.google.com/hangouts/_/canonical.com/jay-uros?authuser=0&hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.228npoderqhjtlfek7mqq3a0p4
<jrwren> and... chrome crashing.
<rick_h_> Makyo: your card is in review right?
<urulama> jrwren: :)
<jrwren> urulama: how I'm in this room with myself.
<urulama> jrwren: khm. do use the link from the invite then :S
 * rick_h_ heads back to the house 
<frankban> rick_h_: quickstart depends on python2, so it should be ok in utopic. I am more concerned about the versions of the websocket-client and pyjuju-client
<frankban> rick_h_: also, I am not sure about the charm vs utopic. AFAIK we only support LTS releases for the charm (so precise and trusty)
<frankban> mhilton: can you add to the bug the versions of the quickstart dependencies? e.g.  python-websocket and python-jujuclient
<hatch> luca__: I hate the container column....fix it plz :P
<hatch> maybe pictures of puppies can go there? :)
<hatch> jujugui call in 10
<rick_h_> frankban: +1, I've got a utopic lxc to tinker with and check it out. 
<luca__> hatch: what do I need to fix? :D
<hatch> luca__:  iunno it just sits there...empty....waiting...longing for someone to love it
<luca__> hatch: well, it should never be emptyâ¦let me have a look
<luca__> hatch: I think there is a bug for that somewhere
<hatch> well it's not "empty"
<hatch> but it has, say 2 containers
<hatch> and about 1000x250px of whitespace
<hatch> (if I shrink my browser) 
<luca__> hatch: well, yeah but thats because you havenât figured best pratice and nested all of your services in endless containersâ¦. :P
<hatch> hahaha
<hatch> it's not even possible!!!!
<luca__> hatch: yeah, rick_h_ told me
<hatch> sad...really
<hatch> :'(
<luca__> hatch: I think if we had known that from the start we would of come up with a different solution
<kadams54> guihelp: one thing I've noticed as I work on standardizing constraints is that we use the label "disk" in some places and "root-disk" in othersâ¦ I'd like to change it all to one label, but that may require a data migration, which I've never dealt with in juju world.
<hatch> anyways....I was just joking around, but it would be nice if something could go there - I have no idea what though 
<luca__> hatch: good thing we didnât go with the boxes model because you would of just had big boxes everywhere o.O
<luca__> hatch: Iâm +1 on the puppies
<hatch> yusssssss
<hatch> kadams54: data migration? the constraint key is root-disk isn't it?
<hatch> so the stuff which says 'disk' would just be a label 
<urulama> hatch: fluffy unicorns?
<frankban> kadams54: we don't store that data, so no migration should be involved
<luca__> urulama: haha
<hatch> urulama: can unicorns be fluffy? 
<kadams54> hatch: not everywhere. In some places it's "disk"
<luca__> hatch: we can review it very quickly in brussels :)
<hatch> I thought they were lean mean murdering machines 
<hatch> lol
<urulama> hatch, luca__: Despicable me :) http://media-cache-ec0.pinimg.com/736x/8a/5d/f5/8a5df52b9773d53c1cc6a1d7ab6a827a.jpg
<hatch> hhahahaha
<hatch> oh I love that show
<luca__> hatch: urulama https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&es_th=1&ie=UTF-8#q=fluffy%20unicorns&safe=off
<hatch> that part made me roar laughing on the plane....ppl looked at me funny
<urulama> luca__: :D :D :D
<urulama> luca__: so you're thinking about animated gifs for background, right :D
<frankban> kadams54: the name of the constraint in juju is "root-disk", we should always send that. The label we show can be either "disk" or "root-disk" and I don't have a string opinion, but I agree it should be consistent in the GUI. I remember we had a map/array storing constraints keys and labels somewhere
<rick_h_> frankban: call time
<kadams54> guihelp: Looking for reviews and QA on https://github.com/juju/juju-gui/pull/528 - there's also a TODO in that code that's sort of an open question about hardware data vs. constraints.
<frankban> kadams54: you are right, while constraints are something we request new instances to conform to, hardware characteristics are actual values (arch, mem, cpu-cores etc.) describing existing machines
<kadams54> Yeah, it just got confusing with grepping through source and test code looking for instances of "disk" that needed to be changed to "root-disk".
<kadams54> I accidentally changed a number of instances that dealt with hardware rather than constraints before I realized what was going on.
<frankban> kadams54: yeah that's unfortunate
<kadams54> Also the cpuPower vs. cpu-power just makes my obsessive-compulsive side twitch :-)
<hatch__> Makyo: do you know why https://github.com/juju/juju-gui/blob/master/app%2Fviews%2Ftopology%2Fservice.js#L1189 model here would be undefined but the bounding box still exist? 
<urulama> juju-gui: have fun, viva MV release ;)
<rick_h_> kadams54: heh, well that's thanks to pyjuju vs go juju :)
<rick_h_> uru-bot: night! :)
<Makyo> hatch, no, not quite sure why that would happen
<hatch> Makyo:  hmm ok will keep digging
<hatch> breakpoints ahoy!!!
 * rick_h_ goes to nuke up some leftover lunchables
<hatch> luca__: https://bugs.launchpad.net/juju-gui/+bug/1365053
<mup> Bug #1365053: Add units dialogue on pre deployment inspector is confusing <juju-gui:New> <https://launchpad.net/bugs/1365053>
<luca__> hatch: that is the correct behaviour. It should auto place that machine, I was going to talk to rick_h_ about it because itâs quite hard to explain.
<luca__> hatch: it should have a 1 in the input field
<hatch> ok so it is broken now?
<luca__> hatch: at the moment you can put 5 in the input field and click auto place and it will give you 5 units and youâll be left with 1 unplaced unit
<kadams54> rick_h_, hatch: Looking at the "Clicking on the inspector after closing shouldn't reset the help text" card - I remember this coming up in IRC after EOD for me.
<luca__> hatch: yeah
<luca__> hatch: the field should start with 1 unplaced unit which is the 1 listed.
<hatch> luca__:  ok but that unplaced unit is already created so we can't auto place it because they scaled up...
<hatch> that's a separate interaction
<kadams54> rick_h_, hatch: just to be sureâ¦ what this card means is the "Your service has been added. Configure using the tabs below." text, correct?
<luca__> hatch: yeah, thats the problem that Iâve been trying to think through, I think itâs worth talking through because itâs pretty complex
<hatch> luca__: I think my problem with it is that it looks like the add-unit dialogue is part of the inspector instead of a separate dialogue because it's pre-opened
<hatch> maybe just a colouring thing would fix that - make the bg lighter for that section...
<luca__> hatch: are we talking about the same bug?
<hatch> kadams54: yeah - if you click dismiss, it should stay dismissed even on subsequent openings 
<hatch> maybe? have time for a call?
<hatch> :)
<kadams54> hatch: thanks
<luca__> hatch: sure, got a link
<luca__> ?
<hatch> incoming
<hatch> rick_h_: care to joing?
<hatch> luca__:  rick_h_ https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1
<jcsackett> hatch: i was wrong, icons on the root container still seem to have some goofiness. they worked sometimes, not always.
<rick_h_> kadams54: otp atm will catch up in a sec
<kadams54> rick_h_: no worries, hatch answered my question
<rick_h_> ah cool then
<kadams54> heading out for a run, bbiab
<hatch> jcsackett:  ok we can investigate once your fix has landed - there appears to be a unit data race condition 
<hatch> I created a bug.....
<jcsackett> wheee
<hatch> umm looking
<hatch> ahh I can't find it
<hatch> anyways when you visit a /machine url it causes bustedness
<hatch> https://bugs.launchpad.net/juju-gui/+bug/1364622
<mup> Bug #1364622: Hardware information never becomes available when creating new machines on ec2 <juju-gui:New> <https://launchpad.net/bugs/1364622>
<hatch> ^ jcsackett I think this is a symptom of the same issue
<frankban> hatch: what's the best way to wait for an event (e.g. an attribute change) before proceeding with the function in YUI?
<hatch> frankban: it depends what you have access too
<hatch> do you have the model?
<hatch> or the class with the attribute on it?
<hatch> if so...
<hatch> myClass.on('fooattrChange', function(e) { ... } );
<hatch> where "fooattr" is what your attribute is called
<frankban> hatch: yes, but that's asynchronous
<hatch> I think I need more context
<hatch> call?
<hatch> standup?
<rick_h_> frankban: can you noop if the function isn't passed the change event object? just verify it's bound or whatever?
<hatch> frankban: rick_h_ I'm in the standup room
<frankban> rick_h_, hatch: I am in a view initializer, and I can't proceed until a specific value is set to model attribute I have access to. So I have two options: 1) look at all the places the view is created and put the view instantiation in a callback (reacting to an event) or 2) sync wait without doing nothing in some way
<rick_h_> frankban: so I'd init the view, do what can be done, and setup a watch on the model for the value if it doesn't exist yet
<frankban> rick_h_, hatch: to be clear, we have to wait for juju-core response to EnvironmentInfo before being able to use the machine view, because only at that time we know what containers are supported
<hatch> joining the call?
<rick_h_> frankban: ok, so I'd go with a default of disabled, and only open it up once we had a value?
<hatch> yeah that
<rick_h_> the hope being that by the time the user deploys something, or goes through and creates a machine it would be done/back
<frankban> rick_h_: so, the machine view is disable until we have the value? what if the user reload the machine view? should we redirect to the service view?
<rick_h_> not MV but just the add container buttons
<rick_h_> frankban: the only thing we're trying to protect the user from doing is trying to create a container only to get an error or broken state back from juju. 
<hatch> frankban:  you can create a flag in the mv which says "enable container stuffs" on load it checks that flag to see if it should show it, if not, it attaches a listener for that flag to enable it in the future
<frankban> rick_h_: there are two ways to create a container: using the button and dragging a unit to an existing machine
<frankban> hatch: that's a possibility
<rick_h_> frankban: so thinking this through, we talked about having a 'featured enbaled/disabled' object
<rick_h_> frankban: and so we'd default to one that is not enabled in real environments, the create machine feature is disabled
<rick_h_> frankban: and once we got the answer of provider back from juju, we'd need to be able to notify users that the provider (and thus features enabled/disabled) has changed and update their UX accordingly
<frankban> rick_h_: I think I have a plan, the UX will change from an initial state in which the header shows something like "checking sub-containers support" to the current one or a third one stating "sub-containers not supported"
<rick_h_> frankban: oh that's interesting. I hadn't thought about expressing the 'checking' idea out to the user. 
<rick_h_> frankban: I worry about a flashing message the user can't read/get back to but we can try that out
<hatch> frankban:  how long does it take for juju to respond with support?
<frankban> rick_h_: it's just a fast request/response
<frankban> rick_h_: so I'd expect that if the user lands to the service view, he will never see the message. if he refreshes the machine view he can see the "checking" message, but I am not sure it matters if it fastly disappears
<rick_h_> frankban: sounds good to try out
<frankban> rick_h_, hatch: in theory it can still be racy, e.g.
<frankban> val = env.get('providerType')
<frankban> if(!val) {env.on('providerTypeChange', func...)}
<frankban> rick_h_, hatch: in theory the provider could be set between line 1 and 2
<hatch> no it can't
<hatch> js is still synchronous 
<hatch> the get call is synchronous, and so is the if check
<frankban> hatch: so it's asynchronous but YUI events bubbling is in the same thread, correct?
<frankban> hatch: so the event can be notified only after the current function completes, is it right?
<rick_h_> I don't think it'll pause and change stacks mid-if statement like that. 
<hatch> frankban: correct
<rick_h_> frankban: I think it's pretty safe to use
<frankban> hatch, rick_h_: good then, thank you
<hatch> something needs to yield the thread for the async loop to run
<hatch> excellent
<frankban> done for the day, have a good evening!
<rick_h_> have a good evening frankban 
<Makyo> jujugui still need one QA/review on https://github.com/juju/juju-gui/pull/527
<hatch> on it
<Makyo> Thanks
<hatch> Makyo:  one comment b4 I qa
<hatch> on the pr
<Makyo> Oh, I thought that's what remove did. I can hunt down further.
<Makyo> New to widgets.
<hatch> its' a view
<hatch> :)
<hatch> Makyo:  you can call `this.destroy()` and it'll go through it's destroy cycle
<hatch> but I thought that we kept reference to these tokens somewhere in the mv as well
<hatch> so something in the mv will need to listen for any token destroy events and then remove it from the list
<Makyo> Ah, lright.
<jcsackett> jujugui: i need two reviews on https://github.com/juju/juju-gui/pull/529
<hatch> jcsackett:  on it
<kadams54> Makyo: FYI, there's code in the MV that will remove the token from the internal cache if the corresponding entity (machine, service unit) is deleted from the DB.
<kadams54> Makyo: IIRC, there's already code to delete from the DB as part of your changes?
<Makyo> kadams54, okay, thanks. Will look into that.
<Makyo> Yes.
<kadams54> Then you can ignore hatch :-)
<Makyo> But he's so loud!
<Makyo> hatch, kadams54 I'll do a bit of research and ensure that's the case.
<hatch> :)
<kadams54> Yeah, shouldn't be too hard to confirm with a breakpoint
<hatch> jcsackett: one comment on pr before I qa
<kadams54> Makyo: look at _removeUnit (called from _onUnitRemove) in machine-view-panel.js, line 401
<jcsackett> hatch: given that parentId === selected when you drop on the container header as well, i think i prefer the explicit toggle.
<kadams54> Makyo: it looks like it calls a destroy on the token in addition to removing it from the internal cache. This is all triggered on a DB delete, as setup on line 147.
<hatch> ok good point
<hatch> qa'ing now
<kadams54> Makyo: So I think you can also ignore hatch's comment in the PR :-)
<kadams54> Makyo: I think the only places it needs to be removed from are the ECS and the DB.
<hatch> Makyo: kadams54 in that case, the remove() call can be removed and a comment added to say where/what is happening
<Makyo> Yep, checking that now.
<kadams54> jcsackett: I'll do the second review/QA on your PR
<jcsackett> kadams54: awesome, thanks.
<jcsackett> kadams54: you need reviewers for your PR, yes?
<kadams54> jcsackett: correct
<jcsackett> on it.
<Makyo> hatch, kadams54 PR updated with comment
<hatch> Makyo:  looks good, qa'ing
<hatch> Makyo: qa issue added to the pr
<Makyo> Ah hell.
<Makyo> I thought that was managed by databinding.
<Makyo> I knew this branch was too easy.
<hatch> Makyo:  hah sorry - I didn't do that stuff in the inspector, I too thought it was databound
<kadams54> guihelp: in order to make sure the help text stays dismissed, my first inclination is to use a cookie. That said, there doesn't seem to be much else in the app that is cookie-based, so not sure if that's a bad sign or if I'm just blazing new territory :-)
<kadams54> On second pass, I may add a 'dismissed' class instead, but I'm still curious about the lack of cookies.
<jcsackett> kadams54: qa notes on your PR.
<kadams54> jcsackett: thanks
<Makyo> kadams54, don't we use cookies for hiding onboarding?
<kadams54> Makyo: the only onboarding I've worked on is hidden/shown depending on the number of machines, not any express user preference.
<kadams54> But the "Getting to Know You" onboarding might be a good place to look at.
<Makyo> Oh, that was in local storage.  There's an onboarding key and a force-onboarding key.
<hatch> kadams54:  set a flag on the model for the service
<hatch> inspector to model is a 1:1 relationship so it's the best place to put it
<hatch> and really easy to implement :)
<rick_h_> jcsackett: got a sec to chat?
<jcsackett> rick_h_: sure, just a moment.
<jcsackett> standup room?
<rick_h_> hatch: kadams54 what about just showing it on ghost/first run and not on any others?
<rick_h_> hatch: kadams54 is there any way to tell a first auto launch from a 'I clicked on a service block' to launch the inspector?
<rick_h_> hatch: kadams54 so it's more done off of the 'how' it was accessed vs tracking 'have you been seen before' kind of thing?
<hatch> rick_h_:  yep there is
<hatch> that's a good idea 
<hatch> reaaal easy to implement heh
<rick_h_> tracking a flag on a model makes me :( at first glance
<rick_h_> heh cool
<jcsackett> rick_h_: i'm in the standup room.
<rick_h_> jcsackett: joining
<marcoceppi> rick_h_: hey, if a bundle doesn't have specific versioned charm will the store injest it?
<marcoceppi> ingest*
<marcoceppi> in a personal branch
<rick_h_> marcoceppi: yes, I think it should
<marcoceppi> cool
<rick_h_> marcoceppi: if proof doens't show an E then it should be good
<marcoceppi> rick_h_: awesome,t hanks
<hatch> oo new humble bundle is a star trek comic book one https://www.humblebundle.com/books
 * rick_h_ runs away for the day. I'll be back online later at coffee house time. 
<hatch> marcoceppi:  new review queue looks awesome - but why such a funky url? Shoudln't it be on jujucharms or juju.u.com?
<hatch> cya rick_h_
<hatch> jujugui anyone know how to force destroy a machine using local?
<marcoceppi> hatch: it's not prime time yet
<marcoceppi> hatch: we'll have it so the current url maps here, until then it's a "Google beta"
<hatch> ahhh haha :) 
<hatch> I have a problem with my ghost charm on jujucharms.com but I can look into that later I suppose
<hatch> it shows ghost-0 even though it definitely shoudln't be 0
<hatch> blarg I can't reliably reproduce this issue
<hatch> laptop sounds like it's going to take off.....realize I have 15 lxc instances running 
<hatch> oops....:)
<hatch> MOAR CONTAINERS!!!
<jrwren_> it sounds light until I remember that is 15 juju's running.  No shared memory :(
<hatch> haha 
<hatch> intermittent race condition errors are da-best-yo
<rick_h_> jujugui https://github.com/blog/1884-introducing-split-diffs let there be light
<kadams54> Nice
<hatch> rick_h_:  welcome to an hour ago https://twitter.com/FromAnEgg/status/507263886165573632
<hatch> pssshhhttt
<rick_h_> doh :P
<hatch> lol!!
<rick_h_> hey, I was chopping tomatos for tacos :P
<kadams54> It's Taco Tuesday!
<kadams54> On a Wednesday.
<rick_h_> woot!
<rick_h_> oh this is so nice
<hatch> yeah what took them so long hah
<rick_h_> no kidding, works much smoother than the extension as well
<rick_h_> the comment buttons always got messed up, I gave up on the chrome extension
<jcsackett> the ff extension just didn't work.
<hatch> yeah same
<jcsackett> rick_h_: does charmworld have a landing bot?
<jcsackett> been so long since i've touched it i forgot how charmworlds review/land process looks, and i'm trying to marshal along brad's branch.
<jcsackett> guihelp: ^
<hatch> noooo idea
<jcsackett> suddenly thinking this is a rietveld/lbox show.
<jcsackett> b/c why have two websites to review code on when you can have three?
<hatch> lol
<huwshimi> Morning
<hatch> morning huwshimi
<rick_h_> huwshimi: morning
<rick_h_> huwshimi: we talked about putting off the size sort for now until we can get constraints in order and better define it
<rick_h_> huwshimi: does that unblock your branch from moving foward and landing?
<huwshimi> rick_h_: Ah yes, that's great
<hatch> wow I just got an ec2 capacity not available warning when trying to bootstrap
<rick_h_> hatch: whoops
<hatch> I'm doing a dry run of getting my blog transfered to ghost 
<hatch> mysql charm won't deploy on trusty though
<hatch> not sure what's up with that...
<hatch> hoping that it's a lxc issue with mysql and not a mysql charm issue
<rick_h_> I've seen some chatter around that
<rick_h_> check the juju irc log, public #juju
<hatch> I'm not sure where those are kept :)
<huwshimi> hatch: Hey, if you have a chance would you mind having a look at my updated code and my comments? https://github.com/juju/juju-gui/pull/526
<hatch> huwshimi: sure, on it
<huwshimi> hatch: Thankyou!
<rick_h_> and then hatch should get out of here :P
<hatch> haha I'm multi tasking, waiting for env's to spin up for ghost blog work
<rick_h_> ah ok
<rick_h_> still
<rick_h_> got to be dinner time there soon
<hatch> yeah we're going out for supper so waiting a bit for the rush to be over
<rick_h_> party
<hatch> I don't wait for restaurants
<rick_h_> big day tomorrow, new Moto X :) and the moto 360. You going to watch hatch ?
<hatch> whaaaa
<hatch> how did i miss this?
<rick_h_> oh yea man, tomorrow is Motorola day, new phones and watch 
<hatch> oooo 
<hatch> definitely going to check that out
<rick_h_> the one from asus looks cool
<rick_h_> will want to check that out as well
<rick_h_> I'm hoping to get my motox with the wood backing this time
<hatch> I just hope their phones aren't like 6" like the new samsungs (and even the new htc one)
<hatch> even the m7 htc 1 was large
<hatch> was/is :)
<rick_h_> They're saying 5.0" :(
<rick_h_> I like my 4.5 or 4.7 
<rick_h_> 5+ is getting too big imo, but I love the motox. The voice stuff, auto detecting meetings/etc
<hatch> yeah - as long as the outside dimensions of the phone don't exceed 5-3/8" x 2-3/4"
<hatch> (see I used inches for you) :P
<rick_h_> lol
<hatch> those are the dimensions of my m7 which is as big as I want to go
<hatch> it's a little too big 
<hatch> huwshimi:  code looks good
<huwshimi> hatch: I still have to remove the size option
<hatch> rick_h_:  we should investigate the D&D issue in chrome/ubuntu before mv1 release....it's a real bummer 
<hatch> not horrible I suppose, but sucks heh
<huwshimi> hatch: Happy for me to shipit after I do that then?
<hatch> yep
<huwshimi> yay
<hatch> huwshimi:  do you like the changes? 
<hatch> I think they are nicer
<huwshimi> hatch: Yeah, I think so, especially having the sorting on the model
<hatch> yeah
#juju-gui 2014-09-04
<hatch> man actually using the gui allows you to find so many bugs
<hatch> haha
<hatch> huwshimi:  if you're confused at all about what to include in the sort just leave it out, you can always add it in later
<hatch> would just love to get this landed
<hatch> ermahgerd this is frustrating
<hatch> rick_h_:  charmworld MUST have an 'original source' and 'bug url' field so that we can display them in the charm details page
<rick_h_> hatch: sure it does
<rick_h_> there's a bug and source link in the gui
<hatch> and the 'commit to this charm' link needs to be removed asap
<hatch> because it takes you to a 'how to commit to a charm' link but not to the real page in question
<rick_h_> commit to this charm?
<rick_h_> the contribute link that goes to the author docs?
<hatch> yeah
<hatch> sorry contribute 
<hatch> I can't contribute to the charm via that link
<rick_h_> ok, maybe https://juju.ubuntu.com/docs/authors-charm-store.html#submitting-a-fix-to-an-existing-charm
<rick_h_> is the better link, but not sure 'needs to be removed asap'
<hatch> yeah except that doesn't work - using the information provided in the gui we can't even get to the charm source
<hatch> all we get is "cs:precise/mysql" (for example)
<rick_h_> there's a link on the header called "source" that takes you straight to bzr
<hatch> that's all the user is left to work with
<hatch> right, but that's only if you haven't deployed yet
<hatch> if you're viewing it from the inspector you have no information like that
<rick_h_> ok, well we'll be doing better with full data in the new charmstore but nothing we can do for that. 
<rick_h_> the info isn't in the charm, when you deploy the charm is copied with no sense of where it came from
<rick_h_> we're making that better with the other stuff
 * hatch is frustrated that none of the promoted mysql charms work
<rick_h_> hatch: did you try out with more memory like sinzui mentioned?
<hatch> 8GB's of them :)
<hatch> same error
<rick_h_> hatch: go walk away man
<rick_h_> hatch: all good for today
<hatch> bug filed https://bugs.launchpad.net/charms/+source/mysql/+bug/1365205 NOW it's time to get off
<mup> Bug #1365205: Charm cannot be deployed, fails on install hook with gpg error <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1365205>
<hatch> hah
<hatch> :)
<hatch> lazyPower: hey yes I have filed a bug ^
<hatch> huwshimi:  hey need anything before I take off?
<huwshimi> hatch: I think I'm all good. Thanks Jeff
<hatch> huwshimi:  sounds good, np
<rick_h_> morning party people
<hazmat> rick_h_, g'morning
<rick_h_> hazmat: party
<hazmat> rick_h_, time
<rick_h_> frankban: once your branch is up for review, can you take a look at updating the quickstart beta ppa with the latest releases of deployers/juju client? 
<rick_h_> frankban: and then have those copied over to the juju stable ppa once we're cool with the updates?
<rick_h_> frankban: jujuclient 0.18.4 juju-deployer 0.4.0  python-websocket-client 0.18.0
<frankban> rick_h_: sure, are those versions included in the trusty and utopic repos?
<rick_h_> frankban: so hazmat is working on getting them into utopic
<rick_h_> frankban: so we'll track that work and try to make sure we get QS updated with those deps if they get in ok
<rick_h_> frankban: no trusty afaik
<frankban> rick_h_: ok I'll take a look. In theory we want quickstart to be installed without the PPA in both trusy and utopic, and so, if they have different versions of the dependencies, we need to support both in some way. anyway, when the packages are in utopic is really easy to backport those and put them in the PPA
<rick_h_> frankban: right, I figure if we update our ppa, and then get them into the juju stable ppa, then we can request an update to utopic across the board pretty easily
<rick_h_> trusty won't get updated on either end. We're not going to be able to update trusty anymore without a major bug/etc I think.
<frankban> rick_h_: ok
<jcastro> hey luca___
<jcastro> wrt the website
<jcastro> https://bugs.launchpad.net/juju-website
<luca___> jcastro: heya
<jcsackett> rick_h_: charmworld landings are all done through lbox still, right?
<jcastro> I forgot we had bugs filed on it in one place
<jcastro> might help with cleanup
<luca___> jcastro: brilliant, I will take a look
<luca___> jcastro: are there any other pages that can be killed?
<jcastro> I made you maintainer so you can actively close bugs
 * frankban lunches
<jcastro> https://juju.ubuntu.com/resources/easy-tasks-for-new-developers/ this will need an update, but not yet, you can put that page on your hitlist though
<rick_h_> jcsackett: double checking, I htink so
<rick_h_> jcsackett: yea, still has the lbox stuff in tree
<jcsackett> rick_h_: i found .lbox in the tree
<jcsackett> yeah.
<jcsackett> should've checked that first, i suppose. :p
 * jcsackett digs back into getting lbox working...
<hatch> lazyPower: hey did you see the bug I created for the mysql charm?
<lazyPower> hatch: i did. looks like a gpg key changed
<lazyPower> i haven't attempted deployment myself however. I'm a bit tied up for at least another hour. 
<lazyPower> marcocepp, mbruzeki: have you seen this behavior out of the MySQL charm before? https://bugs.launchpad.net/charms/+source/mysql/+bug/1365205
<mup> Bug #1365205: Charm cannot be deployed, fails on install hook with gpg error <mysql (Juju Charms Collection):New> <https://launchpad.net/bugs/1365205>
<hatch> ok np - I don't need it again until I start working on the ghost charm again
<hatch> but I figure it's pretty critical if a promoted charm won't deploy
<hatch> heh
<hatch> lazyPower: I also have to create my own ghost-haproxy charm :'(
<lazyPower> why do you need to create your own charm?
<hatch> the haproxy charm is pretty out dated - it doesn't support ssl (according to the readme) and I can't provide my own config values for url redirects based on a regex
<hatch> I need to redirect the old tumblr urls to the new ghost ones
<hatch> I used a lot of juju last night and found a lot of annoyances around the charm/contribution system
<lazyPower> hatch: are you documenting these pain points? All feedback is welcome.
<hatch> lazyPower:  yeah I'm going to fire an email to the canonical juju list
<hatch> tbh most of the issues revolve around the ~charmers stuff
<hatch> who's the author, where do I file bugs, how do I get in touch with the author, where is the real repo
<hatch> I'm pretty sure these fields are being added to the new charmworld stuff 
<hatch> but wow is it.....challenging :) 
<rick_h_> hatch: we've been talkig about those issues. I had a call with eco yesterday around that
<rick_h_> hatch: I'm starting a couple of UX docs around it and we can see if those help/hurt your experience
<hatch> sounds like a plan
<hatch> if it frustrates me I can't imagine some external user
<rick_h_> hatch: +1
<hatch> the haproxy charm issue is really unfortunate (not having the features I need) This is a story we need to investigate more. ATM it looks like I can 1) file a bug on lp and hope, or 2) learn haproxy enough to write my own charm
<hatch> neither are what we want thb
<hatch> we almost need a 'this charm is out of date, and missing features' button for promoted charms :) 
<hatch> but....maybe the simplest is a direct line to the charm author... "if your charm is to be promoted you must be available to be contacted by the community" <--- that's a rule I could get behind
<hatch> rick_h_:  sorry for finding more bugs last night :) 
<rick_h_> hatch: all good
<urulama> jujugui: see you all later, school time :)
<rick_h_> jujugui quick review please https://github.com/juju/juju-gui/pull/530
<hatch> on it
<rick_h_> ty much
<hatch> rick_h_:  so we don't want to remove the functionality that passes the provider data into the templates?
<rick_h_> hatch: no, it's still in the api and still in charmworld
<hatch> ahh ok 
<rick_h_> hatch: that might get updated, but for now just remove the UX, the model/data is still in the api stuff 
<rick_h_> just to clean up the UX
<hatch> sounds good, just going to qa
<rick_h_> rgr
<rick_h_> Makyo: hatch can either of you do a second review of kadams54's branch to help move that forward please?
<Makyo> Sure, on it
<rick_h_> ty Makyo 
<hatch> rick_h_:  has there been any discussion about pulling the possible instance options from the provider and then us listing them instead of just showing constraints? 
<rick_h_> hatch: huh?
<rick_h_> what are 'instance options'
<hatch> sorry totally out of context
<rick_h_> ?
<hatch> heh
<hatch> when I create machines
<hatch> it gives me three fields then picks the most appropriate
<hatch> instance type
<hatch> on ec2 for example
<rick_h_> so there are the start of 'provider constraints' and the first ones are ec2 ones that show mx3.large and such
<rick_h_> hatch: so they're getting added slowly and are provider specific and yes we want to support that and the work frankban is doing will help us with some of that I think
<rick_h_> the idea of 'features' or maybe we'll just have to match up constraints better vs a provider list
<hatch> oh cool - last night I ended up with a monster of a machine because the break point that it picked was on the 'conservative' side, instead of picking the closest 
<rick_h_> lol
<rick_h_> yea
<hatch> well as long as someone else has already thought of this :)
<rick_h_> yep, and some of the work exists, we're not caught up with it atm
<hatch> rick_h_:  there is one oddity in the inspector i noticed yesterday - exposing a service does not go through the ecs, it's a straight call to the env, is this expected? 
<rick_h_> hatch: hmm, good catch. I'm thinking. What happens if you expose an uncomitted service
<rick_h_> I'm tempted to think it's ok, but it has to work properly with an undeployed service
<hatch> yeah I never tried that...
<hatch> I'll spin up an env and give it a go
<rick_h_> hatch: ty
<hatch> jujugui call in 3
<hatch> rick_h_:  gettin' your hands dirty today I see :)
<frankban> guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/531 (GUI, big branch, sorry). anyone? thanks a lot!
<hatch> frankban: on it
<rick_h_> hatch: trying to see if I can code while on calls :)
<frankban> hatch: thanks
<hatch> frankban:  ermahgerd you wern't kidding....maybe I change my mind? :P
<frankban> hatch: heh, hopefully is readable, lots of tests btw, apologies
<hatch> rick_h_:  haha should we expect some ' if( foo == well no leankit has much better lane support than trello)  { ugh } 
<hatch> :P
<rick_h_> hatch: huh?
<hatch> typing what you're saying
<hatch> sorry that was a horrible exmaple haha
<rick_h_> lol
<rick_h_> jujuju hung up on a call, feel free to start without me once we get folks in
<rick_h_> jujugui
 * jrwren_ is singing Call Me!
<jcsackett> kadams54: there appear to be legitimate test failures on your branch. :/
<kadams54> jcsackett: yeah, I'm fixing it right now, but it's not anything that should impact QA. I need to tack 'MB' onto a string and everything will be happy again :-)
<kadams54> jujugui: browser crash, having problems getting back into the hangout nowâ¦
<jcsackett> kadams54: cool beans. i'll finish my review then.
<jcsackett> rick_h_: just double checking, we're skipping todays 1x1 since we effectively had it yesterday, right?
<rick_h_> kadams54: how goes your branch in progress
<rick_h_> jcsackett: rgr
<rick_h_> jcsackett: kadams54 has your spot now :P
<rick_h_> so many calls so little time...for lunch
<rick_h_> :)
 * jcsackett laughs
<jrwren_> hatch__: what are you doing with haproxy?
<kadams54> rick_h_: mentioned on standup before I droppedâ¦ I haven't done much on my in-progress since discussing it in channel yesterday. Circled back to fix the QA issues that jcsackett found in my other PR, but will be working on hiding the text based on your suggestion yesterday.
<hatch__> jrwren_:  my ghost charm needs a front end which does cookie sticky sessions, ssl (eventually), load balancing, and url 302 redirecting
<rick_h_> kadams54: ok thanks
<hatch__> the current recommended haproxy charm is old and doesn't support me providing a custom config file
<hatch__> but haproxy.org hasn't been updated in well over a year which is odd, so i have no idea where to look for docs, release notes, etc
<jrwren_> hatch__: sounds like a good oportunity to charm it up.
<hatch__> jrwren_: right I have to make my own haproxy charm - but I can't find the source of truth for the docs/project
<rick_h_> kadams54: jcsackett Makyo can I get a second review please? https://github.com/juju/juju-gui/pull/530
<jcsackett> nope.
<rick_h_> frankban: looking at yours but might not be done until tomorrow tbh
<hatch__> rick_h_:  you can't expose an uncommitted service because we don't show the toggle :) 
<jcsackett> rick_h_: if no one else grabs it by the time i'm done with my current set, i'll poke at yours.
<rick_h_> hatch__: ah, ok then. I'm ok with it atm
<kadams54> rick_h_: taking a look
<rick_h_> hatch__: in that way it's not something you can 'uncommit' so it's safe-ish
<frankban> rick_h_: thanks, Jeff and Madison are already looking at it FYI
<rick_h_> well that you can 'not yet commit' I guess
<rick_h_> frankban: ah ok cool
<rick_h_> hatch__: for the bookmarks http://kentwilliam.com/articles/rich-drag-and-drop-in-react-js
<rick_h_> damned coffeescripot
<rick_h_> coffeescript
<rick_h_> ty kadams54 
<hatch__> rick_h_:  sounds good
<hatch__> heh will look at link at lunch
<hatch__> lol coffeescript
<hatch__> https://pub.dartlang.org/packages/android .....maybe coming? :) 
<hatch__> heh unlikely I think their glued to android 
<hatch__> er java
<hatch__> frankban: ok I've finished the code portion of the review and have one largish issue 
<hatch__> mind taking a look at the comments?
<hatch> frankban:  hmm I'm not sure I agree that it's any simpler - you had to write all of those noop methods and keep them in sync vs calling one init/render method vs another
<frankban> hatch: we still need to call render, and if the interface changes, we have a test that fails, and maintaining that is just adding a dummy method. If we find this is annoying, we can even build the noop view dynamically
<frankban> hatch: with the other approach, we should also ensure that each view.method call is noop AFAICT, complicating the real header view implementation
<hatch> frankban:  right, but in the init it checks to see if it's a dummy view or not, if it is then it doesn't call a method to add the events. In the render method it checks the same attribute to see if it should call the 'renderDummy' or 'renderFull' cycles
<hatch> frankban:  do things like setDroppable get called on the dummy method too?
<frankban> hatch: that's ok, we start adding if conditions in init and render, but then we need those in all the other methods, correct? e.g. setDroppable must be a noop if the view is in dummy mode. the same for all the other methods. if that's correct, then in the future we have to remember that each method can be "disabled" when adding new logic, and IMHO this is error prone. and we also need to test methods based on stat
<frankban> e. I don't feel it's simpler
<hatch> ok I see where you're coming from
 * hatch thinks about it some more
<frankban> hatch: yes. otherwise my argument is the same, but moved to the caller. we need an if for each time a view method is called
<frankban> hatch: the current approach just switches components, and no other imperative stuff is required
<frankban> hatch: we have two components implementing the same interface, and we ensure they do implement it with a single test
<hatch> the issue now however is that we have to know to test every interaction with the container header in disabled and non disabled mode on every change 
<hatch> crap js sucks for this problem
<hatch> frankban:  I'm entertaining the idea of having the 'real' view extend the 'dummy' view and having some check that the methods line up....
<hatch> not sure how it's possible yet
 * hatch wishes for a more featureful language atm 
<frankban> hatch: I'd like to avoid inheritance there, and I am not sure I understood what we need to further test re interactions
<hatch> yeah inheritance is'nt the best - I'd like an "implements" feature in js
<hatch> frankban:  so if joe developer adds a method to the 'real' view, he has to know to go and add it to the dummy as well
<hatch> but there is nothing forcing that
<hatch> so it could introduce a hidden bug
<frankban> hatch: he will know it because he sees a test miserably failing
<hatch> but how will the test fail if he didn't know to add one for that functionality?
<hatch> oh son-of-a
<hatch> I missed the test I was going to ask for
<hatch> lol
<frankban> hatch: the "implements the machine panel header view interface" ensures the dummy view implements the public interface of the real one. JS type system does not have that, but we can easily work arounf that with a test
<hatch> haha yeah I JUST saw that
<hatch> oops :)
<hatch> so sorry
<frankban> np :-)
<hatch> +1 to the code, going to drop into qa now
<frankban> hatch: thanks a lot
<hatch> luckily I have a env already up :)
<hatch> frankban:  also....can you edit the initial message to only include the details of the merge and not include the qa steps. GH puts everything in the first message as the merge message and we decided that we would only put the changes made in this message and put the qa instructions in a separate comment
<frankban> hatch: sure
<frankban> hatch:  done
<hatch> frankban:  all done
<frankban> hatch: thanks!
<frankban> hatch: good to know it is already a bug
<hatch> yeah, irritating bug because I thought I fixed all the token icon related bugs :)
<frankban> heh
<frankban> Makyo: thank you for the review, at this point I'd be inclined to ship it
<Makyo> I agree, unless you want another QA.
<frankban> rick_h_: do you want me to wait for your review?
<hatch> sssshhhhhiiiippppiiiitttttt
<hatch> :)
<frankban> :-)
<rick_h_> frankban: no, I'm sorry. I added a couple of comments but all good
<rick_h_> frankban: on my end
<frankban> thanks rick_h_ 
<frankban> rick_h_: I think the conversation with hatch (above) was around one of your comments too
<frankban> shipping it
<rick_h_> frankban: yep, I'll catch up the traceback in a bit but trust you guys hashed it out
<frankban> rick_h_: great
<rick_h_> ty hatch nd kadams54 for the reviews!
 * rick_h_ runs and tries to get a lunch in here
<hatch> lazyPower: is there any way I can find out who the maintainer of the haproxy charm is and get in touch with him/her? 
<rick_h_> hatch: we use it internally, maybe chat in #webops and see if there's a diff charm or anything there?
<hatch> rick_h_:  well I'd really prefer the maintainer to update it and add support if possible
<hatch> vs me doing through the whole process of learning haproxy
<rick_h_> hatch: understoood
<rick_h_> but if you're looking for the best charm, and maintained (as we're using it in prod) it's something to keep in mind
<hatch> yeah definitely - it probably shouldn't be promoted if it's no longer up to date :)
<hatch> I asked there, maybe some luck :)
<Makyo> hatch, found the databinding issue, updated pr https://github.com/juju/juju-gui/pull/527
<hatch> Makyo:  hah nice find
<hatch> I'm just qa'ing my branch atm, will pull yours down again soon
<Makyo> Cool, thanks
<hatch> Makyo:  also with this https://github.com/hatched/juju-gui/commit/4c38c98e36290555572864f3de527226621d87df we can now actually delete units via the inspector :) 
<Makyo> Oh, rock on
<hatch> seems we have hit the obscure bug portion of the release lol
<Makyo> Yeah, right? :P
<rick_h_> kadams54: call running long, will ping when done for 1-1 but not able to jump away any time soon
<rick_h_> kadams54: sorry for the mess around that today
<jcastro> rick_h_, hey, the use of elasticsearch in the gui
<jcastro> does that apply to self hosted versions too or just jujucharms.com?
<rick_h_> jcastro: right now it's as long as the gui looks to manage.jujucharms.com
<rick_h_> jcastro: that'll move to the new store once we release it
<jcastro> ok so  like, each user isn't deploying ES internally right?
<jcastro> like, we're not bundling it?
<rick_h_> jcastro: correct
<jcastro> ack
<rick_h_> we're bundling it for our own prodstack needs, but not to each gui deploy or the like
<jcastro> ack
<hatch> Makyo:  ok doing your qa
<hatch> Makyo:  am I supposed to be able to click the 'delete' button in the mv still?
<hatch> Makyo:  sorry another qa issue, added to pr
<Makyo> hatch, can't reproduce.  And what delete button?
<hatch> says "Remove" sorry
<hatch> in the unplaced unit tokens more menu
<Makyo> Yeah, I can't reproduce that.
<hatch> hmm
<hatch> can you make sure you have develop updated?
<Makyo> For pete's sake >:/
<Makyo> Why the hell was env removed?
<Makyo> Attrs are there for a reason.
<hatch> Makyo:  looks like we both missed it in the review :/ https://github.com/juju/juju-gui/pull/531/files#diff-68c965ef8aa2aaad942d780b3b1cf450L413
<Makyo> Oh crap, you're right.  I thought that was cleanup.
<Makyo> Let me see if I can get that back in.  Sorry if the merge screws up my ability to rebase.
<kadams54> hatch: yesterday you mentioned an event being fired when a service was added to the changesetâ¦ I see a changeSetModified event, but that's not specific to services being added.
<hatch> when a service gets added to the canvas 
<hatch> is handled differently than when it's clicked on once on the canvas
<Makyo> hatch, alright, now try
<Makyo> Sorry for the mixup
<kadams54> hatch: what code should I be looking through for that?
<kadams54> topology?
<hatch> kadams54: yeah the topology/service.js
 * rick_h_ hears a ripping noise as the headphone come off
<hatch> for once it's already landed
<rick_h_> kadams54: I'm free now whenever you are. Just ping and we'll do this thing
<hatch> Makyo:  ok looking
<hatch> rick_h_:  can you explain to kadams54 about your idea wrt the different ways the inspector opens
<hatch> just trying to get to lunch :D
<rick_h_> hatch: okie dokie
<hatch> Makyo:  did you want to add a 'remove' button to the inspector for uncommitted units section? probably a follow-up hey?
<hatch> rick_h_:  thx
<kadams54> hatch, rick_h_: I think I have the general idea in mindâ¦ display the help message when the inspector is opened by adding a service to the canvas. Hide it otherwise.
<kadams54> rick_h_: ready
<rick_h_> kadams54: ok, in the room
 * hatch runs away for lunch
<Makyo> hatch, yeah, follow up
<lazyPower> hatch: just wrapped validation on 3 ot 6 substrates and I'm not seeing that behavior from the MySQL charm
<lazyPower> hatch: if you can reproduce it, can you attach the steps you took to reproduce the behavior you're seeing?
<hatch> was one of those ec2? What version of Juju?
<lazyPower> hatch: http://paste.ubuntu.com/8252799/
<lazyPower> 1.20.7, and yes EC2, LXC, and MAAS
<hatch> ok I'm on 1.20.6-trusty
<hatch> lemme try again
<hatch> lazyPower:  it'll take a bit, I'll report back
<lazyPower> hatch: feel free to ping me if you see teh same behavior - I'll want to look at your deployment command history so i can verify on my end.
<hatch> lazyPower:  I'm just doing `juju bootstrap` `juju deploy mysql` 
<hatch> so we'll see
<lazyPower> ack
<hatch> lazyPower: umm ok it worked fine
<hatch> lazyPower: I'll now do what I was doing yesterday, using the GUI and whatnot
<lazyPower> hatch: not sure why you saw a nothing in there, it may be a response it was expecting that it didn't receive... but if its working thats a step in the right direction, if you can find the missing link I'll be happy to try and verify the bug on my end.
<lazyPower> holy run-on batman... 
<hatch> yeah I don't get it, I did those exact steps yesterday and it failed multiple times
 * lazyPower goes back to code, where run-ons are denoted by 80col rules.
<hatch> unless maybe a keyserver was down or something?
<hatch> lazyPower:  ok I have reproduced it
<hatch> *phew*
<hatch> :)
<hatch> I'll outline the somewhat numerous steps I took
<lazyPower> hatch: can you update the bug with steps to reproduce? I'll run down what you've done so i can confirm the bug.
<hatch> lazyPower:  ok added, sorry about the # of steps :) 
<hatch> ahead of time
<hatch> heh
<hatch> lazyPower:  I also still have the env up if you want to see it
<lazyPower> hatch: can you attach the output of juju run --service mysql 'config-get'?
<hatch> done
<hatch> any other tasks? :)
<hatch> lazyPower:  I also added the mysql portion of the juju status
<hatch> lazyPower: hmm, my local is 1.20.6 but it says the mysql one is 1.20.7 could that cause the issue?
<jcsackett> rick_h_: do you have any of the login information for the jenkins instance running charmworld autoland?
<rick_h_> jcsackett: no, that's run by QA. I think brad might have had some access. Might need to ping abentley or sinzui
<jcsackett> rick_h_: i've pinged sinzui as well.
<abentley> jcsackett: Here are the docs about the charmworld lander that I wrote up when we handed it off to your team https://docs.google.com/a/canonical.com/document/d/1IH_a8evtcbJ_bcF2m0SmcvWEO1dT_R6zpjYpp6M_sRU/edit#heading=h.e2vmlmlyb2x0
<jcsackett> abentley: fantastic! thanks.
 * jcsackett stars that document
 * rick_h_ walks away for a little bit until the AU calls, biab
<hatch> rick_h_:  looks like all my issues with mysql charm yesterday were actually caused by the GUI :O
<hatch> rick_h_:  https://bugs.launchpad.net/juju-gui/+bug/1365205 it's a pretty high priority one blocking release 
<mup> Bug #1365205: Charm cannot be deployed, fails on install hook with gpg error <juju-gui:New> <mysql (Juju Charms Collection):Invalid> <https://launchpad.net/bugs/1365205>
<rick_h_> hatch: rgr thanks for the heads up
<hatch> it's pretty obscure hah
<hatch> glad it happened to me lol
<rick_h_> yea, no kidding
<rick_h_> jujugui no AU call tonight. huw called in sick
<rick_h_> reminds me, jcsackett did you file that?
<hatch> alrighty thanks
<jcsackett> rick_h_: no, i did not. thanks for the reminder.
 * jcsackett goes to hr site
<jcsackett> rick_h_: done.
<rick_h_> jcsackett: rgr ty
<rick_h_> jujugui made hatch's bug up in urgent. When grabbing next available card please tackle next
<rick_h_> and bug hatch for details/info
<rick_h_> :)
<hatch> haha yes plz do (although I'm coming up on needing a next card)
<hatch> jujugui lf reviews https://github.com/juju/juju-gui/pull/532 (covers two cards)
<rick_h_> hatch: I might try to look when I come back later to finish emails for the day but brain fried atm
<hatch> sure np
<rick_h_> hatch: good news is first call tomorrow is 10am so might get to look at it before you start either way
<hatch> haha yay
#juju-gui 2014-09-05
<hatch> yes you CAN run haproxy/ghost/mysql on a t2.small :)
<hatch> oh, and the bootstrap node 
<hatch> using 412M of ram :)
<hatch> oop 452
<rick_h_> lol
<rick_h_> woot
<rick_h_> !
<hatch> I need to somehow make a ton of requests to see if my mem usage goes up
<rick_h_> ab or apachebench or whatever
<hatch> yeah ab it is
<rick_h_> ab is apache bench sorry, thinking of seige
<hatch> hmm says invalid url
<rick_h_> quotes around it?
<rick_h_> been a while since I ran ab
<hatch> ab -n 1000 -c 10 http://ec2-107-20-7-222.compute-1.amazonaws.com
<hatch> I'm pretty confident that's correct
<rick_h_> add a / at the end?
<hatch> that was the trick
<hatch> :)
<rick_h_> :)
<hatch> 468
<hatch> 468M was the highest usage with a 266ms time per request avg
<hatch> not bad - I wonder if I can do this on a micro
<hatch> dropping to 2 concurrent it only goes down to 219ms per request 
<hatch> so it's not being pegged :)
<hatch> try 20
<hatch> :)
<hatch> oh there we go lol
<hatch> 489ms
<hatch> :)
<hatch> cpu bound
<hatch> unfortunately I can't use the GUI, I need port 80 :(
<hatch> darn, can't get mysql to run on a micro
<hatch> heh
<hatch> with the bootstrap node, haproxy ghost :)
<hatch> although I think amazon is lying, they say on their site that it's 1GB of ram, htop is only showing 590
<rick_h_> yay tgif
<urulama> rick_h_: indeed :)
 * rick_h_ makes some coffee now that email is processed
 * rick_h_ is going into a call so completely afk for the next little while
<kadams54> hatch: I have more questions about state :-)
<hatch> well ubuntu vm decided it doesn't want to display anything but black pixels today :/
<hatch> kadams54 shoot
<kadams54> hatch: What is metadata generally used for
<hatch> I don't understand the question
<hatch> if you look in state.js you can see everywhere it's referenced
<hatch> it's used to send the data about the state that needs to change
<kadams54> Any arbitrary data, or is it more limited than that?
<hatch> well it's more limited than that because the state system and dispatchers needs to know what to do with the data
<hatch> what are you thinking of putting in there?
<jrwren_> hatch: mysql can run on a micro. its just a bug in the charm.
<jrwren_> "just"
<kadams54> hatch: A flag for showing/hiding the help text
<hatch> jrwren_ yeah I was poking at it, looked like it intentionally needs too much space
<hatch> *sadface*
<hatch> kadams54 hmm
<jrwren_> hatch: I ran into it often when running on local in a small kvm. I'll propose a fix :)
<hatch> metadata is the correct place for that....not sure we want it in there though :)
<hatch> jrwren_ awesome! 
<hatch> I really want to run my blog for $5/mo :)
<jrwren_> hatch: are micros that cheap now?
<hatch> DO has a $5 droplet
<hatch> and can handle 10 concurrent rps at about 170ms response time
<hatch> which is more than enough for my blog atm
<hatch> kadams54 adding it to the model might be quite a bit simpler than adding it into state
<hatch> plus if it's in state it'll create a routable url
<hatch> which doesn't make much sense in this case :)
<hatch> yay back from black desktop in vm......stupid parallels 
<kadams54> hatch: The whole point of going down this rabbit hole was to connect the showing/hiding of the text to a user's actions, rather than the modelâ¦
<hatch> ehh it's not that deep of a rabit hole 
<kadams54> hatch: the problem is that I'm having a hard time locating a good hook to hang this work off of.
<hatch> there ever only was one spot to do this :) Now you learnt how this works haha
<hatch> rick_h_ thoughts on making the hiding of the help text a routable url?
<kadams54> hatch: I've looked all through topology/service.js but I don't see anything all that different about how the inspector is created when clicking on a service vs. adding a new one.
<kadams54> hatch: rick_h_ is afk right now for a phone callâ¦ which is why you get the question :-)
<hatch> ohh
<hatch> well they are different methods which call the changestate
<hatch> so in those different methods you would do something different to signify that you shouldn't show the help text
<hatch> there is a 'flash' storage in the state which allows you to send data not in the url
<hatch> but I think it only allows one record of things at a time
<hatch> https://github.com/juju/juju-gui/blob/develop/app/views/topology/service.js#L740
<hatch> https://github.com/juju/juju-gui/blob/develop/app/views/state.js#L461
<hatch> then you'll reference metadata.flash.whateveryoucallyourproperty here https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/browser.js#L586
<kadams54> The _deployLocalCharmâ¦ is _deployFromCharmbrowser the other side of that coin?
<hatch> deploy local charm is what handles when you drop a zip charm on the canvas
<hatch> deploy from charmbrowser fires an event initateDeploy
<hatch> so you trace that handler down and you'll see where it also fires a changestate event for the ghost inspector
<kadams54> It sounds like I need to add the flag in two spots: that handler and the _deployLocalCharm, and then extract it again in the renderServiceInspector method.
<hatch> why deploy local charm?
<kadams54> Don't we want to display the help text for local charms as well?
<hatch> that shows a totally different inspector
<hatch> it should be visible by default and only hidden by the flag - then you only have to hide it in one place
<hatch> in showServiceDetails 
<hatch> brb
<kadams54> hatch: Hah, my plan was to hide it by default (because the problem right now is that it's shown when we don't want it to show) and then only show it when a service is first added to the canvas.
<hatch> ahh yeah - well there are more places where it's created (where we want it shown) than it's not :)
<hatch> surprisingly 
<hatch> kadams54 have you deployed a local charm in the gui yet?
<kadams54> hatch: yes
<kadams54> hatch: Your ghost charm, specifically :-)
<hatch> well then!
<hatch> jujugui call in 10
<urulama> jujugui: i suggest postponing for 10min, so that rick_h_ finishes the current call
<frankban> urulama: +1
<jrwren_> ok
<hatch> urulama ack
<hatch> jujugui call in 13
<hatch> :P
<rick_h_> off call
<rick_h_> jujugui call in 4
<jrwren_> lol
<hatch> lol
<urulama> rick_h_: sheesh :D
<rick_h_> jujugui call time wheeee
<rick_h_> hatch: jcsackett kadams54 ^
<jcsackett> oops. coming.
<hatch> jujugui still need those reviews https://github.com/juju/juju-gui/pull/532 plz
<rick_h_> hatch: you and kadams54 all good?
<kadams54> We'll know for sure in about 30 minutes :-)
<rick_h_> kadams54: ok awesome. Let me know how it goes. thanks guys
<kadams54> But yeah, I'm back to coding again, so that's a step in the right direction.
<hatch> :)
<hatch> hazmat hey thanks for the update to the DO plugin, I'll be giving it a try tonight.
<hatch> oh man this critical card was literally a 6 character fix
<hatch> it's going to take about 1Mx longer to test than to fix lol
<rick_h_> hatch: well that's good to hear at least then. 
<rick_h_> that it's not some fundamental giant of a thing
<hatch> well....it sort of is...the charm is broken
<rick_h_> whoops
<hatch> but since the cli handles it correctly the guy should too
<hatch> gui
<hatch> rick_h_ https://gist.github.com/hatched/998e31e217c2a577d112
<rick_h_> hatch: :)
<rick_h_> jujugui have to run up to the doc office for a little bit. biab. 
<hatch> enjoy
<rick_h_> flu shots are in and the wife mandates I get one asap yay me
<urulama> rick_h_: to actually get a flu, you'll have to leave your desk and computer sometimes ;)
<hatch> lol!
<hatch> that's why I get sick every time I leave the house
<urulama> hatch: programmers should walk around in one of these http://main.cdn.grabone.com/goimage/440x267/i4a3clx.jpg
<urulama> hatch: imagine our next sprint! :D
<hatch> lol
<hatch> it could be ON a lake
<hatch> jujugui I'm going to be taken offline (power) in a few for about 30mins 
<hatch> jujugui still need one more review on #532, qa is already done
<frankban> hatch: on it
<rick_h_> urulama: her thing was "You better get this shot before you get on a plane with 300 sick people
<rick_h_> "
<hatch> and power!
<rick_h_> woot
<hatch> I no longer have a 100A power line running across my backyard
<rick_h_> what could possibly go wrong with that?
<rick_h_> new motox take my money!
<rick_h_> wish I could get a 360 but I think my wife would kill me
<rick_h_> hatch: want an LG watch?
<rick_h_> and I'll get a 360?
<hatch> haha no sorry
<rick_h_> no shippping fee straight to brussels :P
<hatch> https://twitter.com/FromAnEgg/status/507935819521613825
<rick_h_> hatch: I'm talking watches not phone :P
<hatch> I know....but saving moneys
<rick_h_> boo ok good plan
<jcsackett> hatch: sorry i forgot to look at your PRs. moving charmworld along is surprisingly distracting.
<hatch> heh np frankban got it
<jcsackett> cool stuff.
<hatch> of course my simple fix turned out to not be good enough :/ bleh
<hatch> todays pro tip: if you're going to spill a bowl of borscht don't do it over your desk, keyboard cellphone, wallet, dog 
<rick_h_> ouch
<rick_h_> time for a new phone! new moto x here we come! :P
<rick_h_> Makyo: hatch got a sec to chat?
<hatch> lol
<hatch> rick_h_ yeah 2 mins just need to reposition stuff now that I don't have an external keyboard lol
<rick_h_> hatch: all good
<rick_h_> I'm chilling in today's standup room
<jrwren_> someone finally fixed python: https://github.com/paradoxxxzero/nocolon
<hatch> lol no
<hatch> that's just wrong
<hatch> it even says so in the readme haha
<rick_h_> w...t...f
<rick_h_> less ruby in my python kthx
<hatch> haha +1
<jrwren_> I often forget colons when I Haven't done python in a while.
<jrwren_> I always wished they were optional :)
<hatch> nobody is happy
<hatch> sheesh
<hatch> I guess tonight I'll be taking apart my keyboard and running it through the dishwasher.....it no longer works so....maybe now is a good time to invest in an expensive one
 * rick_h_ holds back
<hatch> haha, are you back to using your kinesis?
<rick_h_> yea, been using it for a while
<rick_h_> typing too many docs these days :P
<rick_h_> but I've got a closet of about 7 mechanical keyboards you could try :)
<hatch> lol I've been eyeing this one.... https://www.trulyergonomic.com/store/index.php 
<hatch> unfortunately they are all on backorder
<hatch> I may end up switching to one of my many old keyboards if this one doesn't come back to life
<rick_h_> no good windows/meta key so :(
<hatch> the one in the middle top i think is the meta key
<rick_h_> yea but typing that easily a lot of times a day is not going to work ou
<rick_h_> out
<hatch> yeah true
<hatch> https://www.trulyergonomic.com/store/model-differences--truly-ergonomic-mechanical-keyboard--cherry-mx-brown-red-blue-black-clear-keyswitches#Model-209
<hatch> here is one with a split alt key
<hatch> could turn one of those into one maybe
<rick_h_> hmm, perhaps
<hatch> I've never seen/used this one in person so I really have no idea
<rick_h_> yea, I've looked a lot at it but keep holding back
<hatch> https://www.kinesis-ergo.com/shop/advantage-lf-for-pc-mac/
<rick_h_> that's what I use
<hatch> coding with browns would suck
<hatch> fingers would get so sore haha
<rick_h_> yea, I do wish for blues, but browns get by
<rick_h_> hah, let me show you my unicomp
<rick_h_> that one I get sore hands for the first week of use every time
<hatch> oh you're using browns and not reds?
<hatch> https://d2s7foagexgnc2.cloudfront.net/files/49df782d46968ee719e7/kinesis_and_trackpad.jpg interesting layout....I'd probably do something very similar to this
<rick_h_> yea, the browns here
<rick_h_> hah, that's funny
<rick_h_> jujugui ok I'm out. Everyone have a good weekend. 
<hatch> enjoy your weekend
<hatch> cya
<rick_h_> 12 cards left, with 5 people. Should be able to knock em out next week np
<rick_h_> :)
<hatch> agreed!
<kadams54> hatch__: Soâ¦ it looks like the flash object is being stripped out before it gets down to renderServiceInspector.
<hatch__> hmm that's odd
<hatch> lemme pull up the code
<hatch> kadams54 not sure that's possible - if you look at the renderLocalInspector method it references the flash property
<hatch> and it's the same method that either calls the renderServiceInspector or renderLocal Inspector
<kadams54> Hmm. I see the flash property going in, but it's not coming out the other end. Still tracing through all the state code.
<hatch> kadams54 put a debugger in the _inspectorDispatcher and see if it's available there
<hatch> because that's where it would be passed to the renderLocalInspector if it had it
<kadams54> > metadata
<kadams54> Object {id: "7818300$"}
<kadams54> So nope.
<hatch> hmm can you put a gist of your diff up
<hatch> something funky is going on
<kadams54> This is what I see when I inspect the state object in the *:changeState handler, browser.js line 207:
<kadams54> > state.sectionA.metadata
<kadams54> Object {id: "7818300$", flash: Object}
<kadams54> So the flash is there when the changeState event is caught, but gone by the time it hits _inspectorDispatcher
<kadams54> gist coming up
<kadams54> https://gist.github.com/kadams54/1b382fca1c2c1d84071c
<hatch> ok put a debugger in state.js on like 461
<hatch> oh that's the problem
<hatch> that can never be hit
<hatch> move line 461 to line 468
<hatch> well that's a temp fix to see if it works
<hatch> will need a bit of a better fix for the long haul
<hatch> then I think 126 needs to change from being set to an object to being set to undefine
<hatch> d
<hatch> kadams54 is that making sense?
<kadams54> Sorry, afk, back now
<kadams54> Not sure why line 126 needs changing, but I follow the rest
<kadams54> hatch: bam, that works.
<hatch> it needs to be changed because we don't want it setting the flash metadata on every request
<hatch> so that should now be if (this.get('flash')) {...} 
<hatch> and then where it resets it change it to set it to undefined
<hatch> s
<hatch> darn keyboard busted
<hatch> :/
<hatch> kadams54 I have to run and buy a new keyboard
<hatch> I'll likely be back in about 45 if you need some more help
<kadams54> Friday fun
<kadams54> I'm all set
<hatch> yeah the store is closed on the weekends for the kinesis 
<kadams54> Just working on a test now to make this official
<hatch> so gota get there before eod
<hatch> ok bbiab
<hatch> kinesis keyboard with browns equipped
<hatch> this will take a while haha
#juju-gui 2014-09-07
<cory_fu> mbruzek: https://support.google.com/calendar/answer/37064?hl=en
<cory_fu> Sorry, wrong chan
<huwshimi> Morning
<rick_h_> morning huwshimi, feeling better?
<huwshimi> rick_h_: Yeah, much better thankyou!
<rick_h_> awesome, good to hear
<rick_h_> huwshimi: when you get a sec let's chat for a few min and catch up on missed weekly call stuff please
<huwshimi> rick_h_: Anytime is fine, I'm just catching up on emails
<rick_h_> huwshimi: cool, https://plus.google.com/hangouts/_/gq7owllyohfgi2ebde5biy6bvya?authuser=1&hl=en
<rick_h_> the las 3 hours of it wheeee!
#juju-gui 2015-09-03
<firl> anyone able to help me validate if my constraints tag is proper? juju-gui doesnât seem to be respecting my constraints
<firl> in a v4 bundle 
<rick_h_> firl: what's the constraint?
<firl> rick_h_ http://pastebin.com/ULBjUtiy
<firl>  constraints: tags=compute
<firl> maas tag specifically
<firl> it fails completely when I try to put it on the service layer
<rick_h_> firl: looking sec
<firl> ty
<rick_h_> firl: did you try putting " " around it?
<firl> I did, but I can try again
<rick_h_> firl: see https://jujucharms.com/docs/stable/charms-bundles#local-deploy-via-command-line
<firl> yeah the service constraints didnât work at all
<firl> let me rebootstrap and try with quotes around it
<rick_h_> firl: I was looking at the machine one vs service ones
<rick_h_> firl: can have Makyo look when he's in, next 20ish
<firl> cool; yeah just trying to create a repeatable way to just tag systems and deploy to them in the lab
<rick_h_> firl: oh, but is that just the part of the file?
<firl> what?
<rick_h_> firl: never mind, ignore me
<firl> haha ok
<firl> I donât see the tags constraint in the juju-gui, but I assume itâs supposed to still respect it in the bundle file right?
<rick_h_> firl: checking
<rick_h_> firl: yea, it's there https://github.com/juju/juju-bundlelib/blob/master/jujubundlelib/validation.py#L27
<firl> cool
<rick_h_> firl: ok so how are you deploying the bundle?
<rick_h_> firl: juju-quickstart "filename"?
<firl> no, drag and drop
<rick_h_> ah ok
<firl> i can try the juju-quickstart file name
<rick_h_> no, that's ok. 
<firl> kk
<rick_h_> ahhhhhhhhh
<rick_h_> oh no...you're dragging/dropping in a real enviornment right?
<firl> yeah
<firl> juju bootstrap --to machine.name
<rick_h_> ok cool
<firl> juju deploy juju-gui --to 0 && juju expose juju-gui
<rick_h_> cool, yea that should all work. 
<firl> kk
<firl> ( I had an issue with quickstart originally I think, donât remember why, thatâs why I went the juju-gui route )
<rick_h_> firl: ah but they both use the same path
<rick_h_> juju-guickstart just passes it to the gui 
<firl> thatâs what I figured; but still for some reason didnât like it
<firl> I can try to replicate via juju quickstart
<rick_h_> that's ok, what's the exact error you get?
 * rick_h_ can search for it
<firl> 1s let me replicate
<Makyo> frankban: http://pastebin.com/ULBjUtiy
<firl> rick_h_: An error occurred while deploying the bundle: json: cannot unmarshal string into Go value of type []string
<firl> drag and drop into the UI works I think
<firl> rick_h_: http://pastebin.com/5McramHp
<firl> same error with juju-deployer, dragging and dropping seems to âwork"
<firl> but ignores constraints
<firl> rick_h_: even with â âs around it, no dice
<rick_h_> firl: thansk for trying. Makyo and frankban are looking into duplicating it and chasing it down
<firl> cool, if you want me to try any specific versions / patches let me know
<rick_h_> firl: will do, <3
<firl> I can open a bug also if it warrants it and I am not just using it wrong
<Makyo> frankban: app.db.machines.item(4)
<firl> afk for a bit
<Makyo> frankban_: app.env.get('ecs').changeSet
<frankban> uiteam, Makyo: https://code.launchpad.net/~frankban/juju-deployer/fix-tags-constraint/+merge/270070
<frankban> tvansteenburgh: could you please take a look?
<frankban> ^
<frankban> firl: hey we investigated and found two bugs in how the tags constraints are provided to juju, on ein the GUI and one in the deployer. The fix for the deployer already landed on trunk, and we are working on the GUI side
<frankban> tvansteenburgh: thanks for the review!
<tvansteenburgh> frankban: np, let me know if/when you need a new release
<firl> frankban: woohoo! thanks
<firl> frankban: how can i test it on the deployer side?
<rick_h_> marcoceppi: you ever used mojo?
<firl> rick_h_ , frankban , Makyo : I just tried the latest deployer, it deployed, but I think it didnât respect the tags again. Should I also have a different version of the juju to go with the new deployer?
<rick_h_> firl: no, just the deployer, but not through the GUI
<firl> rick_h_: Yeah I used juju-deployer, and I no longer get the error, however doesnât respect the tags
<marcoceppi> rick_h_: I know enough about it but I haven't actually used it much in depth
#juju-gui 2015-09-04
<firl> frankban you around?
<frankban_> firl: yes
<firl> I tried the latest juju-deployer, and it didnât work with the constraints. It seemed to ignore it just like dragging it to the UI did
<frankban> ignore the tags constraints, or just all constraints?
<firl> I am only using tags constraints
<firl> so I donât know 
<frankban> firl: I see
<firl> but the juju-deployer passed validation for the file where it didnât before
<frankban> firl: yes I fixed the fact that tags were passed as a string, butl a list was required instead.
<frankban> firl: I'll investigate that further
<firl> kk, let me know if there is anything I can do. 
<frankban> firl: could you please point me at the YAML again?
<firl> http://pastebin.com/fxHJi5ue
<firl> ( had a feeling you might have wanted the one I was using )
<frankban_> firl: sorry disconnected,  how do you know that tags are not set?
<firl> when I look at my network agent
<firl> itâs not on the right tag
<firl> ( juju status )
<frankban> firl: ok I'll check, are you on maas?
<firl> yeah
<firl> I have a 6 node cluster that I can replicate and let you see fully if that helps
<frankban> firl: not at the moment, and I have t leave in ~40 (we are sprinting this week). I'll be on it on Tue.
<firl> cool
<firl> thanks again man
<frankban> firl: I just deployed your bundle using juju 1.25-alpha1-vivid-amd64 on an ec2 environment and it seems tags seems to be  properly set: http://pastebin.ubuntu.com/12274405/
<frankban> firl: so maybe a problem in maas?
<frankban> firl: could you please try the bundle deployment using that juju version and check if status reports correctly the tags?
<firl> frankban: How do I install that version specifically? bzr and compile with go?
<firl> frankban: install juju 1.25-alpha1-vivid-amd64 and use juju-deployer or use juju quickstart
<firl> is it ok to use 1.26-alpha1-vivid-amd64 ?
#juju-gui 2016-09-09
<ahasenack> hi guys, I pushed and released (charm release) cs:~ahasenack/landscape-server-1 but I can't see it in the store, and deployer complains with a 407 (proxy auth required?) error
<ahasenack> charm pull fetches it just fine
<ahasenack> did I miss some step? I used to do charm publish, but that's gone
<rick_h_> ahasenack: yes, there's a whole new charm process that's been in place using the new charm cli command and a release workflow much more like snaps
<ahasenack> $ charm release cs:~ahasenack/landscape-server-1
<ahasenack> url: cs:~ahasenack/landscape-server-1
<ahasenack> channel: stable
<ahasenack> warning: bugs-url and homepage are not set.  See set command.
<ahasenack> what else do I need to do?
<rick_h_> ahasenack: see https://jujucharms.com/docs/stable/authors-charm-store
<rick_h_> ahasenack: you have to set the ACL on it so everyone can see it probably
<ahasenack> ok
<ahasenack> rick_h_: that page still talks about "charm publish"
<ahasenack> which is not available in the packages published to the juju stable ppa
<rick_h_> ahasenack: right, the charm publish command which is in xenial? 
<rick_h_> just not juju publish
<ahasenack> ppa:juju/stable xenial in my case
<ahasenack> right, charm publish
<rick_h_> ahasenack: ok, and you added the ACL for everyone
<ahasenack> I'm trying, it's not yet showing up in the charm store search
<ahasenack> tried these: http://pastebin.ubuntu.com/23154693/
<rick_h_> the charm store won't show non-promulgated, you need to go to the user page I believe. https://jujucharms.com/u/ahasenack/
<rick_h_> and I see landscape-server there
<ahasenack> it used to find user charms and list them in another section, further down
<rick_h_> hatch: jujucharms.com search is just promulgated now right?
<rick_h_> ahasenack: yes, that's been done away with
<hatch> rick_h_: it is yes
<hatch> unless there are no promulgated that match
<ahasenack> ok
<ahasenack> geez, why does charm show <charm> show info about other charms?
<rick_h_> ahasenack: so charm show <charm> is like going to the charm details page which works just fine
<ahasenack> under "charm-related"
<rick_h_> https://jujucharms.com/u/ahasenack/landscape-server
<ahasenack> charm-related:
<ahasenack>   Provides:
<ahasenack>     pgsql:
<ahasenack>     - Id: cs:~alexlist/precise/pgbouncer-0
<ahasenack>     - Id: cs:~alexlist/precise/pgbouncer-1
<ahasenack> and a huge list below that
<ahasenack> pages and pages
<rick_h_> ah, it's charms that meet that relation? That's probably something that we should clean up
<rick_h_> worth a bug
<ahasenack> basically all revisions of any other charm that uses these relations
<ahasenack> hundreds and hundreds :)
<ahasenack> I'll file one
<rick_h_> ahasenack: yea, that sucks
<ahasenack> rick_h_: since I'm here, I also filed this earlier, but it doesn't look juju-gui related: https://bugs.launchpad.net/ubuntu/+source/charm-tools/+bug/1621870
<mup> Bug #1621870: charm push fails in bzr branch <charm-tools (Ubuntu):New> <https://launchpad.net/bugs/1621870>
<rick_h_> ahasenack: sure thing, https://github.com/juju/charmstore-client is the charm client code/bugs
<rick_h_> ahasenack: I'll move that over there
<ahasenack> oh
<ahasenack> ok
<rick_h_> ahasenack: https://github.com/juju/charmstore-client/issues/90
<ahasenack> thx
