[00:00] menn0: I see you are the lucky winner of https://bugs.launchpad.net/juju/+bug/1660087; it may still be the same underlying cause as https://bugs.launchpad.net/bugs/1635311, so that might be useful background, depending on what you find in the profiling data. [00:00] Bug #1660087: Controller and all models unresponsive [00:00] Bug #1635311: juju2 eating CPU, units in error [00:05] blahdeblah: ok, thanks for joining the dots [00:05] menn0: No guarantees ;-) [00:35] wallyworld, ping [00:36] hey [00:36] heya wallyworld did you want to meet in our 1x1 HO? [00:36] alexisb: give me 5? [00:36] or 3 [00:44] * alexisb taps her fingers impatiently on her desk [00:44] and stares at wallyworld [00:44] alexisb: just looking for hangout, it's gone :-) [00:45] https://hangouts.google.com/hangouts/_/canonical.com/alexis-ian [00:45] you just have to look into the past [00:52] Bug #1660522 changed: Un-removeable "life: dead", "agent-state: pending" agents

[00:55] menn0: back [01:09] axw (or anyone else) - is there any way to have the ec2test server return errors for operations? [01:11] axw: Or do I need to introduce indirection in the provider and patch things out with mocked ones? (that seems to be what the other tests do) [01:13] * redir looks into the future and sees a beer [01:13] * redir eods [01:13] maybe [01:13] but should find a bug to look at tomorrow [01:14] babbageclunk: I don't think so, but don't know for sure. what error do you want to return? [01:16] axw: I just want to test a few error paths in my code. [01:17] axw: Actually I'm not sure there's much need - the error handling is fairly trivial in this case. [01:17] for full coverage you probably need a layer of indirection. for more specific validation errors (for example), it would make sense to update ec2test [01:19] axw: I'm not looking for any specific validation errors or anything, so I think this is probably fine. [01:21] axw: was having lunch. i'm back now too. [01:21] axw: quick hangout? [01:23] wallyworld: for bug 1602192, you just want me to say that it'll b better communicated thru status msg and will b addressed in 2.2? [01:23] Bug #1602192: when starting many LXD containers, they start failing to boot with "Too many open files" [01:24] let me look, one sec [01:24] menn0: sorry missed your msg, yep [01:24] menn0: see you in standup HO? [01:25] axw: yep, see you there [01:26] anastasiamac: yeah. i think we also discussed that in clouds, there was no guarantee that the images could support those particular kernal parameters so best not to try and guess and better surface the error [01:26] wallyworld: ack [01:27] that was the advice from nic and adam anyway [01:27] juju often gets stuff wrong when it tries to guess, so we are trying to be more explicit [01:53] I often get stuff wrong when I try to guess [01:54] axw: can you take a look at this if you get a chance? https://github.com/juju/juju/pull/6900 [01:54] babbageclunk: okey dokey [01:57] axw: thanks! [01:59] babbageclunk: done [02:01] axw yay! Yeah, much easier than the Azure one (although a lot of that was me getting to understand the SDK), [02:34] babbageclunk: query is the model migration fix in for aws re: the bug where destroying the origin controller borks things? [02:41] veebers: no - the AWS specific bit is done, but I still need to do the part that calls that from the migration. [02:41] babbageclunk: ack thanks, I'll leave that out from my test script for today then :-) [02:42] veebers: sorry - I'll let you know when it's all done. [02:42] babbageclunk: nw, was just checking before I try it out in my manual testing. Also interested in GCE [02:43] veebers - gce's in the same state. [02:44] Hmm, there's no reason I can't do the migration bit now, if it would help? [02:44] ack. it's not blocking me really at the moment, I'm just doing some manual testing for migrations in the public clouds [03:34] axw: how far away are you with that lxd credentials fix? [03:36] menn0: not too far, just updating tests [03:36] axw: cool. I ask b/c I have a fix for the charm URL migration issue but it would be easier to QA if your fix was in place. [03:36] axw: I can work around it regardless [03:42] menn0: sorry was otp [03:42] menn0: I can push my branch if you want to use it incomplete [03:42] axw: nah it's all good [03:59] axw, babbageclunk or wallyworld: https://github.com/juju/juju/pull/6901 [04:00] looking [04:07] menn0: i think i missing something - the sequence assigns rev numbers 1,2,3,4,5 etc for each base charm url right? [04:07] wallyworld: yes [04:08] so if the source model has had charm rev 4 deleted, and migrates rev-1 rev-2 rev-3 rev-5 rev-6, won't that stuff up? [04:09] wallyworld: no b/c the revision is set to max(charm URL rev, next seq value) [04:09] wallyworld: for each charm upload [04:09] ah, right ok [04:09] wallyworld: the rev in the uploaded charm is used if possible, unless the sequence is beyond that value already [04:10] ok, thanks. lgtm [04:10] wallyworld: thanks for looking [04:10] np. was a pretty easy fix in the end [04:16] wallyworld: a bit fiddly but not too hard [04:17] thanks to babbageclunk too [04:17] wallyworld: it looks like there's no method in goose corresponding to the update volume metadata API call: https://developer.openstack.org/api-ref/block-storage/v3/#update-a-volume-s-metadata [04:17] wouldn't surprise me [04:17] i don't know for sure off hand though [04:17] wallyworld: Ok, cool - just checking I wasn't missing something. I'll add it then. [04:17] babbageclunk: if you do change goose, there's a drive by that needs doing [04:18] i'll find it [04:18] wallyworld: It's not "upgrade it to the new version of the openstack API" is it? [04:18] it's a message that is logged as INFO that should be debug [04:19] that could be the message, can't recall exactly [04:19] wallyworld: Oh yeah, that I can handle. [04:19] wallyworld: No I meant a big thing being jokingly described as a driveby. But changing a log level I'll do. [04:20] just as well :-) [04:20] actually, it's worse than info, it's warning [04:20] line 220 of client/apiversion.go [04:28] * menn0 is done for now. back again later. [04:38] wallyworld: ok, I'll change that too. [04:38] ta [04:41] wallyworld: Do you mean 229? https://github.com/go-goose/goose/blob/v1/client/apiversion.go#L229 [04:41] babbageclunk: yis (that's kiwi for yes) [04:42] thenks [04:53] Hello Experts I working on to develop charms . I have two questions 1) Is there any way to fire command from one juju unit to another ? 2) Is there a way to copy file from one unit to another ? [05:07] Lalit: juju itself does not provide any way to do those things. charms can coordinate with each other to do it using relations, though [05:07] wallyworld: can you please review https://github.com/juju/juju/pull/6903 [05:07] sure [05:11] Hello Andrew thank for replay . if possible could you please let me know any charm doing this So that i can refer that charm [05:50] Lalit: I'm sorry, I don't know of any. I suggest trying in #juju or on the mailing list [06:28] wallyworld: you're working on https://bugs.launchpad.net/juju/+bug/1643430? [06:28] Bug #1643430: Unassigned units in an error state cannot be removed [06:49] axw: yeah, in between things, just fixing a state changing too quickly error. i also need to think about the fact that we can't assert A && B across collections === frankban|afk is now known as frankban [09:23] for those around that can review: https://github.com/juju/juju/pull/6905 [09:23] frobware: perrito666: ^^ [09:59] Jam it's 7am here once I finish waking up I'll take a look :) [11:12] Hi Folks, [11:12] Have a question. Is there a way to call config-changed hook in charm after relation hooks? === tinwood is now known as tinwood_afk [12:12] Hey folks. Have a query [12:12] need to fire config-changed hook after all relations are made. Any way to do this? === freyes__ is now known as freyes === tinwood_afk is now known as tinwood [15:49] Hey. Can anyone here help me with a query on hooks? [16:00] pranav_: sorry almost no one is here you had a query regarding config hook right? [16:00] pranav_: most of these will most likely get a more useful answer in #juju [16:01] Oh ok thanks. Will try there [17:03] morning juju dev === mskalka|afk is now known as mskalka === frankban is now known as frankban|afk [19:14] new kernel brb [19:14] or bbiab === jog_ is now known as jog [20:33] perrito666, redir: anyone familiar with the openstack API? [20:34] Babbageclunk slightly [20:35] perrito666: I'm adding a SetMetadata method to cinder volumes in goose. [20:36] perrito666: My reading of the docs says I want PUT - https://developer.openstack.org/api-ref/block-storage/v3/?expanded=create-metadata-for-volume-detail,update-a-volume-s-metadata-detail#update-a-volume-s-metadata [20:36] perrito666: Only confused because the corresponding method for servers is POST: https://developer.openstack.org/api-ref/compute/?expanded=create-or-update-metadata-item-detail,update-metadata-items-detail,create-or-replace-metadata-items-detail#update-metadata-items [20:37] perrito666: There's also a POST version of the volumes request, but I think PUT is what I want since it explicitly allows partial updates to the metadata (so I don't need to get all of the tags to update one). [20:38] Definitely not that into it :) [20:38] perrito666: :) [20:39] perrito666: I'll do PUT for now anyway. [20:41] babbageclunk: vry minimally [20:42] babbageclunk: PUT sounds correct to me [20:42] redir: sweet, thanks [21:38] perrito666: do you know how I can run the cinder live tests for goose? [21:38] perrito666: Can I use creds from cloud-city? [21:49] perrito666: hang on - following along in the nova tests it looks like maybe I don't need to. [21:51] * redir lunches [21:54] babbageclunk: yes you can [21:56] perrito666: I couldn't work out where to get all of the cred bits: I can find URL, user, secret (I assume this can be password), region and tenant. What should domain be? [21:58] babbageclunk: let me peek at cloud city [21:58] babbageclunk: you need the credentials for something other than bootstraping? [21:59] otherwise just JUJU_DATA=/path/to/cloud-city [22:00] perrito666: no, trying to run the goose live tests - that seems to need 6 env vars set. [22:01] perrito666: Ah, looking at the credentials struct, domain is tagged as optional. [22:02] perrito666: Ok, I'll try this - thanks! [22:02] babbageclunk: source ec2rc [22:02] :p [22:02] ah sorry openstack [22:03] babbageclunk: I used to have hp cloud for tests in openstack [22:03] now I have no idea what we use, last time someone gave me one [22:04] perrito666: ok, if this doesn't work I'll ping some of the qa folk, thanks === mskalka is now known as mskalka|afk [22:30] wallyworld: ping? [22:30] otp [22:34] babbageclunk: i can ping you after release standup [22:34] wallyworld: ok, just trying to work out how to run goose live tests - if you don't know then no worries. [22:35] babbageclunk: unit tests? [22:35] ah live tests [22:35] wallyworld: yup [22:35] i can help a bit, soon [22:35] wallyworld: ok, awse - thanks [23:05] babbageclunk: i have to duckout real quick, but basically if you have your .novarc and source it, the env vars should be set up so you can go test --live [23:05] from memory [23:05] babbageclunk: but realistically, nowadays, a bootstrap / live functional test is probably best [23:06] wallyworld: what's a .novarc? (I know nothing about openstack) [23:07] ah, oh. novarc contains your credentials [23:07] and tenant etc [23:08] wallyworld: ok, I'll do some testing once I've done the migration master part [23:08] you have not been givwn those for canonistack? [23:08] ok [23:08] wallyworld: I've got cloud-city, so I can use those I think [23:09] yes you can [23:09] there should be a novarc file there [23:09] save it as ~/.novarc [23:10] then you juju autoload-credentials [23:11] babbageclunk: i have to pop out for a bit, back soon [23:56] anastasiamac, ping [23:56] hi alexisb \o/ [23:57] heya anastasiamac, sorry I missed standups today [23:57] u haven't yet. it's now [23:57] was curious where we are with the beta5 release [23:57] ah ok [23:57] I will join [23:57] it's ready to go. last PR just landed