wallyworldthumper: what did we resolve with respect to printing stuff to stderr where the output format was yaml. typically i think we currently have what's printed to screen is just yaml, but in theory if we printed stuff to stderr, the user could still redirect stdout somewhere to get the pure yaml. or do we want to stick with what i think we have now, which is anything printed to the terminal is just yaml01:19
thumperI think the answer was complicated...01:20
* thumper is in the middle of emails just now01:20
wallyworldok, let me know if you have a minute to discuss. calling an action, we might still want to print progress logs to stderr  even if format is yaml01:22
thumperI think our general answer was "if you specify a format, whether yaml or json, you get valid yaml or json on stdout"01:23
thumperwhy print logs to stderr if they are asking for yaml output?01:23
thumperwhy not have a stderr section in the yaml?01:24
wallyworldwe do01:28
wallyworldwe also want to show progress as it happens01:28
wallyworldso the experience is the same waiting for the action to run regardless of format01:29
thumperI can get on board with the progression messages being stderr01:29
wallyworldi am thinking yes also but wanted to get a +1 since it's a bit different01:30
wallyworldi guess it's easy to change it we get -ve feedback01:30
* thumper nods01:30
stubThe general use case is people want free form plain text output from actions, so worth optimising for that. YAML is very occasionally more conventient, and rare it actually needs to be machine readable. And even in those cases, its not always suitable as IIRC the existing API only allows simple strings strings as values.01:36
stub(and the keys have limitations too, such as not being able to use filenames because they tend to contain '.' characters)01:38
thumperwallyworld: https://bugs.launchpad.net/juju/+bug/1847084/comments/501:40
mupBug #1847084: Juju k8s controller is not getting configuration parameters correctly <juju:Incomplete by hpidcock> <https://launchpad.net/bugs/1847084>01:40
stubMaybe the action should choose between structured output (action-set), and unstructured (whatever I spit out)01:40
thumperstub: yes, we are optimising for plain freeform output for action execution01:40
thumperbut we still need to think of the edge cases01:40
wallyworldmy thnking is that if we are providing a feedback mechanism for long running actions via action-log, you'd want to see that regardess of chosen output format01:41
wallyworldwe do support structured vs unstructured too01:42
wallyworldstdout and stderr have their own fields in the yaml01:42
wallyworldand we also now print the action stdout and stderr when running with "plain" format01:42
wallyworldas well as the structured01:42
stubYes, that would be useful. My knee jerk thought would be action-log ends up on stderr with timestamps and maybe severity, and output ends up on stdout or wherever -o filename put it01:43
wallyworldthat's how it will work01:43
wallyworldthis is happenong in 2.7 edge01:43
wallyworldwith "juju-v3" feature flag01:43
wallyworldfeature flag gets the new "juju call" syntax01:44
wallyworldbut run-action also benefits from the improved output01:44
stubIf the action was able to choose its mode (via a hook environment tool), you might be able to make the transition seamless without a flag01:44
wallyworldthe flag just determines the juju cli syntax01:44
wallyworldall actions benefit from the newer output01:45
wallyworldthe yaml is the same but the plain output is improved01:45
wallyworldall actions also get a numeric id rather than a uuid01:45
stubJust thinking it is pointless the operator needing to specify --format=text for actions designed to spit out text or --format=yaml for actions designed to spit out structured data01:46
thumperugh... this is a breaking change in a point release...01:46
thumperbut I can't think of a way to have any compatibility...01:47
wallyworldthumper: breaking change?01:47
wallyworldids are opaque01:47
wallyworldnothing should depend on their format01:47
thumperthe id of the action is part of the interface01:47
thumperbut they do01:47
wallyworldthey are just a blob01:47
thumperand they have been uuids01:47
thumperand some tests check for uuids01:47
thumperI know there are openstack ones01:47
wallyworldsigh, that's bad behaviour then01:47
wallyworldids should be opaque01:48
thumperthey should01:48
wallyworldso let's go with that then01:48
thumperbut the when the docs said "id is a uuid", acceptance tests were written to ensure this01:48
wallyworldeasy to change some tests01:48
wallyworldi already updated the juju ones01:48
* thumper nods01:48
wallyworldand the only bad feedback so far has been due to a different bug01:49
wallyworldfeedback from openstack folks01:49
wallyworldwhere we sometimes leave out stdout in the yaml01:49
wallyworldthat's just a straight bug unrelated to action ids or such01:49
* thumper nods01:50
wallyworldstub: with --format, we don't really know what an action may or may not write to stdout etc (in addition to producing with action-set) so we display both. for plain output we print nicely, for yaml, it's as fields in the yaml doc01:51
stubRight. The action can tell you what it is going to do though01:51
wallyworldit can but who's to say an action won't do both01:52
wallyworldif there's no stdout we don't print it01:52
stubAn action can tell you that too if you let it01:52
wallyworldand it there's no structured data we don't print that01:52
wallyworldbut people have raised bugs if a field in the yaml is missing regardless of f it's empty01:53
wallyworldso in the yaml we're thinking well include all fields01:53
stubI'm not too fussed on including all fields, as personally I'd consider it legacy behavior. If I want YAML output, I'll format and spit it out myself, avoiding the limitations JUJU imposes on structured output (keys with a restricted charset, values only being strings)01:56
wallyworldthumper: i like your bug comment, let's see what happens from it. however, their main issue (one of them) is with the controller itself as it can't reach the charm store to download a charm01:57
thumperwell doesn't the controller have the proxies set internally?01:57
wallyworldwe don't do anything different for k8s vs iaas as far as i know. what do we do for iaas01:58
wallyworldbut for k8s, i think we would need to pass in thje proxies via pod env vars01:58
wallyworldfor the controller01:58
thumperis the controller in k8s or iaas?01:59
wallyworldin their case? i assume it's all k8s? not sure01:59
thumperdoes a k8s controller have a proxy updater worker?01:59
thumperas long as it does, the internal proxies are set01:59
* wallyworld checks02:00
thumperas long as there isn't any caas specific behaviour in the proxy updater worker02:00
wallyworldthumper: no, that's currently in the iaas only worker list02:01
thumperwell... that seems like a bug02:01
wallyworldyeah, seems so02:01
wallyworldwe were initially quite selective about what we ran up in a caas controller02:01
thumperalso... k8s controller for the client?02:01
wallyworldand networking/proxies we wanted to be cautious about02:02
wallyworldwhat do you mean "k8s controller for the client"?02:02
thumperit was an exclamation but with limited info due to public channel :)02:02
=== si is now known as Guest5009
hpidcockwallyworld: `juju bootstrap --logging-config "<juju.worker.diskmanager>=TRACE"` is that how you enable trace logging on a specific module?02:57
wallyworld--logging-config "<root>=INFO;juju.worker.diskmanager=TRACE"02:58
wallyworldonly <root> needs <>02:58
hpidcockawesome thankyou02:58
wallyworld; separator02:58
wallyworldcan add as many packages as you want02:59
hpidcocktimClicks: RE: https://bugs.launchpad.net/juju/+bug/1847128 how long did you wait for it to finish initialising?03:14
mupBug #1847128: [2.7] ceph-osd stuck in "agent initializing" <juju:New for hpidcock> <https://launchpad.net/bugs/1847128>03:14
timClickshpidcock: I deployed then ran juju-wait for ~30 mins03:15
hpidcockoh wow03:15
timClickssent SIGINT then checked status03:15
hpidcockyeah mine resolved within 5min03:15
hpidcockreally weird03:15
timClicksis it possible that the snap build is somehow different than your env?03:20
hpidcockyeah that's what I'm thinking03:21
timClicksnew tutorial up https://discourse.jujucharms.com/t/218904:36
timClicksworthy of some peer review if anyone has a minute or 204:36
babbageclunkwallyworld: review plz? https://github.com/juju/juju/pull/1070404:51
babbageclunkI'm just testing it locally04:51
wallyworldbabbageclunk: looking05:05
babbageclunkwallyworld: actually, trying it out it's really obnoxious - changing it to log once and then only every 30s05:06
babbageclunkwallyworld: I have to drop now, I've sent a status update. Could you babysit the PR and build the snap?05:32
babbageclunkwallyworld: oop, looks like you might be on the phone - ping me on telegram if you need me.05:34
wallyworldbabbageclunk: will do, i'll baby sit ty05:41
wallyworldyeah otp05:42
=== exsdev0 is now known as exsdev
timClickswallyworld: thought you might like to know https://discourse.jujucharms.com/t/new-emoji-available/219005:55
hpidcockwallyworld: PR for you to check out https://github.com/juju/juju/pull/1070505:56
wallyworldhpidcock: will do05:56
wallyworldtimClicks: pretty05:56
timClickswallyworld: I know how much you love social media05:57
wallyworldoh joy05:57
hpidcockit's on 2.6 because I don't know if we want it there or in develop. Let me know.05:57
wallyworldhpidcock: so you found a real issue05:57
wallyworldwe can land in 2.6 just in case05:57
hpidcockwell 2.6.10 would be broken05:58
wallyworldas we have probs broken 2.605:58
wallyworldwe may need to halt 2.6.1005:58
hpidcockessentially all the matching logic is weird05:58
hpidcockand it probably never worked as it originally was intended05:58
hpidcockI just happened to break it05:59
wallyworldso it worked by coincidence05:59
wallyworldhpidcock: so the core issue was with dealing with planBlockInfo?06:03
hpidcockyeah, if it didn't match it would just skip checking if any other unique fields match06:04
wallyworldi thought plan info was just for oracle, hmmmm06:06
wallyworldalso i just left a comment, see what you thimnk06:06
wallyworldhpidcock: got to go deal with something, i'll check PR again soon. need to digest the changes as it is quite fragile06:11
hpidcockwallyworld: yeah agreed. I don't think it will break unless we are matching with some non-unique values... which would be concerning.06:12
babbageclunkI don't think the golangci-lint people understand what deprecated means.06:37
babbageclunkoh no, I take it back06:38
wallyworldhpidcock: i left another comment on the PR, trying to grok the logic. is there an example of how it failed and how we fixed it?07:43
wallyworldwould simply removing the continues be enough, without the loop logic changes?07:44
wallyworldit would be good to see what we were matching on to understand what tripped up the logic07:44
stickupkidbabbageclunk, haha08:17
nammn_deis there a fast way to force a bootstrap to a specific juju version?08:32
nammn_dee.g. client is 2.7, is there a way to force 2.6 or do i have to checkout 2.6 first?08:32
nammn_detimClicks: my client then returns he can only bootstrap 2.708:33
achilleasanammn_de: snap install juju?08:38
timClicksnammn_de: reading the help text more carefully, it looks like this is only possible within the same minor release08:38
timClicksnammn_de: snap refresh --channel=2.6/stable juju08:38
nammn_detimClicks: thanks achilleasa: hmm yeah good idea, is usefull :D08:38
achilleasanammn_de: just be careful with paths, to be sure '/snap/bin/juju bootstrap...'08:39
timClicksnammn_de: you can see which channels are available via `snap info juju`08:40
nammn_degreat thanks guys works like a charm, probably setting an alias for the snap juju to not get confused :D08:42
achilleasanammn_de: "works like a charm"... I see what you did there ;-)08:44
stickupkidOR just setup go path to take precedence over snap path08:46
nammn_destickupkid: luckily it already does, puh08:46
nammn_desomeone might  wanna take a look at this "small change"? https://github.com/juju/juju/pull/1068509:51
Fallenourhey icey manadart have you guys seen something like this before: https://conn-check.readthedocs.io/en/latest/tutorial-part-3.html09:55
Fallenour$ # all checks on all units09:55
Fallenour$ juju run --service my-service-conn-check 'actions/run-check'09:55
Fallenour$ # all checks on just unit 009:55
Fallenour$ juju run --service my-service-conn-check/0 'actions/run-check'09:55
Fallenour$ # nagios (not including no-nagios) checks on all units09:55
Fallenour$ juju run --service my-service-conn-check 'actions/run-nagios-check'09:55
Fallenour$ # nagios (not including no-nagios) checks on just unit 009:55
Fallenour$ juju run --service my-service-conn-check/0 'actions/run-nagios-check'09:55
FallenourSorry for the wall of text everyone.09:55
Fallenourrick_h, your thoughts?09:55
nammn_deachilleasa stickupkid in upgrade code, do we have to expect someone upgrading from really old juju version (e.g. 2.0) using upstart to new 2.7 with systemd?10:31
hpidcockwallyworld: removing the loops changes the priority intention that was originally there. I'll add a unit test tomorrow that matches what we were seeing.10:33
hpidcockremoving the continues*10:33
wallyworldi'd be interested in the aws dev info etc as well10:33
wallyworldto see how the bug manifested10:33
wallyworldi need to look at code again. i did tink removing continues was all that was needed10:34
nammn_deachilleasa: what command do I have to run to upgrade from 2.6 to current development juju with the cli?  Is it "juju upgrade-controller" will the upgrade steps defined run then?10:59
achilleasanammn_de: yes, just make sure that you use the correct cli version when upgrading11:00
nammn_dee.g. for correct understanding: "juju2.6 bootstrap ...", followed by "$GOPATH/bin/juju upgrade-controller --build-agent" will trigger the upgradesteps to 2.7, right?11:01
achilleasaI think that should do it...11:04
nammn_dewallyworld: does it still work for you to attach to controllers with delve? For me it returns "could not find debug info", did we change a flag while building?11:17
nammn_dewallyworld: ahh I need to set the debugflag to not omit debug information11:19
nammn_deduring trying to running the upgrade steps my model died between 2.6 and 2.7 because `ModelLogfileMaxSize` was added but didn't exist or so. Is that expected? For now I "just" added an upgradeStep to add that value12:33
hmlnammn_de: there should never be a failure during upgrade like that12:36
hmlnammn_de: does it happen upgrading without your change as well?12:37
nammn_dehml: maybe i did some weird stuff, let me try that12:38
nammn_dehml: yeah seems to be the case Let me get the pastebiun12:47
nammn_dehml: what I did, bootstrap snap juju 2.6, get local code 2.7-beta, run `juju upgrade-controller --build-agent` without my upgrade code. Leads to the pastebin12:50
nammn_de server is down, given status, ssh into and digging into machine log leads to: https://pastebin.canonical.com/p/JpHV2fMSXH/12:50
hmlnammn_de:  that’s a bug.  was this 2.6.8?12:51
hmlor 2.6.9 i guess the released version is12:51
nammn_defrom 2.6.9 -> 2.7-beta112:52
rick_hmorning juju12:53
nammn_derick_h: morning12:53
nammn_dehml: trying with the newest develop version, my last one was 9 commits behin or so12:54
nammn_deyeah same, leads to machine down12:55
Fallenourmorning rick_h13:34
Fallenouroff the wall question, but does anyone have a diagram which can visually represent the place terraform holds in the CI/CD process13:34
hmlmanadart:  i wonder if that defaultSpaceName arg was just poorly named.  That the intention was to have a default space on a per machine basis:  https://github.com/juju/juju/blob/develop/network/containerizer/bridgepolicy.go#L288  but the code never got there14:14
nammn_deHow do I upgrade a local agent from a model?15:49
hmlnammn_de:   did you run juju upgrade-juju after upgrade-controller?15:56
hmlnammn_de: every model is upgraded by the user the after controller is upgraded15:56
nammn_dehml: does upgrade juju copies the jujud from the controller?15:57
hmlnammn_de: there is an agent (tools) tar ball which is copied and unpacked15:57
hml on each juju machine when juju upgrade-juju is called on the model15:58
pmatulis1hml, upgrade-model, upgrade-model :)15:58
nammn_deif i do "juju upgrade-controller --build-agent" my local one is deployed and installed, it also updates the tar ball, which then gets redistributed, right?15:58
hmlnammn_de: yes, but you only after you upgrade the model.  that line only upgrade the controller model15:59
nammn_dehml: got it, thanks 🦸‍♀️15:59
nammn_desomeone want to take a look and mind giving some feedback? https://github.com/juju/juju/pull/10696 I am not 100% safe about the upgrade steps. It did seem to work, but cannot guarantee as they are not automated (?) I only added the upgrade step as it did not work otherwise. But it's all written in the commends in the PR16:57
stickupkidnammn_de, send an email to thumper and ask him to review, I wonder why he didn't add them17:02
nammn_destickupkid: will do!17:03
timClicksFallenour: it would be really interesting to see whether that subordinate still functions19:00
timClicksweirdly, there are no links in that docs site that point to the source code repository.. which makes the source code hard to inspect :/19:02
=== AvondZon_ is now known as AvondZon

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