[16:33] <magicaltrout>  so
[16:33] <magicaltrout> the juju gui
[16:33] <magicaltrout> tells me 2 charms are blocked
[16:33] <magicaltrout> juju status tells me all is green
[16:33] <magicaltrout> on jaas
[16:34] <magicaltrout> who broke it?
[16:34] <rick_h_> magicaltrout: hmm, reload the browser? maybe something got missed in the websocket coms?
[16:34] <magicaltrout> did that
[16:34] <magicaltrout> went back to the control page went back to the model
[16:34] <magicaltrout> etc
[16:36] <zeestrat> Hey rick_h_, did you ever manage to scrounge together any of the backend folks regarding CI and the charm store?
[16:39] <rick_h_> zeestrat: yes, sorry. one sec
[16:40] <rick_h_> magicaltrout: so where's it say it's blocked? In the inspector floaty box thing on the left?
[16:41] <rick_h_> zeestrat: so, we were at a sprint and we had some sessions on it and so the team's working on changes to enable what has been called "agents" that we've used for communication between microservices but allowing users to create and manage agents themselves
[16:41] <rick_h_> zeestrat: so that's ongoing work from the sprint the teams doing and some of the terms might change up as we move from an internal details to a feature for all users
[16:41] <rick_h_> zeestrat: when we've got something test-able you can be sure I'll reach out and show off to folks in a juju show/blog post about using it
[16:45] <magicaltrout> rick_h_: https://imagebin.ca/v/3vetcUjfVsrQ
[16:46] <magicaltrout> https://imagebin.ca/v/3vettfOo8Psf
[16:46] <rick_h_> magicaltrout: bugging hatch (who's not in here that punk) to see if he knows anything to check there.
[16:47] <rick_h_> magicaltrout: sounds like a buggy bug, but not sure how it got into that state
[16:49] <magicaltrout> thanks rick_h_
[16:50] <rick_h_> gotta love it "did he reload" yea...we got that
[16:50] <zeestrat> rick_h_: Thanks. That sounds good. Please don't hesitate to ask if they would like some direct feedback on use cases before things land.
[16:50] <rick_h_> zeestrat: so the goal is going to be to expose the current stuff as a form of unblocking with a path forward that's cleaner I think.
[16:50] <rick_h_> zeestrat: so there will be some room for testing stuff out and then refining
[16:50] <rick_h_> zeestrat: otherwise we're starting from scratch which will take longer
[16:51] <rick_h_> magicaltrout: so he's going to check something and get back in a bit. Are the images ok to go into a bug?
[16:52] <rick_h_> magicaltrout: though I think he's going to ask for the actual wss coms to see if it's juju lying or us
[16:52] <magicaltrout> yeah i'm just trying to finish off the jaas bundles so nothing top secret in there
[16:52] <rick_h_> magicaltrout: ok
[16:52] <rick_h_> magicaltrout: do you know how to view the web socket messages in chrome?
[16:54] <magicaltrout> hmm
[16:54] <magicaltrout> it seems to have sync'd up rick_h_
[16:55] <magicaltrout> cause i refreshed for the websocket stuff
[16:55] <magicaltrout> and not it all green
[16:55] <magicaltrout> not much to show any more =/
[16:55] <rick_h_> magicaltrout: not/now?
[16:55] <magicaltrout> er
[16:55] <magicaltrout> yeah
[16:55] <rick_h_> magicaltrout: hmm, yea my bet is that the websocket that updated the status  got missed/dropped somehow
[16:55] <magicaltrout> fair enough
[16:55] <magicaltrout> other random question
[16:55] <rick_h_> magicaltrout: and that a fresh stack with the current status cleared up the confusion
[16:56] <magicaltrout> is it just me who feels the import export icons and the wrong way around? :)
[16:56] <rick_h_> magicaltrout: lol, issue filed. I always have to double check. I'll have to bug the design folks again as it's been a while
[16:57] <rick_h_> magicaltrout: at one point they were looking at more clear images to use
[17:02] <zeestrat> rick_h_: Gotcha. Looking forward to it. Thanks again!
[21:03] <bdx> cory_fu, reactive-peeps: https://github.com/juju-solutions/charms.reactive/issues/new
[21:03] <bdx> GEHHHH
[21:03] <bdx> https://github.com/juju-solutions/charms.reactive/issues/166
[21:03] <cory_fu> :)
[21:04] <cory_fu> bdx: Can you not use venv?  And does it fail if you do?
[21:05] <bdx> yeah, not using venv
[21:05] <bdx> it seems to fail in both situations
[21:06] <cory_fu> bdx: I feel like I ran into this before and found some workaround
[21:06] <cory_fu> But I don't recall what it was
[21:07] <cory_fu> bdx: Can you try adding setuptools_scm to the start of the wheelhouse.txt in a copy of layer:basic?
[21:07] <bdx> yes
[21:09] <cory_fu> bdx: Is this failing during build or during deploy?
[21:09] <bdx> cory_fu: deploy
[21:11] <cory_fu> bdx: From this comment https://github.com/pypa/pypi-legacy/issues/322#issuecomment-291733676 it sounds like we need to bump the pip version in layer:basic's wheelhouse.txt: https://github.com/juju-solutions/layer-basic/blob/master/wheelhouse.txt#L1
[21:12] <bdx> cory_fu: nice find!
[21:12] <cory_fu> bdx: Would you mind testing that and submitting a PR if it works?
[21:12] <cory_fu> I'm in the middle of something else
[21:12] <bdx> np
[21:13] <cory_fu> Thanks!
[21:14] <bdx> cury_fu: with your workaround https://paste.ubuntu.com/p/DG7PC9DGHj/
[21:14] <bdx> looks like its still failling down the line
[21:15] <bdx> I'll play with upgrading pip now
[21:32] <bdx> updating to pip>=9.0.2 still gives the same error
[21:33] <bdx> when I build the charm its using pip-10.0.0.dev0-py3.5.egg
[21:33] <bdx> https://paste.ubuntu.com/p/pYDyCdtfFg/
[21:34] <bdx> I'm guessing I need to find a way to get that version of pip into the wheelhouse of layer-basic then
[21:37] <bdx> that pip looks like it ships with the snap https://paste.ubuntu.com/p/ZdcYwJ2Yry/
[21:38] <bdx> hmmmm
[21:39] <bdx> there is some jiggery going on here
[21:39] <bdx> cory_fu: what have you gotten me into :)
[21:40] <cory_fu> lol
[21:42] <cory_fu> bdx: Have you tried specifying pip==10.0.0dev0 explicitly?  I'm not sure if that will allow dev versions or if you have to get charm-build to use --pre when building the charm
[21:44] <bdx> no, neither
[21:44] <cory_fu> bdx: Though, I don't understand why it's still failing with 9.x
[21:45] <bdx> I don't see that version as a release of pip, or a branch, or anything about it in the pip repo ... I'll try what you've suggested
[21:47] <cory_fu> bdx: I suspect that using pip==10.0.0dev0 won't work, anyway.  I wonder if we need an explicit `pip install setuptools_scm` in layer:basic just prior to it trying to install the wheelhouse.
[21:47] <cory_fu> I swear I remember hitting this before and having some sort of work-around
[21:47] <bdx> yeah it barfed on the version https://paste.ubuntu.com/p/8xP92Q87bv/
[21:48] <bdx> cory_fu: do you know how, and or why 10.0.0dev0 is used?
[21:49] <cory_fu> bdx: Yeah, it's used because of https://github.com/juju/charm-tools/blob/master/charmtools/build/tactics.py#L819-L821
[21:50] <cory_fu> bdx: Which points to https://github.com/pypa/pip/blob/master/news/4320.bugfix
[21:50] <cory_fu> Which is something we specifically had to fix for the snap
[21:50] <cory_fu> Wait, we didn't fix that, someone else had first, that's right
[21:51] <cory_fu> Anyway, it was something we hit in the snap
[21:54] <bdx> ok
[21:56] <bdx> I'm wondering if I use non-snap version if I would still hit this .... testing
[22:09] <bdx> fails the same no matter what version of charm I build with ... don't think thats the issue
[22:09] <bdx> cory_fu: https://paste.ubuntu.com/p/7hNPqVvmQc/ - could this be the root of this evil?
[22:10] <cory_fu> bdx: It could be but you said it happened even when using a venv
[22:10] <bdx> totally, doesnt the venv get system packages?
[22:11] <bdx> oooh, thats another option possibly
[22:12] <cory_fu> bdx: Yeah, there's a separate option for include_system_packages which defaults to false
[22:12] <cory_fu> bdx: Can I ask why you can't use a venv?  It's a better idea in general
[22:12] <bdx> cory_fu: https://github.com/juju-solutions/layer-basic/blob/master/layer.yaml#L14
[22:13] <cory_fu> bdx: Oh, yes, I'm dumb.  I forgot we went with true by default to make it more backwards compatible
[22:13] <bdx> cory_fu: I have cron jobs that the charm sets up that need to run at the system level
[22:14] <cory_fu> Try changing that to false and use_venv to true and see if it helps
[22:14] <cory_fu> bdx: Just run them with charm-env
[22:14] <bdx> oh I can use that in any python file?
[22:14] <cory_fu> #!/usr/local/sbin/charm-env python
[22:14] <bdx> the shebang?
[22:14] <cory_fu> Yep
[22:14] <bdx> oh saaweeeet!
[22:15] <cory_fu> bdx: Hrm.  I just realized, though, that if it doesn't have the hook context clues, it will have to guess on the charm path.  It will be fine if there is only one principle, and if your charm isn't a subordinate, but I might need to add a way to specify which charm, to be more explicit
[22:16] <bdx> ahh totally, its a principle
[22:16] <bdx> good to keep in mind though
[22:17] <cory_fu> Ok, so as long as you're not hulk-smashing charms together, it'll be fine.  And I'll add an option to disambiguate
[22:17] <bdx> ok sweet
[22:30] <bdx> cory_fu: I still got the error after changing include_system_packages to false and use_venv to true, I'm trying another deploy with setuptools specified in my wheelhouse.txt
[22:30] <cory_fu> bdx: Pretty sure that specifying it in wheelhouse.txt will be too late.  I think it has to be an explicit call to pip in layer:basic just before the wheelhouse install
[22:31] <bdx> ahh ok
[22:31] <cory_fu> i.e., right before this line: https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L81
[22:31] <cory_fu> Actually, no.  Before line 85
[22:31] <cory_fu> https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L85
[22:58] <cory_fu> bdx: I have to head out for the evening.  Good luck, and let me know if you figure anything out
[23:01] <bdx> will do