[00:18] babbageclunk: we mis you [00:18] oops! omw [01:21] wallyworld: any idea why actions would just get queued as pending and never be run? [01:21] worse - one did run and then others never have. [01:21] (even on different units) [01:24] babbageclunk: the unit agent watches actions and reacts - it marks them as running when it executes them. so if an action is not being run, you need to look at the unit agent to see why [01:24] I can't see anything in the debug-logs, I'll have a look in the files. [01:25] thanks wallyworld [01:46] babbageclunk: i had a look at the action resolver in the uniter and there's no filtering - it really does just react directly to an action watcher that flicks across any queued/pending actions [01:46] babbageclunk: actions require the hook-execution lock [01:47] babbageclunk: look at the machine-lock file on the machine [01:47] and the juju_machine_lock command [01:48] nothing holding the lock - I can see the first run releasing the lock at the end, and I've had hooks run after that. Just not getting anything for the new pending actions I've added. [01:51] so that means that the watcher isn't seeing them for some reason? [01:51] maybe - you'd need logging in remotestate/watcher etc [01:52] babbageclunk: if you specify juju.apiserver to TRACE you'll see the details of all the api calls [01:52] that may help [01:53] ok, thanks [01:55] there's logging in remotestate/watcher for when the action watcher triggers, I can see it for the first one but not subsequent actions... [02:02] it's almost like the actions watcher has stopped. [02:06] kelvinliu: the issue is that the secret labels in 2.7 include model name. that's not needed because the secrets for an app are created in the app's namespace and we know the model. if we remove that label it will work as 2.6.9 correctly uses the juju-app=foo label [02:06] configmap also uses model label [02:07] we should only use model lable for global resources [02:07] ic. we should only have model labels for global resources [02:07] so it will be a quick fix [02:08] i will fix it after current pr landed. [02:21] wallyworld: so I just tested on gke, aks working fine, microk8s failed due to this issue https://github.com/ubuntu/microk8s/issues/757 I will test CDK on aws after lunch. [02:24] sgtm, ty [02:24] kelvinliu: is latest change pushed? [02:25] thumper: can I pick your brains about this? [02:26] the credential schema change, yes, but I need rename the func name and to see if other clean up/rebase etc need to be done. [02:26] that's ok, i might try and test too [02:31] babbageclunk: sure [02:31] in 1:1? [02:31] omw [03:23] kelvinliu: testing with CDK on AWS, the LoadBalancer service is not getting an external IP so bootstrap fails. not sure if that's related. might be an issue with integrator [03:28] wallyworld: my cdk is deploying, i will see if it's reproducable [03:30] kelvinliu: also, the nodes are missing the juju.io/cloud labels so i am raising a bug [03:31] yeah, it's missing https://pastebin.ubuntu.com/p/xZMPxCwJYn/ [03:58] wallyworld: i tested on cdk/aws, all good for me. I didn't have the LB provision issue. [03:59] must be my account or something [03:59] missing -- trust? [03:59] juju deploy charmed-kubernetes --overlay /home/ian/aws-overlay.yaml --trust [03:59] that's supposed to work [04:00] i use the same cmd and copied overlay from the doc https://pastebin.ubuntu.com/p/WMgVhNQyTF/ [04:05] yup, i did too [04:12] babbageclunk: did you sort out the actions thing? [04:17] wallyworld: nope [04:17] it's really weird [04:18] what charm? [04:19] wallyworld: it's my charm - but it doesn't seem like the watcher internals are passing along the update [04:20] wallyworld: babbageclunk : PTAL https://github.com/juju/juju/pull/10801 - corrected creation of cloud call context [04:21] babbageclunk: i'll try deploying a stock charm and see if actions work [04:24] babbageclunk: hmmm, works for ubuntu-lite with a simple action i added [04:24] wallyworld: and if you queue another action? [04:29] babbageclunk: works [04:29] this is on develop [04:30] ok, I think it's to do with jam's changes. Can I talk through with you a bit? I'm pretty unfamiliar with the hubwatcher code [04:31] wallyworld: in standup? [04:31] sure [04:44] anastasiamac: i have to duck out for a bit, a couple of quick initial questions have been left. i may be missing something [04:47] k [04:56] wallyworld: updated [06:04] looking [06:05] anastasiamac: while i look? https://github.com/juju/juju/pull/10800 small [06:05] hpidcock: did you need me to look at any wip? [06:06] wallyworld: k [06:09] probably monday morning, I'm pretty tired going to finish up a bit earlier [06:10] anastasiamac: with the network facade, that is a model facade right? so technically it is ok as is i would have thought? [06:11] as it always gets the right state when it is constrcuted [06:11] it's only controller facades that get controller state [06:12] and the same st is being passed in anyway [06:12] wallyworld: with network ine becaue we r using the code in common, we could potentially have a controller facade using it (dunno for what but possible ... since nothing stops us)... I did not want it to be a possibility [06:12] func NewNetworkConfigAPI(st *state.State ...) [06:12] wallyworld: i think with this experience, every time we need call context, we should construct it [06:12] so the change does not prevent that st above being passed in [06:13] i can see passing in the one st is useful though [06:13] and making the context off that [06:13] just trying to understand the change [06:15] wallyworld: with respect to networking facade, i.e. NewNetworkConfigAPI(...) like i said above - i don't think we should construct call context in constructor any longer... we should only construct it as needed in the individual call [06:16] yeah [06:18] wallyworld: hence i've changed the signature and removed call context creation from constructor... [06:24] anastasiamac: func (s statePoolShim) GetModelCallContext(modelUUID string).... is there an issue there? we Release() modelState inside the func but then pass modelState.State as a return value expecting it can be used outside the func call. [06:29] wallyworld: i don't think so.... the new implementation juts moves things around for convenience but is the same a old where we did call release in apiserver... and old one worked... so m sure the new one works too [06:29] wallyworld: i tested live :D [06:30] ok, that reference counting code ia a bit hairy and i need to re-learn it [06:30] statepool, modelstatepool, systemstate etc etc [06:31] the pr fixes the issue in the bug :) [06:31] and makes sure that all similar calls are not wrong [06:33] indeed, i just wanted to make sure there wasn't a st leak [06:33] or a premature release of state from the pool [06:33] i'm still not 100% but if it works.... [06:33] ur concern is appreciate and all the vali questions :D [06:33] valid* [06:33] i don't know the code well enough anymore [06:33] it works in practice :) [06:35] yeah.. that m.UUID() gave me hell... the model we get above is is not a full model... it's interfaced... but i think u r right, it's cleaner to add a method to Interface than to do the convulated dance [06:43] yeah, got to add it to mocks etc but cleaner prod code [07:01] wallyworld: Should I look at https://bugs.launchpad.net/juju/+bug/1849744 today? [07:01] Bug #1849744: k8s upgrade to 2.7 results in broken apps [07:03] manadart: nope, i already know the fix [07:03] just got to do a pr [07:03] it's about 3 lines of code and tests [07:04] i assume it's not blocking you? [07:08] wallyworld: OK. No not block me. [07:09] *blocking. [08:23] manadart: thanks for the bug link. I have approved 10779 [08:24] achilleasa: Thanks. [09:36] manadart, the branch stuff is still behind a feature flag right? [09:37] stickupkid: Yeah. "export JUJU_DEV_FEATURE_FLAGS=generations". [09:37] manadart, nice nice [09:52] manadart, are we calling the code internally to juju, branches or generations [09:54] stickupkid: It was initially just generations before we started using the "branch" name. So the packages, state collection and some types still use that nomenclature. [09:54] stickupkid: "branch" is generally the term for in-flight, not-committed generations. [09:55] stickupkid: One committed, the generation seq is bumped and the model has a new "generation", a high-water mark if you will. [09:56] There is a notion to make all changes use a branch implicitly, so each change will increment the model generation and you will be able to see a history of changes. [09:56] ^^ Once committed... [09:57] righto [10:09] manadart: if you want something small in the evening, a small PR regarding branches update https://github.com/juju/juju/pull/10796 :D [10:09] manadart: was not 100% sure whats the way right now to work on status is, so I just opened the PR so that we can discuss in case we do it differently [10:10] nammn_de: OK, I'll take a look. [10:39] achilleasa: https://github.com/juju/juju/pull/10802 [11:39] Oops. Looks like we have never handled space info in address migrations. [11:46] manadart: approved PR; one mock seems to have escaped the renaming [12:57] manadart, is there a way to see all branches ? [13:03] stickupkid: We are going to need such a command. [13:04] :-p [13:39] if someone wants to take a look at this small one. Changed the track err msg and update mockgen manadart ^ https://github.com/juju/juju/pull/10804 [13:40] and the one we were just talking about how we read charm, simon already added nice comments https://github.com/juju/charm/pull/297 . I added my opnion why this also can be bad what i added [14:36] manadart, before I add some qa steps, anychance of looking at the WIP https://github.com/juju/juju/pull/10803 [14:37] stickupkid: Yep. [14:47] noob question: how can i set the release of openstack, looks like it defaults to queens. Id like to set it to a more recent release. [15:05] N3tw0rK, if you're on an LTS the short answer is "UCA" [15:07] https://wiki.ubuntu.com/OpenStack/CloudArchive [15:09] pmatulis, ok is there anything juju specific that needs to be done once the UCA repo is added to the nodes? [15:12] N3tw0rK, are you installing O/S charm by charm or using a bundle? [15:12] pmatulis, charms [15:13] then this is the key syntax you need: [15:13] juju deploy --config openstack-origin=cloud:bionic-train [15:13] pmatulis, Thanks! [15:15] some non-openstack charms (e.g. ceph) will use a different option: [15:15] juju deploy ceph-osd --config source=cloud:bionic-train [15:16] achilleasa: we pass the space names as tags in some places… and _default is not a valid space tag currently [15:17] like constraints? [15:17] :-) [15:17] achilleasa: “juju spaces” [15:17] output [15:17] I sense a names.v3 PR coming soon... [15:18] hahahaha [15:19] achilleasa: it would help with the Config validation as well. [15:26] achilleasa: it’s a bit ugly really… i don’t think we want to allow just an name with understore in front [15:26] can we have the underscore in the end instead? [15:33] manadart, it doesn't look like we validate the branch name in terms of uniqueness [15:39] stickupkid: I think we do for active branches, but you can use the name of a committed one. [15:40] manadart, yeah, ok, so let's say if it's not committed you can't pick that branch name [15:40] manadart, i'll add that validation [16:48] manadart: looks like my pr was not problem free. I need to address this and come back to you, probably I will remove the additional api call [16:49] manadart: seems like init cannot access the api yet [17:37] I'm having trouble building juju 2.6.9; 2.1 builds fine. Any idea what I'm missing? http://dpaste.com/20WC576 [17:41] webstrand: Juju switch to dep since 2.1. Have you run "go make dep"? [17:41] *switche [17:41] *switched dammit. [17:42] Yep, I rebuilt all dependencies from Gopkg.lock [18:10] anyone else having charm build failures due to https://git.launchpad.net/layer-apt/ giving 503?