/srv/irclogs.ubuntu.com/2020/03/30/#juju.txt

hpidcockwallyworld: k8s charms don't have an install hook correct?02:59
hpidcockconsidering dropping the noop upgrade op for the standard deploy op, but instead of firing the "install" hook it fires the "start" hook03:00
hpidcockthen the caasoperator has a caching downloader03:01
hpidcockand we use the deployer as normal inside the caas uniter03:01
hpidcockthen caas upgrade/install has a post install op that copies files to the pod03:01
hpidcockthat pod init op is also run on container init03:02
wallyworldhpidcock: they do have one now03:07
wallyworldit was added just before the sprint03:07
wallyworldhere's that action enablement PR https://github.com/juju/juju/pull/1137403:08
wallyworldwe could use the "normal" deployer if we rejig things i suspect03:08
wallyworldor we could serialse the deployer and actions etc03:09
wallyworldso that we don't unpack a new charm if there's an action running. we may even do that, would need to check03:09
hpidcockthe resolver is serialised and only runs one op at a time03:10
pmatulishow does JUJU_AVAILABILITY_ZONE information, set from MAAS, get propagated to a Juju model? and is this strictly used by the nova-compute charm?03:34
timClickslatest progress report is now available: https://discourse.jujucharms.com/t/juju-progress-report-2020-w13/284204:17
zeestratpmatulis: regarding usage, ceph-mon can use it for crush maps if `customize-failure-domain` is enabled: https://github.com/openstack/charm-ceph-mon/blob/master/config.yaml#L172-L17707:43
flxfoohi all07:50
timClickshi flxfoo07:50
flxfoolittle question about ~/.local/share/juju/ssh/juju_id_rsa... where does this one comes from? If I create a new user (syste/ and juju) I have this some ssh key... and if I try a juju-ssh or a simple ssh i have a permission denied... I would need to override that key by some generated in ~/.ssh ? I am not sure about the best practice here...07:51
timClicksall inter-agent communication is protected by TLS07:52
timClicksusing a self-signed CA07:52
timClicksso, it is created by the juju controller07:53
hpidcocktimClicks: wouldn't be the TLS cert, probably the ssh key that I think is created when you bootstrap. Not sure.07:58
flxfoosorry I think I am not clear at all :p ... when creating a new user, (unis system and juju) one should ssh-genkey for the system user, juju register the user, import that .ssh/id_rsa.pub key, and replace .local/share/juju/ssh/ with those keys?08:13
timClickshpidcock: good point (I was a bit too fast )08:21
timClicksflxfoo: I don't recall exactly what the steps are.. perhaps ask on https://discourse.jujucharms.com?08:22
jamachilleasa, when you work out the DEBUG level to set for the dependency engine, it would probably be good to send it to discourse to let others know that it at least exists, and they can come back if they ever want to use it.10:10
achilleasajam: will do10:28
stickupkidmanadart, whilst I'm doing some integration testing, I fixed my reload spaces-rework https://github.com/juju/juju/pull/1136611:02
stickupkidwho wants a quick PR that prevents me from swearing a lot https://github.com/juju/juju/pull/1137511:40
achilleasastickupkid: looking11:48
stickupkidhaha, need to fix the linter one sec11:49
achilleasastickupkid: can you try this on dev? cd provider/openstack; go test -check.f TestGetVolumeEndpointBadURL11:52
stickupkidachilleasa, what branch?11:53
achilleasadev/head11:53
stickupkidachilleasa, fixed my lint issue11:53
stickupkidachilleasa, worked for me11:53
achilleasadid you pull + make dep?11:54
stickupkidprobably not11:54
achilleasaon my branch I see a %q in there while the regex tests the unquoted error11:54
stickupkidPASS: cinder_test.go:914: cinderVolumeSourceSuite.TestGetVolumeEndpointBadURL0.000s11:56
achilleasastickupkid: not sure why but I get https://paste.ubuntu.com/p/PknhR9Zh9V/11:56
achilleasastickupkid: getting same error on develop too11:58
achilleasastickupkid: you wouldn't happen to use < go1.14.1 would you?12:00
achilleasagotcha! https://github.com/golang/go/commit/64cfe9fe22113cd6bc05a2c5d0cbe872b1b5786012:04
achilleasajam: I have rebased my relation-departed changes after the relation-created PR merged. It has already been reviewed but let me know if you want to take a quick look before I land it (https://github.com/juju/juju/pull/11356)12:10
rick_h_achilleasa:  wallyworld has a ping out to me around https://launchpad.net/bugs/1869275 and a need for an upgrade-step around the app relation work?12:46
mupBug #1869275: [subordinate] main unit did not get subordinate installed <juju:Triaged> <https://launchpad.net/bugs/1869275>12:46
rick_h_achilleasa:  if you have a sec can you read that and let me know what you think?12:46
* rick_h_ is processing email/irc ping backlogs12:46
achilleasarick_h_: reading...12:49
stickupkidachilleasa, I use go1.12 for work ;)12:53
=== hpidcock_ is now known as hpidcock
=== skay_ is now known as skay
achilleasastickupkid: 11375 approved with small req13:50
stickupkidachilleasa, nope ;)13:52
achilleasaall other tests pass with go1.14 ;-)13:52
rick_h_achilleasa:  looks like errors merged?14:08
achilleasarick_h_: did juju/errors need anything special?14:08
achilleasamy merge on Friday didn't do anything :D14:08
rick_h_achilleasa:  I just checked the settings, I updated the password in case it wasn't up to date14:08
rick_h_achilleasa:  and watch the logs to see it go by14:08
achilleasaall good then14:08
achilleasahml: still reviewing 11339; it's gonna take a while though14:35
hmlachilleasa:  it’s not blocking me, i’m storage right now, an independent piece14:36
achilleasarick_h_: looks like we are indeed missing an upgrade step from 2.6 -> 2.7 (https://github.com/juju/juju/blob/2.7/worker/uniter/hook/hook.go#L36 vs https://github.com/juju/juju/blob/2.6/worker/uniter/hook/hook.go#L32)16:47
achilleasaI might be able to add a small patch that attempts to recover the application name from the remote which means we won't need an upgrade step16:48
achilleasaor I can just add an upgrade step but if that won't ship with 2.7.5 and we won't have a 2.7.6 things might get interesting...16:50
achilleasaany preference?16:53
rick_h_achilleasa:  ok, on the phone atm. Preference would be the safest path for existing users. We don't/can't set a gateway release where "you have to upgrdae to X before you upgrade to Y"16:54
achilleasarick_h_: I guess the manual workaround is un-relate and then relate?16:55
achilleasarick_h_: so this seems to affect 2.6 -> 2.7 upgrades where a unit's state indicates a pending hook of type RelationChange16:57
achilleasarick_h_: maybe just having an upgrade step should be enough; you still need to run the steps if you go from 2.6 -> 2.8 right?16:58
pmatulishow does JUJU_AVAILABILITY_ZONE information, in a MAAS context, get propagated to a Juju model?17:01
rick_h_achilleasa:  sorry, off the phone now, processing17:04
rick_h_achilleasa:  let's sync up in the morning. You're EOD and I want to read this again. I mean we can add an upgrade step to 2.8 that's fine.17:06
rick_h_achilleasa:  but I'm nervous about current steps for existing users. So anyone on 2.7 will hit this and we've got a lot of stuff that's going to be upgaded from 2.6 to 2.7 with prodstack17:07
rick_h_achilleasa:  not everything can be unrelated/rerelated17:07
achilleasarick_h_: AFAICT it's upgrade 2.6->2.(6+x) where any of the units have a pending relation{Changed, Departed} hook (both check for non-empty RemoteApplication)17:08
rick_h_achilleasa:  oh, so the thought is this is missing within the 2.6 series vs 2.6 to 2.7?17:09
achilleasaso it's not everyone but can probably (?) happen with enough units17:09
rick_h_achilleasa:  yea... ugh17:09
achilleasathat's my understanding17:09
rick_h_achilleasa:  ok...thinking. I don't think there's a magic trick to this though...ugh17:10
achilleasaso we can add an upgrade step to the 2.7 line17:10
rick_h_achilleasa:  right, but but but I'm going to start crying lol17:10
rick_h_achilleasa:  please drop your notes into the bug before you EOD and then go enjoy the evening17:10
achilleasawell another option would be to offer a juju-unfck tool to attempt and fix the state files17:11
rick_h_achilleasa:  :/ not making me feel better lol17:11
achilleasabut we probably need the upgrade step anyway17:11
rick_h_yea, definitely need that. ...can the upgade step check the hook state before running?17:11
achilleasapatch 2.7.0?17:12
rick_h_e.g. can we promise we won't hit it?17:12
rick_h_achilleasa:  maybe. For tomorrow you can start off 2.7 with the idea of forward port and I'll try to find out tonight about what we're thinking with 2.7.17:12
achilleasaok. will drop my notes in the bug17:12
rick_h_I really wish I'd have been strong with the "release what we've got" because we're 5 shas in now...this would be 6...17:12
achilleasarick_h_: added a comment but skipped the proposal to patch 2.7.0 onwards as I am not sure if it's even feasible with snaps and whatnot17:26
rick_h_achilleasa:  ok, ty17:43
babbageclunkhave we introduced a go 1.13 dependency in develop?22:35
babbageclunkI'm getting an error building k8s.io/apimachinery/pkg/util/errors22:36
tlmbabbageclunk: good chance that was me as I started using that package22:38
tlmbut more than likely it was our upgrade to latest k8's client that triggered it22:39
babbageclunkyeah, sounds likely22:39
babbageclunkis it a problem?22:39
tlmsounds like it might be when we go to make 2.822:39
tlm?22:39
babbageclunkI'm not sure where we are with getting off go 1.10 - might just upgrade to 1.14 locally for now22:40
tlmwhat is the error so I an take a look ?22:41
babbageclunktlm: https://paste.ubuntu.com/p/r2zBVRVjhm/22:42
babbageclunkit's weird though - building juju works fine (with go 1.12), this only happens when I try to do an upgrade-controller --build-agent22:43
tlm1.17 kubernetes is built with go 1.13.822:45
babbageclunkhmm, upgrading to 1.14 didn't help :/22:45
babbageclunkoh no - I think it's because I was in the juju-restore directory, so it was trying to use modules!22:46
babbageclunksorry22:46
babbageclunkthat's really annoying22:46
tlm?22:46
tlmstill raises a good point, we are very lucky  that the upgrade hasn't given us more problems22:47
babbageclunkI'm going to try downgrading back to 1.12 and then run the upgrade from outside the juju-restore directory22:47
tlmit should fail as they are using the new errors stuff22:47
babbageclunkyeah that totally worked fine, somehow22:48
tlmmagic22:48
* babbageclunk shrugs!22:48
tlmall I can think of is we are not using that code so it's being compiled out22:49
babbageclunktlm: yeah, that might be it23:07
babbageclunka bit weird that just being in a go mod directory (for a different project) is enough to completely change how juju builds though23:08
tlmhpidcock: is the plan to get off 1.10 before 2.8 release ?23:08
tlmwhat is your GO111MODULE env set to ?23:08
hpidcocktlm: `go env` says empty string, so auto23:13
hpidcockthe plan is to get 1.14 in snap building at least23:13
babbageclunktlm: yeah it's unset in that shell23:14
hpidcockalso babbageclunk the github actions stuff builds with 1.1023:20
hpidcockso people can't land breaking changes23:20
babbageclunkseems like it was a weird interaction between modules and unused deps?23:21
babbageclunkit's fine for me now anyway, thanks guys!23:21

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!