[09:12] <externalreality> test
[12:32] <jam> tick
[12:34] <rick_h> Jam tock
[12:34] <jam> rick_h: sorry I'm late, just finishing up the last meeting, brt
[14:23] <jac_cplane> We have a charm for xenial that relys on /etc/network/interfaces, there was a recent update to curtin that moves /etc/network/interfaces to /etc/network/interfaces.d.   I dont think this is correct, but I' not sure why this change was made.  Can someone help?
[14:54] <jac_cplane> bug openend https://bugs.launchpad.net/maas/+bug/1732202 on curtin 532
[14:54] <mup> Bug #1732202: Xenial Deploy fails when using /etc/network/interface <MAAS:New> <https://launchpad.net/bugs/1732202>
[19:13] <[Kid]> can you not create models from logging into a controller?
[19:13] <[Kid]> also, is it possible to login to a controller as admin on any other server than the one that juju was bootstrapped from?
[19:15] <[Kid]> ahh i see what the problem is. the cloud providers are only stored on the juju server that the controllers were bootstrapped from
[19:15] <[Kid]> i.e., you can't login to a controller from a random juju install and see the cloud providers for that controller
[19:29] <[Kid]> so far, it seems like if i need to make most changes outside of removing or adding a worker node to a kubernetes cluster i have to remove the model and re-add it
[19:29] <[Kid]> so basically a full re-deploy
[19:29] <[Kid]> does that sound right?
[19:38] <rick_h> [Kid]: so you can add new users with admin and superuser permissions to access from other locations
[19:39] <rick_h> [Kid]: check out https://jujucharms.com/docs/stable/tut-users
[19:39] <rick_h> [Kid]: as far as changes to the cluster needing a redeploy, I'd hope not. I think the team would be curious what changes and see what's not supported in the charms and such that wrap the operations
[19:42] <ryebot> [Kid]: gimme a second to catch up
[19:42] <ryebot> [Kid]: What changes do you need to make?
[20:11] <[Kid]> sorry, i am here
[20:12] <[Kid]> i currently tried a deploy and MAAS didn't finish deploying 2 of the nodes and i have machines in a down state
[20:12] <[Kid]> i released the machines in MAAS, but how to i get juju to try and redeploy to those machines?
[20:12] <[Kid]> it already thinks it allocated them
[20:14] <[Kid]> the changes that i was trying to make were like removing flannel and adding calico. it worked but then it rebuilt the master nodes and my  ssh keys changed and i couldn't get juju scp to work.
[20:38] <kwmonroe> [Kid]: watcha mean by 'rebuilt the master nodes'?  you mean like the flannel cni relation was removed and calico joined?
[20:41] <kwmonroe> also [Kid], i'm at a loss when you say you lost 'juju scp' capabilities.  i can't think of a reason why the juju keys used to ssh to a unit would change, regardless of how that unit was changed post deployment (unless, of course, you changed ~/.ssh/authorized_keys on the juju unit out-of-band)
[20:43] <kwmonroe> rick_h: are there circumstances that cause ~/.local/share/juju/ssh/juju_id_rsa* to change?
[20:44] <rick_h> kwmonroe: ...not that I can think of
[20:44] <kwmonroe> [Kid]: the ssh key that juju uses for things like juju scp are stored in ~/.local/share/juju/ssh/juju_id_rsa, and the .pub key in there is what is normally on all deployed units.  rick_h assures me this is bulletproof. ;)
[21:00] <cory_fu> What does this error mean when trying to bootstrap lxd / localhost?  ERROR Get https://10.130.48.1:8443/1.0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "root@murdoch")
[21:05] <cory_fu> stokachu: Do you recognize that, by chance?  ^
[21:05] <stokachu> cory_fu: yea i think it's the certificate in .local/share/juju/bootstrap-config
[21:05] <stokachu> or one of those files
[21:05] <stokachu> maybe credentials.yaml
[21:06] <cory_fu> stokachu: Ah.  Just torch it?
[21:06] <stokachu> yea
[21:08] <cory_fu> stokachu: It was credentials.yaml.  Thanks!
[21:08] <stokachu> cool, np
[21:11] <[Kid]> kw and rick, thanks. i will continue to look at it
[21:12] <[Kid]> kw and rick, is there a way to have juju retry the deployment of a machine?
[21:12] <[Kid]> i have two machines in a down state and message is failed deployment.
[21:13] <[Kid]> i manually fixed MAAS, so i wanted it to try on those same machines agin
[21:13] <[Kid]> again
[21:14] <rick_h> [Kid]: so there's juju retry-provisioning, if the machine didn't come up
[21:15] <rick_h> [Kid]: or if you want to just retry as something failed and you cleaned it up just juju add-unit xxx
[21:15] <rick_h> and have juju pull another up for use
[21:19] <[Kid]> ahh yes, i think juju retry-provisioning is what i need
[21:19] <rick_h> cool, hopefully that helps some
[21:26] <[Kid]> rick
[21:26]  * rick_h ducks
[21:27] <[Kid]> it accepts that command, but doesn't do anything
[21:27] <[Kid]> haha
[21:27] <[Kid]> just stuck in a down status
[21:27] <[Kid]> guess i might have to remove and re-deploy
[21:27] <rick_h> [Kid]: try with --debug and see if anything is fishy? Maybe trace debug-log and see if anything comes up.
[21:27] <[Kid]> i did
[21:27] <rick_h> [Kid]: just remove and add-unit ?
[21:27] <[Kid]> juju debug-log didn't have anything
[21:27] <[Kid]> i will try the --debug on the command
[21:32] <[Kid]> well, destroying the model again
[21:32] <[Kid]> .....
[21:32] <[Kid]> redeployings
[21:33] <[Kid]> i have to wonder if i am just a special case.....
[21:34] <rick_h> [Kid]: no I mean something's up. Do you know it failed to come up?
[21:46] <zeestrat> Hey [Kid], if you fixed the maas nodes so that's not the issue anymore and the `retry-provisioning` didn't work then you should be able to do `juju add-unit <name-of-service-that-failed-to-deploy>` so you don't have to destroy the whole model as rick_h mentioned above.
[21:51] <[Kid]> rick, yes, it didn't come up
[21:51] <[Kid]> i waited like 30 minutes
[21:51] <[Kid]> just in a down state and had "failed deployment" in the message field
[21:51] <[Kid]> looks like the re-deploy worked
[21:52] <[Kid]> i just hate that i have to keep re-deploying for simple changes
[21:53] <rick_h> [Kid]: well this isn't a redeploy as the first one didn't succeed right?
[21:53] <rick_h> I mean it's not in a change, but that maas didn't get a machine to juju?
[21:53] <rick_h> I guess that's what I'm wondering is what went wrong between maas/juju, did curtain get things started, cloud-init go ok, juju agents get installed and setup?
[22:01] <zeestrat> Maas has logs for it's deployments on the node page and should say why it ended up as a failed deployment.