[00:00] <wallyworld> thumper: PR to move proxy update worker to common manifold set for use in caas and iaas https://github.com/juju/juju/pull/10731
[03:10] <anastasiamac> wallyworld: and PTAL https://github.com/juju/juju/pull/10732 - fixes for 'regions' command
[03:10] <wallyworld> ok, real soon
[03:51] <wallyworld> anastasiamac: worries about the yaml change since we try not to do that. remind me, was that something we said was ok this time?
[04:03] <anastasiamac> wallyworld: so yaml has to change coz we previously did not have controller side info
[04:03] <anastasiamac> wallyworld: the most yaml changes that r concerning r the ones that feed back into a correpsonding command
[04:03] <anastasiamac> for example if we had to update regions using this output
[04:03] <wallyworld> true, although pople to script stuff also
[04:03] <anastasiamac> however... this is more of a show than a list
[04:03] <wallyworld> but yeah, not much choice here
[04:04] <anastasiamac> wallyworld: i srsly doubt many ppl scripted that but we are adding more info that did not exist so yes, have to change yaml...
[04:07] <wallyworld> anastasiamac: lgtm, ty
[04:08] <anastasiamac> wallyworld: \o/
[04:10] <wallyworld> babbageclunk: what's status on vsphere role checK? still having "fun with groups"? i prefer "fun with flags"
[04:16] <babbageclunk> wallyworld: still fun with groups - I think I've nearly cracked it
[04:20] <wallyworld> \o/
[05:48] <babbageclunk> wallyworld: ok, I think I've got it - went down a few wrong alleys first. Also there's the weird thing where if you don't have the read permission you also don't have permission to check to see if you have the permission, so you have to use the nopermission fault as the answer.
[05:48] <babbageclunk> I'll finish coding it up tomorrow - have to go to choir.
[05:48] <wallyworld> ok, ty
[06:04] <anastasiamac> wallyworld: m inclined to lmit lists and show to just list and show rather than also do a diff... i feel like it's a different concern
[06:05] <wallyworld> porbs, just on a call atm
[06:05] <anastasiamac> wallyworld: besides we r only doing it in one, human readable format as it makes no sense in other formats...
[06:05] <anastasiamac> wallyworld: ack
[09:41] <stickupkid> is there away to make `--debug` flag be true all the time via an env var? I want it for some CLI integration testing, and it's very verbose to do that in every place
[09:41] <stickupkid> jam, thoughts?
[09:42] <achilleasa> stickupkid: how about 'alias juju=juju --debug' ?
[09:42] <stickupkid> sick
[09:42] <stickupkid> that might work
[09:50] <stickupkid> achilleasa, nice, that worked
[09:52] <stickupkid> anyone want to review the left overs from CI day, this ensures that we handle logging and bootstrap reuse correctly https://github.com/juju/juju/pull/10729
[09:53] <stickupkid> it actually fixes an issue in one of the test suites, where underscores in model names failed to bootstrap
[10:23] <nammn_de> manadart: controller do count as agents? If I want to run updatesteps on the controller and machines, in generall all agents I add those to targets?  []Target{AllMachines, DatabaseMaster} Or would be "allMachines" correct? I know we talked aobut this briefly yesterday..
[10:37] <manadart> nammn_de: AllMachines should do it.
[10:45] <nammn_de> got it thanks
[11:00] <nammn_de> did any of you ever came across this err message? 'juju.worker.dependency "uniter" manifold worker returned unexpected error: subnet'
[11:03] <achilleasa> manadart: can you take a look at https://github.com/juju/juju/pull/10734? I don't think it causes any conflict with hml's changes but I will wait till her PR lands to merge this in.
[11:05] <manadart> achilleasa: Yep. Just grabbing a bite.
[12:10] <manadart> achilleasa: Approved. One comment.
[12:18] <hml> manadart:  can you take a look at a test for me pls?  https://jenkins.juju.canonical.com/job/github-make-check-juju/1563/consoleText  TestReplaceSpaceNameWithIDEndpointBindings - the data isn’t getting into the db for endpointbindings so fails.  I’m just not sure what’s wrong with the bson insert.
[12:18] <hml> manadart: https://github.com/juju/juju/pull/10718/files#diff-dd4ab00ea08f5a35293ab48af332ba38R3958
[12:19] <hml> manadart:  another set of eyes would be great
[12:25] <manadart> hml: Looking.
[12:26] <nammn_de> manadart do you know what "JUJU_K8S_MODEL" in the makefile refers to?
[12:31] <manadart> nammn_de: It looks like an env var that needs to be set as the model that "make local-operator-update" will run against.
[12:32] <rick_h> manadart:  heads up, in talking with thumper last night this topic came up and might be of great interest to the ATOS conversations https://discourse.jujucharms.com/t/little-known-feature-workload-juju-communication/2218
[12:32] <rick_h> heh looks like you've already seen/replied in it. cool
[12:32] <manadart> rick_h: I also posted it to the Atos Slack.
[12:32] <rick_h> manadart:  <3
[12:33]  * manadart got you yo.
[12:49] <manadart> hml: I think you have to add a model-uuid to the test docs that you create. None of them are found by the test.
[12:51] <hml> manadart:  okay, i’ll take a look,
[12:51] <hml> I thought _id was sufficient
[13:51] <nammn_de> manadart: just to make sure for bug report https://bugs.launchpad.net/juju/+bug/1848149 , does an error occur while deploying? Was the err msg.: "version string generation failed"?
[13:51] <mup> Bug #1848149: Charm Deployed or Upgrade from Dir Ignores "version" <juju:Triaged> <https://launchpad.net/bugs/1848149>
[13:52] <hml> stickupkid: reworded the CMR scenario, hopefully more clear
[13:52] <manadart> nammn_de: There is no error. One way gets a version and the other does not.
[13:52] <stickupkid> ta
[13:53] <nammn_de> manadart: ahh, okay interesting. Maybe both bug reports where different nature I will update that thanks
[14:10] <nammn_de> hml: do you have the PR at hand which I should run QA?
[14:11] <hml> nammn_de: they should be linked from the trello cards in general.   here’s the specific one in this case: https://github.com/juju/juju/pull/10718
[14:11] <nammn_de> hml: ah right, thanks!
[14:16] <nammn_de> @jam you were saying we should add an acceptance test because of pathing. Isn't there one used? https://github.com/nammn/juju/blob/088736ee1fea11a6d85eb4511e26239cc688dc43/tests/suites/cli/use_local_charm.sh#L43
[14:24] <rick_h> nammn_de:  the idea was to test deploying a charm now in the cwd, e.g. ./path/to/charm
[14:24] <rick_h> nammn_de:  along with the test for juju deploy .
[14:25] <rick_h> nammn_de:  so we'd have both scenarios vs just the one
[14:25] <nammn_de> rick_h: you mean adding a test with a relative path? Current test uses a absolute one
[14:26] <rick_h> nammn_de: yes
[14:26] <nammn_de> rick_h: ahhh I missunderstood initially. Got it
[16:22] <nammn_de> rick_h hml: i just configured guimaas and would love to help QA the PR but a lot of things are new to me (Space bindings, CMR, bindings) someone has time to give me an introduction/give me links to some things to read up on?
[16:24] <nammn_de> just ping me up if thats the correct documentation for the current system: https://jaas.ai/docs/deploying-advanced-applications#heading--deploying-to-network-spaces
[17:01] <killcity> Hi all. Does anyone know what else i need to do when trying to set config values to env vars on a centos box via an install hook? they dont seem to be populating. works fine on ubuntu.
[17:02] <killcity> ie: MYVALUE=$(config-get myvalue)
[17:02] <killcity> the rest of the hook that doesnt rely on config values/vars works fine. ie: yum installs, etc
[17:11] <rick_h> nammn_de:  will make time tomorrow we can run through stuff
[17:34] <pmatulis1> when i use option `--metadata-source` with the 'bootstrap' command i don't see where this value is exposed. should it not show up in the output to 'show-controller' command?
[17:35] <rick_h> pmatulis1:  I think it's controller-config?
[17:38] <killcity> is there a chat log anywhere we can reference?
[17:38] <killcity> anyone know if they are planning on moving to slack instead?
[17:39] <killcity> irc is cool and old school, but...
[17:39] <rick_h> killcity:  we're not looking to move to slack anytime.
[17:40] <rick_h> killcity:  let me see if we have logs. We used to but I can't recall the url.
[17:41] <rick_h> killcity:  https://irclogs.ubuntu.com/2019/
[17:42] <rick_h> hml:  looks like jenkins is back up and happy-ish
[17:42] <hml> rick_h: ty
[17:42]  * rick_h rekicks last build
[17:45] <killcity> any reason in particular you dont want to move to slack? not having to ask the same question over again because someone already asked it (because there is a convo history) is huge.
[17:47] <killcity> rick_h thanks
[17:52] <rick_h> killcity:  mainly not a fan of slack myself and I've avoided it so far personally. I understand not everyone agrees. I think that the main thing is it's standard for canonical projects to have a public IRC channel on freenode and it would be a large undertaking to migrate everyone/everything.
[17:54] <killcity> looks like #juju isnt being logged.
[17:54] <pmatulis1> rick_h, i forgot about controller-config. these two commands have always been confusing. anyway, metadata-source is in neither of them
[17:54] <rick_h> pmatulis1:  :( ok
=== pmatulis1 is now known as pmatulis
[17:54] <rick_h> killcity:  oh, I saw it one one of the days.
[17:54] <rick_h> killcity:  https://irclogs.ubuntu.com/2019/10/15/%23juju.txt (today)
[17:54] <killcity> i just dont see the benefit to irc over slack, but fair enough. this is coming from a guy that used to work at concentric.net
[17:55] <rick_h> killcity:  understand. It's just not something I've pushed on because of my own slack reluctance I guess. I'm sure there are others that would <3 it
[17:55] <rick_h> killcity:  but hey, what can I help you with?
[17:56] <rick_h> oic, you've got a charm hook question above. Hmmm, there's nothing specific on that I can think of. Just bash at that point.
[17:57] <hml> pmatulis: doesn’t metadata-source get turned into agent-metadata-url and image-metadata-url in model-config?
[17:57] <killcity> Thanks Rick, I appreciate the response and thoughts. Im excited to move all of our provisioning over to maas and juju from stacki. The one thing Im trying to figure out is how to set get-config values to an env when deployed onto a centos box. seems to work fine with ubuntu (tested on bionic). not so much on centos7. im sure im doing something
[17:57] <killcity> wrong.
[17:58] <rick_h> killcity: gotcha, welcome to the party
[17:58] <killcity> hmmm. ill have to test a little more then. just wanted to make sure there wasnt anything special i needed to do for centos :)
[17:58] <killcity> thanks
[17:59] <pmatulis> hml, no. i get null values for each of those
[17:59] <rick_h> killcity:  hmm yea, I can't think of anything. I guess can you log/dump debug traces in there to see if it's set, if the value is coming out correctly from the config-get call?
[17:59] <killcity> ah good idea. ill add some debugging in there. thanks :)
[18:00] <killcity> btw, this channel seems a lot more active than #maas.
[18:00] <killcity> which is great.
[18:00] <rick_h> killcity:  cool, glad we're alive and kicking here. MAAS folks are definitely a bit queiter as they're a smaller team in a tighter set of timezones (we go across almost all of them)
[18:01] <rick_h> killcity:  but I will say the MAAS stuff is awesomesauce and they've got a discourse going as well which is worth hitting up if you hit questions/etc.
[18:04] <killcity> saw that, so far its looking really nice and stable. the biggest hurdle is understanding the workflow, etc. which isnt a huge deal. most of the docs look very thorough.
[18:06] <nammn_de> rick_h: yeah thanks!
[18:09] <hml> pmatulis:  weird…. you checked all models?
[18:13] <rick_h> nammn_de:  k, have a good night and feel free to ask around of EU folks in the morning and when I come online we can sync up and catch up on any gaps/knowledge share that's helpful
[18:14] <nammn_de> rick_h: you as well, will do!
[18:17] <pmatulis> hml, i check both the 'default' and 'controller' models
[18:25] <pmatulis> https://bugs.launchpad.net/juju/+bug/1848241 <--- hml
[18:25] <mup> Bug #1848241: [bootstrap] metadata-source option is not exposed <juju:New> <https://launchpad.net/bugs/1848241>
[18:32] <hml> pmatulis:  can you please add the version of juju to the bug
[18:33] <pmatulis> hml, done
[18:45] <killcity> does anyone know how to set the vlan and create bond via juju commands + maas?
[18:45] <killcity> so when i deploy a specific charm, any unit under that application gets the same network configuration?
[18:46] <rick_h> killcity:  so the idea is that you create the network setup in MAAS. There's docs around creating bonds/etc
[18:47] <rick_h> killcity:  as the underlying cloud it knows the network topology/etc
[18:47] <rick_h> killcity:  then in Juju, it'll read that data from MAAS and you'll end up doing things like using spaces, and endpoint bindings onto spaces, to manage which networks applications are talking through/over
[18:47] <rick_h> killcity:  welcome to the "deep end"
[18:48] <rick_h> killcity:  some reading material from the Juju perspective - https://discourse.jujucharms.com/t/network-spaces/1157 and https://discourse.jujucharms.com/t/deploying-applications-advanced/1061
[18:49] <killcity> Excellent, thanks Rick :)
[18:49] <killcity> The last hurdle we have is understanding how to set specific software raid configurations on certain models of hw. some of our nodes dont have raid controllers
[18:51] <rick_h> killcity:  yea, there's some disk management config you can do on machines in MAAS (though I've not tweaked that myself)
[18:52] <killcity> I saw some custom stuff done in a single posting somewhere, but theres not any reference material ive found concerning software raid in particular.
[18:52] <killcity> Btw, I ran my test deploy again and vars were working fine :)  It was an issue with the script itself
[18:53] <rick_h> killcity:  woot, glad to hear
[18:53] <killcity> *facepalm...
[18:53]  * killcity facepalms
[18:53] <rick_h> killcity:  interesting google search https://docs.mirantis.com/mcp/q4-18/mcp-deployment-guide/deployment-customizations-guidelines/maas/custom-disk-layout.html
[18:53] <rick_h> has a section "To define software raid"
[18:54] <rick_h> might be worth a bug to the maas docs if that's what you're looking for and couldn't find it in the maas docs
[18:54]  * rick_h has to run and get his son from school, back in a bit
[19:05] <killcity> rick_h thanks! i will definitely look at those docs.
[20:10] <roadmr> this is a software raid! put all your floppies and CDs in the bag and don't get any funny ideas about downloading any apps... we'll know.
[20:23] <pmatulis> gulp
[20:31] <killcity> does anyone know if maas/juju require machines to be set on a specific space before they can be used or can you have the space set at the time of deployment?
[20:31] <killcity> i would prefer to have a bunch of hw sitting there unallocated and not explicitly added to a specific space so they can land on whatever subnet they need to be on.
[20:32] <thumper> no, I don't think that is a prerequisite
[20:33] <killcity> im trying to better understand how to automatically enable bonding and a vlan subinterface on deployment. all our nodes receive trunked/tagged interfaces, so we can put them on whatever vlan we choose when they are built.
[20:33] <killcity> i can configure nodes via MAAS ui for this, but not sure how to make it happen automatically during deployment...cant seem to find any docs on it.
[20:34] <killcity> (also maas cli)
[20:39] <thumper> my understanding is that you configure how you want the network devices set up in maas, and then when you deploy with juju they get set up that way
[20:40] <thumper> effectively it is the maas instantiation of the machine that sets up the networking
[20:40] <thumper> there isn't another step
[20:40] <thumper> as far as I understand it
[21:36] <babbageclunk> wallyworld: tested out the precheck, all working - just writing a unit test now.
[21:46] <thedac> thumper: rick_h: Nevermind on the juju run problem. Test on latest 2.7 edge looks good. I'll let you know if I ever see it again.
[22:27] <wallyworld> babbageclunk: just got out of morning meetings. i'll review once done, ty
[22:56] <anastasiamac_> wallyworld: PTAL https://github.com/juju/juju/pull/10736 - list clouds changes
[23:24] <anastasiamac_> wallyworld: yes all is the breakage and so is non display of clouds that do not have creds registered. both were discsussed and insitented on in paris by both jam and rick_h
[23:25] <anastasiamac_> wallyworld: the removl of color was discussed and agreed onin paris too coz it was obscure for users and has no valud now
[23:25] <anastasiamac_> value*
[23:29] <killcity> thumper thanks. ill see if i can figure out how to create the different profiles for interface configs in maas.
[23:33] <rick_h> thedac:  ok cool ty
[23:52] <anastasiamac> wallyworld: rick_h : udated PR to only filter public clouds based on whether creds are present... PTAL?
[23:53] <anastasiamac> really want to land this asap as there is more in pipeline and no time left