[00:15] Happy Wednesday #juju! [00:15] Anyone seen this error when trying to deploy an OpenStack bundle to MAAS? [00:15] Deploying charm "cs:ceph-269" [00:15] ERROR cannot deploy bundle: cannot deploy application "ceph": cannot add application "ceph": unknown space "storage-cluster" not valid [00:30] fun [01:43] marcoceppi, hmm cannot assign unit "ghost/0" to machine 0/lxd/0: adding storage to lxd container not supported [01:44] stokachu: you can't use storage in lxd (it would seem) [01:44] works just fine with localhost though, its only when deploying to a lxd container on a bare metal machine via maas [01:44] stokachu: sounds like some aggressive check code [01:44] yea [01:45] how do i remove a charm which failed to install? [01:46] i deployed a local charm, its install failed, i fixed the problem, but when i try to deploy it again it says the application has already been deployed [01:46] when i try remove-application, there is no output and the application remains on the controller [01:46] babou, juju resolved / [01:47] oh you probably want to juju debug-hooks / and fix it there so you can do a juju upgrade-charm from your working copy [01:49] sorry im quite new to all of this [01:49] juju resolved had no effect [01:49] debug-hooks ssh me into the container [01:49] you're saying I should edit the code from within the container instead of externally and redeploying? [02:00] the debug-log just keeps looping [02:00] saying the install hook is failing again and again [02:00] restarting the machine had no effect, it immediately began failing the install hook again [02:06] babou, juju debug-hooks / install [02:06] then in another terminal type juju resolved / and the debug-hooks window will show up an "install" tab [02:06] from there you can edit the currently installed hook to make it work [02:07] when you ctrl+d out of that terminal juju should continue on through the other hooks [02:07] i was able to upgrade it by running this command [02:07] juju upgrade-charm --force-units --repository=./buses buses [02:07] if all else works you'll get an active status and can then run `juju upgrade-charm` [02:07] where buses is the name of my charm [02:07] ah ok [02:07] and then running resolved [02:07] that works too :D [02:07] onward to the next error! [02:07] i should probably look at the help output more [02:08] babou, cool gl [02:08] got help from this page which i had to translate to v2 [02:08] http://marcoceppi.com/2015/01/force-upgrade-best-juju-secret/ [02:08] babou: o/ [02:08] ah yes i remember that post [02:09] maybe time to update it :D [02:09] yes, *updates post* [02:09] your posts aren't on github are they? [02:10] stokachu: no, wordpress [02:10] @marcoeppi i have no idea who you are, but i feel like im meeting a famous person [02:10] marcoceppi, ah ok [02:10] babou, he is famous [02:10] * marcoceppi blushes [02:50] babou: thanks for the updated commands, I've refreshed my blog post [02:54] marcoceppi: stokachu storage on lxd is on this cycle's roadmap of items. Couple of folks are working on it [02:55] marcoceppi: stokachu that's both lxd provider and lxd on another cloud (maas, etc) [03:50] does anyone know how to install a modern version of node to a controller? [03:51] the way this one does it, it installs 0.10.3 [03:51] https://api.jujucharms.com/charmstore/v5/precise/node-app-11/archive/hooks/install [08:30] Good morning Juju world [09:18] morning! === zeus- is now known as zeus === zeus is now known as Guest74290 [13:42] question about layers and interface-layers [13:43] goooo anrah gooooooooo! [13:43] I have a interface-layer which I (perhaps) want to peer on all nodes on my model [13:44] then i have base-layer on which all other apps are build on [13:44] apparently i can't use my peer-interface on all nodes? [13:45] as now it seems that all diffent apps have their own peering, even the interface is same on all applications [13:46] https://github.com/juju-solutions/interface-spark-quorum/blob/master/peers.py you have something like that? [13:46] yes [13:46] and you have the scope set? [13:46] yes, global [13:48] Relation Provides Consumes Type [13:48] test app-control app-control peer [13:48] test app-worker app-worker peer [13:48] it shows like that [13:48] what I would like to have is that all different applications would peer with each other [13:48] throught that layer [13:48] I might have wrong idea on my mind and I need ot change the approach, but that is how I planned it :) [13:49] that output looks right from my limited knowledge of peer relations. [13:49] You're wanting to peer app-control to app-worker as well? [13:49] Yes [13:49] yeah thats not happening afaik [13:49] kjackal: [13:49] Without requires-provides [13:49] help the poor person [13:50] I think that I'll have a beer and think this otherway around :) [13:50] hello magicaltrout [13:50] marcoceppi is answer emails [13:50] he'll know as well [13:50] let me see give me a sec to catchup [13:50] wat [13:50] peer relations across different charms [13:50] I think in a nutshell [13:51] does not exist [13:51] peers are only for unit <-> unit communication wihtin a single application [13:51] figured as much [13:51] there you go anrah [13:51] you can reuse the interface for a peer relation in the provides/requires though [13:51] but it's a seprate relations [13:52] I thought so [13:52] Then I'll have a beer and think other way around :) [13:52] have 5 [13:52] its more effective [13:53] basically the need is just to get ip-addresses of all units within a model [13:53] inside the charm [13:53] there must be a way to get that that marcoceppi can python up [13:54] anrah: ah, so, juju-info will be your savior [13:54] there is the juju-info interface that is implicit to all charms [13:54] anrah: but it's still a bit, dull [13:55] anrah: basically, juju-info is an interface you can require in your charm that allows you to connect to any application deployed. It only sets the `private-address` field so you can relation_get('private_address') but it requires the bundle or operator to add a relation to each component [13:55] anrah: without using the API, that's the best you can get [13:57] thanks! I'll try that === Guest74290 is now known as zeus` === zeus` is now known as zeus [14:30] Hello, when creating actions for a charm in python, if I keep the .py suffix, the action is not identified by the script name w/o the .py [14:31] what is the best approach to create actions in python ? just drop the .py ? [14:31] i did some yesterday [14:31] drop the .py and make sure you have a shebang in the top of the script [14:31] if I use a symlink (layered charm), when the charm is built, it drops the symlink & copy the file [14:32] magicaltrout: then it becomes an issue with unittests [14:32] tests are for wimps [14:32] :) [14:33] dunno, i asked marco the other day, he said, just write them in python so I did it like that [14:33] i've not tried testing them yet [14:35] rick_h, ping? [14:35] mattyw: otp pong [14:36] caribou: magicaltrout you could do this, a pattern some charms have produced: https://github.com/juju-solutions/vpe-router/ [14:36] that's a python stub for the actions/ and then a start of the reactive loop [14:37] it's not super clean, but it's something we're looking at cleaning up in reactive [14:37] caribou magicaltrout alternatively, put the heavy lifting in lib/charms/layer/ and import it from the action stub [14:37] unit test the library and don't worry about the stub [14:38] marcoceppi: hmm, good idea [14:38] or land stub's branch to avoid the stub [14:40] stub's stub is one approach [14:40] fwiw stub, we'll be looping back around to reactive 2.0 in the coming weeks, actions is one of the items on this list [14:41] magicaltrout: marcoceppi: that seems to do the trick as well : collect = imp.load_source('collect', 'actions/collect') [14:41] at the top of the test script, instead of "import actions.collect" [15:19] marcoceppi: I need to be writing actions in under two weeks time, in reactive 1. [15:55] anyone around for a question about contraints? [16:04] mattyw, dunno, best ask [16:05] pmatulis, according to the docs it's acceptable to set the arch constraints to no value. but: juju deploy ./ msql --constraints "arch=""" --series win2012r2 returns ERROR cannot add application "msql": invalid constraint value: arch= [16:06] marcoceppi: stub: Unless I'm missing some context here, actions in reactive aren't terribly difficult, just a little clunky. Totally functional, though. [16:06] mattyw, yeahh i saw something similar with 'mem' [16:06] mattyw, i think something changed recently [16:09] aisrael: I need actions that tie into the reactor. I can't do that without my patch, and I've seen no alternatives. [16:10] stub: This is what I've been doing for actions: https://github.com/AdamIsrael/vnfproxy [16:13] aisrael: Hmm... You might have reimplemented my branch from 6 months ago, but without the charms.reactive patches [16:14] stub: Dunno. I've been using actions with reactive like this almost since reactive was released. [16:15] * aisrael smells a blog post [16:15] aisrael: I don't recall it being brought up in Pasadena, and haven't heard it mentioned as an alternative [16:16] aisrael: (which is surprising, since I've been escalating this the last month) [16:17] stub: I'll make a point to call it out more. I didn't realize it was a pain point. I've been head-down working on open source mano and must have missed the discussion. :( [16:21] aisrael: I'll need to revisit my old branch, but I think all that is missing is the @action decorator and that is just a style choice. [16:22] stub: I'm happy to take a look at what you've got. I definitely think we can make actions easier to implement [16:22] aisrael: https://github.com/juju-solutions/layer-basic/pull/69/files was my template, which might look very familiar :) [16:23] Hah, sure does. Yours is pulling the action name directly from hookenv, which is something I wanted to add to my template. :D [16:24] aisrael: oh, my reactive patch is adding a new phase so the main action body is guaranteed to kick in before the rest of the reactive handlers. But I don't think I need that, at least for now. [16:26] aisrael: Ta. This unblocks me nicely :) [16:26] stub: Excellent, good to hear! [16:32] (amusingly, I used to have states too for actions but removed that from the patch on request ;) , https://github.com/juju-solutions/charms.reactive/pull/66 ) [16:38] stub: I'll try to weigh in on that discussion today or tomorrow. [16:38] cory_fu: I'll merge, but I could use a review https://github.com/juju/charm-tools/pull/298 [16:42] marcoceppi: Comment added: Do you think you could add a trusty series to the mysql layer's metadata.yaml to ensure that de-dupe works across layers as well (since you ran in to that while testing)? [16:42] cory_fu: sure [16:43] cory_fu: kwmonroe: Here is the error http://pastebin.ubuntu.com/23747121/ [16:44] marcoceppi: I think you lose the declared series ordering, so the preferred series (first) might change when you 'charm build' [16:45] probably should use ordered set then stub ? [16:45] marcoceppi: There is an ordered set? [16:45] I mean, "yes" [16:46] (hey, there is an ordered dictionary... wouldn't surprise me if there was an ordered set lurking around somewhere in stdlib) [16:46] it's not in stdlib, but there's a generally accepted class that implements it [16:47] cory_fu: kwmonroe: something very important cwr filed but it did not retrun an error code so the script tried to release the charms (even if the tests failed) [16:47] kjackal: There's a card on the board for that [16:49] cory_fu: so how can we move forward with this PR then? Should we have a check (eg grep FAILURE) against the output directory and stop the jenkins job? [16:49] kjackal: We should address the card on the board and make cwr return a proper exit code [16:50] kjackal: Ok, I know what the problem is. Your invocation with the charm doesn't have a reference bundle [16:51] kjackal: http://54.205.68.190:8080/job/charm-apache-tomee/2/console vs http://54.205.68.190:8080/job/charm-topbeat/2/console [16:51] ahhh. nice! [16:51] PM'd you the login [16:52] kjackal: Note the "echo 'bundle: /tmp/bundles/'" vs "echo 'bundle: /tmp/bundles/cs_beats_core'" [16:53] We need to detect no reference bundle and use the charm path / name instead [16:53] That, or make the reference bundle required [16:54] I'm leaning toward the latter [16:55] cory_fu: if we make the reference bundle required then we are losing all our customer base :) [16:57] I am not sure, I am a bit puzzled [16:57] stub: good catch on the ordering [16:58] cory_fu: so we will say if you want to make a charm you should first have a bundle for it before using the CI we are building? [16:58] kjackal: Part of the justification for reference bundle is that we want to heavily push for testing of bundles instead of charms. I don't think it's unreasonable to make that a requirement, but I'm not 100% set on it. [16:58] arosales: What's your opinion on that? ^ [16:58] kjackal: Pretty much, yes [16:59] * arosales reads back scroll [16:59] kjackal: Otherwise, you're back to having to write amulet tests to get any testing done. If you have even a trivial bundle, you can test it with matrix [17:00] we had talked about policy in making a reference bundle mandatory, thus I would be a +1 on making a reference bundle mandatory [17:00] a charm that doesn't have a bundle doesn't make much sense [17:00] I guess at a very minimum if someone did have a use case for a single charm they could still make a bundle of 1 charm. I wouldn't suggest it, but there is still that option [17:01] cory_fu: kjackal ^ [17:03] arosales: cory_fu: It is a chiken and egg issue here. Let say we want to have a CI for juju from day 1 of development. That means that day 0 should start with creting a bundle. And day 2 you can create a charm. [17:03] arosales: cory_fu: anyway, I am out for today [17:04] On Monday, i will look at the multiple controllers [17:04] bye [17:05] cory_fu: I found another problem, the way combine works [17:05] it's appending series list, instead of prepending [17:06] marcoceppi: Why is that wrong? [17:07] cory_fu: if lower layer is trusty, precise, and upper layer is xenial, trusty, order will be trusty, precise, xenial [17:08] but upper layer should take precedence [17:08] Ah, yeah [17:29] rick_h, thanks re: storage on lxd [17:30] stokachu: <3 [17:30] kjackal: I think in that case we could still just have a bundle of 1 charm [17:30] at a very minimum if that charm doesn't have any relations yet [17:44] hey all, so I'm using 2.1 beta3 to talk to maas 2.1. When I try to bootstrap, juju errors out because MAAS doesn't support the 1.0 api anymore. Is there a workaround for this? [17:46] marcoceppi - got a second? mbruzek and I are looking to share a controller we have hosted for the team, but we want teh shares to be admin level users [17:47] can you grant controller wide admin access? [17:48] lazyPower: grant superuser https://jujucharms.com/docs/2.0/users-models#controller-access [17:48] rick_h ta [18:24] anybody? How do I tell juju to use api version 2? [18:24] (for maas) [18:29] this is the error i'm getting [18:29] 2017-01-05 17:57:23 ERROR cmd supercommand.go:458 new environ: Get http:///MAAS/api/1.0/version/: dial tcp :80: getsockopt: connection timed out [18:29] ERROR failed to bootstrap model: subprocess encountered error code 1 [18:29] but curl on that url from the host works just fine [18:46] smgoller what version of juju? === frankban is now known as frankban|afk [19:17] so here's a weird one [19:17] that is completely left field at the moment, but I need to figure out how to deploy Juju stuff to this bad boy... https://www.tacc.utexas.edu/systems/wrangler [19:17] thats quite a powerful computer... [19:23] marcoceppi: Are you working on the append vs insert issue or is #298 ready for review again? [19:24] hey folks got a mysql question regarding the openstack deployment from juju [19:27] magicaltrout hoooo, DSSD rack scale? I bet that disk IO is *in-sane* [19:27] analytics with bandwidth of 1TB/s and 250M IOPS (6x faster than Stampede) [19:27] cory_fu: working on it [19:28] in the past (non juju deployed openstack) I would be able to log into my mysql servers and do a “show databases;” and voila my openstack dbs [19:28] now I juju ssh mysql/0 and then log into mysql and do the same and all I see is schema and test [19:29] h00pz - not to be daft, but i'm fairly certain our openstack offering uses percona [19:29] wouldn't that then be warehoused in percona/0 not mysql/0? [19:29] yah it does hence my complete lack of brain cells [19:29] well I wasn't going to go that far :D Its a common mistake [19:29] i do ask, as some people modify the bundle, and its not always obvious if thats the case [19:30] ubuntu@maas:~$ juju status | grep percona [19:30] mysql 5.6.21-25.8 active 1 percona-cluster jujucharms 246 ubuntu [19:30] ubuntu@maas:~$ juju ssh percona/0 [19:30] ERROR unit "percona/0" not found [19:30] so mysql/0 exists but not percona/0 [19:30] ok, they aliased the percona charm as mysql [19:31] makes sense to me so far. When you log into the percona unit you dont see any databases related to openstack right? [19:31] h00pz: right, you can name the applications once deployed whatever you want. [19:31] correct [19:31] hmmm [19:31] h00pz: e.g. you might deploy mysql twice, once as mysql-leader, and a second time as follower [19:32] i did a first-timer juju deploy of the basic openstack bundle and didn’t fiddle with it. [19:32] h00pz: so to ssh to each you'd use your names you gave it, mysql-leader and such [19:32] services are working fine i just need to edit a couple fields (i tied to delete vms when rabbitmq was down) [19:33] h00pz: right, so juju ssh mysql/0 should work for you in this case? [19:33] yes that does and once in there no darn dbs [19:33] h00pz: this was running before or is a new deploy? [19:34] been running fine (and still is) for over a month [19:34] im just trying to find the darn dbs to edit some stuff [19:35] h00pz: k, and how are you listing the dbs on the mysql? [19:35] ubuntu@maas:~$ juju ssh mysql/0 [19:35] ubuntu@juju-e039b2-0-lxd-1:~$ mysql -u mysql [19:35] mysql> show databases; [19:35] +--------------------+ [19:35] | Database | [19:35] +--------------------+ [19:35] | information_schema | [19:35] | test | [19:35] +--------------------+ [19:35] 2 rows in set (0.00 sec) [19:36] h00pz: can you get an interactive mysql shell and try "SELECT User FROM mysql.user;" [19:37] * rick_h dusts off some old mysql know-how [19:37] heh [19:37] im sitting next to h00pz btw [19:37] bildz: howdy [19:37] hey rick_h [19:38] its telling me to faq off, clearly no adequate perms [19:38] bildz: h00pz so my suspicion is that it's not showing all databases, but only the ones you have permission to see [19:38] bildz: h00pz so the ones for the OS aren't shown as the charms will create users/dbs with permissions in case that mysql is reused with other applications [19:38] e.g. a blog and a drupal and a ... [19:38] h00pz: bildz so try using "sudo mysql [19:39] yeah that's very odd [19:39] to get mysql running as root [19:39] sorry, w/o the " [19:39] well, you can mysql -u root -p [19:39] same thing [19:39] ok, same thing [19:39] bildz: but not mysql -u mysql? [19:39] bildz: so might be completely [19:39] im guessing we could parse the configs of services using mysql to see what it's using :) [19:40] sudo mysql [19:40] use mysq; [19:40] select User from mysql.user; [19:40] yeah basing that root has no passwd [19:40] bah, use mysql; [19:40] but its appearing to have one [19:40] right, it's ubuntu so you should be able to sudo from the ubuntu user [19:40] lazypower: I figured it out. it's not an api problem [19:40] it's a network connectivity problem. [19:41] the problem being the command was being executed on the bootstrapped controller, not the machine i was running the bootstrap from [19:41] smgoller ok good :) [19:41] and the controller couldn't talk to maas [19:41] glad you figured out the blocker [19:41] i wasn't entirely sure where to start but i figured best to start with what juju [19:41] and go from there [19:41] +1 for your debugging routine :) [19:42] yah so imi thinking that the only way to get into the openstack table space is from the root user WITH PASSWORD which we dont know or setup during the juju deploy [19:42] h00pz thats in /var/lib/mysql or /var/lib/percona respectively [19:42] * rick_h goes to deploy the percona-db charm and will be back in a sec [19:43] h00pz specifically /var/lib/mysql/mysql.passwd [19:43] on the controller ? [19:43] That should exist on any mysql unit you have deployed [19:44] thats a convention baked into the db charms when it auto-generates a password, it leaves a little cache file around on disk with the contents of the root users password, only readable by root [19:45] i have /var/lib/percona-xtradb-cluster but no mysql.passwd [19:49] i did a find and a grep for that file name, no dice [19:57] hmm [19:57] perhaps something changed and i wasn't aware its been a bit since i've looked at those charms [19:57] beisner, or thedac - any suggestions on how to get the root password for the percona charm these days? [19:58] lazyPower: h00pz bildz this is the only thing I can find atm https://help.ubuntu.com/community/MysqlPasswordReset [19:58] lazyPower: h00pz bildz lots of thing say that if not provided during install it creates on in the log file [19:59] but my deploy doesn't have a password line I can tell [19:59] howdy lazyPower, we typically set it on deploy, but i think there is a retrieval method. pretty sure it's in rel data. thedac may have more detail? [20:00] https://jujucharms.com/percona-cluster/#charm-config-root-password yea [20:00] hmm, /me wonders if you can change it via charm config? [20:00] bwahahahaha are telling me I can set it through the juju gui [20:01] h00pz: I'm testing it out :) [20:01] h00pz: hmm, doesn't look like it took [20:01] this —> Root password for MySQL access; must be configured pre-deployment for Active-Active clusters. <— [20:02] yea...that seems about right [20:02] lemme try [20:03] nope might have to try lazypower’s suggestion to break the passwoid [20:03] beisner ok, i hand't thought about the rel data being the key holder. Percona is non reactive correct? [20:05] h00pz: bildz yea, have to suggest to go the password recovery route [20:05] seems this is the way it works these days to keep things secure [20:05] k will do thanks guys. [20:05] cory_fu: I am doing two minor changes in "Store and serve CWR reports and build artifacts" [20:06] lazyPower, indeed, it's old style [20:06] kjackal: What changes? [20:07] indeed lazyPower that is some serious compute power [20:07] not sure how i'm gonna get charms deployed on int [20:07] it [20:07] but always like a challenge [20:07] cory_fu: the ref-bundle param should be mundatory in the build-on-release as well and something is not right in the descriptiona [20:08] kjackal: OK, thanks [20:23] cory_fu: last show stopper in this PR (at least for me) is the CWR not reporting a failure. How do we want to handle this in respect to the PR. Should we merge the PR now knowing that this needs to be fixed or should we keep the PR pending? [20:25] kjackal: It will have to be fixed in the CWR repo anyway, so I'd say treat it as a separate issue. [20:25] kjackal: However, hold on one sec, I have one more minor change to make [20:29] kjackal: Ok, pushed [20:29] cory_fu: Ok, so we move forward with the merge (as soon as you are done). One last question. What is more important: multiple controllers vs cwr retruning an error code on failure? If you ask me the latter because with that PR the build-on-* are not safe to be used. [20:30] Basically I am asking for priority of tasks for Monday morning [20:31] kjackal: Well, they're safe to use if you don't use push-to-channel, and that won't affect our demo next week, so I'd actually say the multiple clouds is higher. But they're both important. [20:32] Ok, multiple controllers it is then (unless someone else goes for it tomorrow) [20:33] marcoceppi: i get the feeling i'll know the answer to this but.... if i wanted to use the manual provider, apart from the controller, do the other units need to be Ubuntu? [20:33] magicaltrout nah you can manually enlist other series [20:33] i'm like 80 [20:33] % certain of this [20:33] its that last 20% that might bite you [20:33] lol [20:34] well i'll have a bunch of other issues as well so i'll need to fork and extend [20:34] but its worth investigating [20:37] cory_fu: Sorry to bother you again. Do we export the cloud credentials so that Matrix knows about them? What should happen in the case of multiple controllers? [20:38] kjackal: Ugh [20:39] kjackal: You're right. And now I realize that my work-around of using the env var won't work [20:40] kjackal: I can't believe I missed that [20:54] kjackal: Ok, I removed the exports. I'll have to figure out another way to do it [20:57] cory_fu: multiple controllers seems an easy task. Should be one day. [20:59] kjackal: cory_fu: where did the "usage: cwr [-h] [--result-output RESULT_OUTPUT]" get fixed? kjackal reported it in pr21 because the cwr invocation was --result-dir (not --result-output). was there a commit in layer-cwr to update the install location of cloud-weather-report? [20:59] kwmonroe: kjackal somehow had an old version of cwr [20:59] right cory_fu.. now i've got it. [21:00] and iirc, pypi wasn't updated, so layer-cwr did a clone/install (or wget master.zip or something) [21:00] kwmonroe: cory_fu: yes, I probably had an old cwr. Probably because I reused a jenkins deployment [21:10] hey guys, i'm working on a new charm and the install hook keeps failing with the following: http://pastebin.ubuntu.com/23748751/ looks to be related to wheelhouse, has anyone ran into this before? [21:12] lazyPower: looking that up for you now. The file is written on disk somewhere. Not where I expected. Give me a few. [21:16] lazyPower: no it is shipped of to leader settings: juju run --unit percona-cluster/0 leader-get [21:16] thedac aha! thats excellent. Thanks for the follow up [21:17] h00pz - still poking around? [21:17] no problem [21:20] kjackal: did you fix it by manually updating cwr on the jenkins slave? i ask because my cwr charm (on the jenkins unit) says to pip_install_from_git, so i know that's correct. however, the cwr installed on the jenkins system is *not* the same as the github repo. [21:21] it's like cwr is getting pip installed prior to the 'pip_install_from_git' and being skipped. [21:21] cory_fu: do you have pypi release rights to cwr? [21:21] (not that that's the right answer, just curious) [21:24] kwmonroe: I do not. Only ses [21:24] kwmonroe: I am back. So I fixed it by going to bed and woke-up realising what I was doing wrong [21:24] :) [21:24] kwmonroe: let me parse what you are sayiing [21:25] kjackal: let me help: i deployed the latest cwr-ci bundle and upgraded the cwr charm with the feature/reports-and-artifacts branch. [21:25] the jenkins principal has an old version of cloud-weather-report pip installed [21:26] yeap, that will not work. [21:26] it doesn't seem to be using the "pip_install_from_git(..., http://repo/c-w-r) [21:26] I just destroyed the model and tried manually from scrach [21:26] kwmonroe: It's working fine for me [21:27] not possible! [21:27] kwmonroe: As kjackal said, did you re-deploy the jenkins, or did you upgrade it from an old deploy? [21:28] kwmonroe: Of course, this would be moot if we had the workloads containerized. [21:28] cory_fu: this is a new jenkins deploy.. from ~kos. [21:28] Very strange [21:30] cory_fu: should cwr be in the /var/lib/juju/agent/cwr/.venv or on the system? it feels like i'm getting cwr installed outside of the cwr charm. and that feels bad. [21:30] I've deployed many times and not hit that, but it might be a heisenbug [21:30] kwmonroe: It should be in the system now, because it's not python3 so isn't compatible with the venv. Really, it should be in the containerized job env [21:30] heh, you keep saying "containerized" like we have time to do something about that [21:31] Yeah. :( [21:32] fix it!!!! fiiiiix iiiiiiit! [21:32] well, i had a stale ciuser preventing me from doing the build-on-commit, so let me tear all the way down again. if i deploy cs:~kos.greek/jenkins + local cwr from feature/reports-and-artifacts, i should have a cwr that supports --results-dir? [21:33]