[03:41] <tlm> wallyworld: got 5 minutes for HO problem ?
[03:42] <wallyworld> sure soon
[04:00] <wallyworld> tlm: free now
[04:00] <tlm> k
[06:08] <babbageclunk> wallyworld: https://github.com/juju/juju/pull/11543
[06:08] <babbageclunk> I think it might have a problem with something in feature tests that rely on legacy leases though.
[06:38] <wallyworld> babbageclunk: looking
[06:40] <wallyworld> babbageclunk: yeha, there's a MachineLegacyLeasesSuite in cmd/jujud/agent machine_test
[06:40] <wallyworld> so a few tests to fix
[07:30] <hpidcock> wallyworld: quick pr https://github.com/juju/juju-db-snap/pull/2
[07:30] <wallyworld> sure
[07:31] <wallyworld> lgtm
[07:31] <hpidcock> danke
[07:59] <flxfoo> Hi guys, sorry to interrupt again. But someone is asking me some questions like
[08:00] <flxfoo> Is JUJU able to provision AWS resources or is managing only application deployment/layer?
[08:00] <flxfoo> and
[08:00] <flxfoo> If able to deploy AWS resources, is it able to deploy autoscaling groups? Or just fixed defined number of instances?
[08:00] <flxfoo> if anyone has some answers... you are welcome :P
[08:01] <timClicks> fixfoo: provision, yes to autoscaling
[08:01] <timClicks> except it's not autoscaling as per kubernetes, it's manual
[08:01] <timClicks> e.g. you ask juju to change the application's scale, and it will update all config on your behalf
[08:05] <flxfoo> timClicks: thanks!
[08:05] <flxfoo> still don't know what they are calling "groups"
=== salmankhan1 is now known as salmankhan
[10:35] <jam> timClicks[m], are you around?
[11:10] <manadart> achilleasa: Got a couple of small patches to come in under the one I am working.
[11:11] <manadart> This is the first: https://github.com/juju/juju/pull/11545
[11:15] <manadart> achilleasa: And this is the other: https://github.com/juju/juju/pull/11546
[11:16] <achilleasa> manadart: looking
[11:34] <hpidcock> PR for someone https://github.com/juju/testing/pull/148
[11:44] <hpidcock> another PR https://github.com/juju/juju/pull/11547
[12:14] <achilleasa> hml: got any time to look at 11547 ^^
[12:14] <hml> achilleasa: not really, i was thinking we needed to look at it though from email.
[12:14] <hml> achilleasa:  i’m tight on time - read thumper’s email on RC1
[12:14] <hml> :-D
[12:15] <achilleasa> hml: ah... that email! No worries, I will take a look then
[12:15] <hml> achilleasa:  ty
[12:27] <hml> achilleasa:  we should look at 11544 also
[13:30] <pmatulis> if i reboot a juju machine and immediately send it a command like 'juju upgrade-series 0 complete' is that guaranteed to work or do i need to wait?
[14:06] <pmatulis> hml, any idea? ^^^
[14:08] <hml> pmatulis: you could have a race, if the machine doesn’t go down fast enough, i’d think.  cannot guarantee.
[14:08] <hml> pmatulis:  a bit swamped at the momment to dig into how our CI tests this
[14:09] <hml> manadart: do you have an easy answer for pmatulis ^^^ ?
[14:11] <manadart> pmatulis hml: You should be able to send the command immediately. It needs the agent to do the work, so the command will implicitly wait for the worker to do its thing.
[14:11] <manadart> This is actually a known issue with it - reliance on a well connected client should not be a thing.
[14:13] <pmatulis> manadart, you're saying it will work out fine as long as the client maintains connectivity with the controller?
[14:14] <manadart> pmatulis: Yes, there is an open bug around it.
[14:14] <manadart> https://bugs.launchpad.net/juju/+bug/1855013
[14:14] <mup> Bug #1855013: upgrade-series hangs, leaves lock behind <seg> <juju:Triaged> <https://launchpad.net/bugs/1855013>
[14:17] <pmatulis> manadart, thanks a lot. i don't see anything about bad client:controller connectivity as the cause though
[14:19] <manadart> pmatulis: The symptoms line up with what we know about how the feature was written.
[14:21] <pmatulis> manadart, alright
[14:41] <manadart> achilleasa, hml, petevg: This is finally ready to go now: https://github.com/juju/juju/pull/11534
[14:45] <petevg> Woot!
[14:46] <petevg> achilleasa, manadart: if either of you have time to take a look at hml's draft for https://github.com/juju/juju/pull/11542 before your eod today, I'd appreciate it. That would help us try to sneak it in to the rc1.
[14:47] <manadart> petevg: I can look now.
[14:47] <petevg> +1. Thx!
[14:54] <achilleasa> petevg: I ... think ... I have finally managed to reproduce the kvm bug
[14:54] <petevg> achilleasa: nice! Was it a caching issue, or something else?
[14:56] <achilleasa> petevg: still going through my logs but I believe after we get the metadata from the stream and before we fetch the actual image, the base URL (which should point to the model-config) is left empty...
[14:56] <petevg> Interesting.
[15:03] <achilleasa> petevg: so if it's not correctly propagated, we get here: https://github.com/juju/juju/blob/develop/environs/imagedownloads/simplestreams.go#L77-L79
[15:04] <achilleasa> and this is why they fall back to cloud-images.ubuntu.com
[15:04] <achilleasa> looks like the streams index was fetched from the correct location but the image used the fallback
[15:04] <petevg> Aha.
[15:42] <hml> manadart:  ty for 11542, I pushed up some commands testing.  there is an acknowledged short cut…..
[15:46] <hml> achilleasa: manadart  how do i get the skipped github actions to run after converting a pr from draft to open?
[15:46] <hml> haven’t done this since we changed it
[15:47] <hml> no buttons are appearing to me.
[16:15] <pmatulis> manadart, hi, i got a similar question re actions. is there a timing concern for a unit that has had an action applied if the --wait option is omitted?
[16:18] <pmatulis> (my use case is pausing a unit prior to 'upgrade-series prepare' for the associated machine)
[16:19] <hml> pmatulis: what command are you using with —wait?
[16:19] <hml> pmatulis:  show-action-output
[16:19] <hml> ?
[16:19] <pmatulis> hml, run-action
[16:20] <pmatulis> (to pause the unit)
[16:20] <hml> pmatulis:  i’d recommend checking the action status at the very least.
[16:20] <hml> there is also a show-action-status
[16:20] <pmatulis> hml, realise that. just wondering if there is indeed a timing issue
[16:21] <pmatulis> (potentially)
[16:24] <pmatulis> to be clear, if keystone/2 is on machine 0 can i perform these two commands safely without waiting?
[16:24] <pmatulis> juju run-action keystone/2 pause
[16:24] <pmatulis> juju upgrade-series 0 prepare bionic
[16:49] <achilleasa> petevg: are there any plans for another 2.6 release? I have a fix for the kvm bug currently targeting 2.7 but can also do 2.6 -> 2.7 -> develop
[16:52] <achilleasa> hml: approved but without QA as I am near EOD
[16:52] <hml> achilleasa:  ty, i’ll get petevg  to do qa. :-)
[16:52] <hml> achilleasa:  do you know how to switch the github actions back on for a pr?
[16:53] <achilleasa> hml: no :-( do you need admin permissions?
[16:53] <hml> achilleasa:  dunno?  i’ll check with hpidcock later
[16:54] <petevg> achilleasa: I don't know whether we're planning another 2.6 release or not. Let's just target 2.7 and develop with the fix for now.
[17:50] <achilleasa> hml: can you take a look at https://github.com/juju/juju/pull/11550? Perhaps petevg can lend a hand with the QA steps as well. Since I am EOW it would be great if you (or anyone from APAC) could forward-port (should be a clean merge) to develop and update the bug with a link to the other RP
[17:50] <hml> achilleasa:  looking
[17:50] <hml> achilleasa:  you used guimaas to test?
[17:53] <achilleasa> hml: yes but the image server must be accessible by it (I used a VPS for testing)