[02:20] kelvinliu: is your PR ready to review? I'll look after i finish harry's. plus I have 2 small ones up as well [02:21] wallyworld: not yet, will ping u when it's ready [02:21] ok [02:43] wallyworld: PRs look good, exit code one just needs to update Gopkg.lock [02:44] oh right yeah, for the k8s dep [02:44] got sucked back into this verizon thing, so still not done with yours sorry [02:45] np [04:40] hpidcock: i left a few more comments - wouldn't mind a chat perhaps once you read them [04:42] hpidcock: not needed, I think I understand them all [04:42] ok [04:44] hpidcock: i'll do another pass once changes pushed. operator flle needed for juju-run since that is invoked from the workload pod by a cron script or whatever and not via an exec call made by juju where the env vars can all be set in place to commuicate socket info etc [04:44] so where we do have env vars available, we should continue to use that pattern [04:45] wallyworld: seems pretty heavy to send the ca cert for every call [04:45] yeah, true that [04:45] we could write that to the /var/lib/juju directory [04:46] wallyworld: wanna have a discuss testing podspecv2, ru free now? [04:46] hpidcock: so i guess the operator file in some form might be reasonable after all [04:48] wallyworld: I agree that we should probably keep the env vars consistent for hooks, but I think the compromise is a ca.crt file, and a JUJU_CA_CERT= [04:48] hpidcock: or maybe just the cert and private key a seperatae files on disk under /var/lib/juju like we do for other things [04:48] yup, works for me [04:48] ^ [04:48] ok [04:48] kelvinliu: sure, free now [05:25] kelvinliu: for later when you are free, this brings the pod spec parsing from from yesterday in 2.6 to the develop branch https://github.com/juju/juju/pull/10611 [05:26] wallyworld: lgtm thx [05:26] ty [14:03] I'm trying to use the feature described in https://jaas.ai/docs/lxd-cloud-advanced#heading--charms-and-lxd-profiles as having been added in Juju 2.5.0. I have https://paste.ubuntu.com/p/jBydGSKdHS/ as lxd-profile.yaml at the top level of my charm. Client version 2.6.8, controller version 2.5.8. It seems to have exactly no effect: "lxc config show --expanded" on the relevant container ... [14:03] ... doesn't show the configuration I've tried to set, and I can't find any log entries related to it. What am I missing? [14:09] Oh, never mind. I think my controller upgrade hadn't quite finished at the point when I did the deployment [14:10] Nice nice, this is there now [14:51] cjwatson: glad that was resolved. definately recomment juju 2.6.8 for using lxdprofiles over 2.5.x [18:08] o/ [18:09] Is it normal for, when adding credentials, the pasted API key doesnt print to screen? My juju is all messed up. [18:10] pepperhead, yes, that sounds right [18:10] pepperhead, messed up how? [18:10] I enter "juju status" and get "ERROR no API addresses" [18:11] it sounds like you cannot contact the controller [18:12] Is there any way to uninstall juju and start fresh? [18:12] do you have anything deployed? [18:13] I tried "sudo apt-get remove juju", then "sudo apt-get purge juju". then reinstalled with "sudo apt install juju". I get the same [18:14] what i meant was, did you deploy anything with juju (ex: juju deploy ) [18:14] Well I think that may be the problem: I had maas running, and moved it into a lab, and it got borked. I uninstalled maas and reinstalled maas. It HAD the controller deployed previously. Could it be still thinking it is alive? [18:15] The only thing successfully deployed previously was the controller [18:16] yes, juju cannot see the new maas [18:16] So do I have to wipe the system and start from scratch? [18:16] you can do a few things. uninstall completely or just tell juju to forget about the controller [18:17] Whats weird is I tried to deploy the controller, and it deployed Ubuntu to the node and hiot a wall. [18:18] does 'juju clouds --local' show your maas cloud? [18:18] Can I do both? How can I tell juju to forget the controller, AND uninstall to ensure I am clean? [18:18] uninstalling will include forgetting the controller [18:19] did you install juju by deb package or by snap? [18:19] I get "mymaas 0 maas Metal As A Service" [18:19] deb [18:19] we usually encourage snaps these days [18:19] I am cool with switching, if that is possible [18:19] ok [18:20] New to Snaps, and juju, and maas :( [18:20] 'sudo apt purge juju' [18:20] done [18:21] and remove ~/.local/share/juju if it's still there [18:22] it was there, removed [18:22] now 'sudo snap install juju --classic' [18:22] "juju 2.6.8 from Canonical✓ installed" [18:23] I need to research Snap [18:23] perfect. now add your MAAS. you've done that before right? [18:24] (add-cloud command) [18:24] Unsure what that means, maas is running already [18:24] yes, but you need to tell juju about it [18:24] (how did you get a maas before? you said it showed up with 'juju clouds --local') [18:25] "juju add-cloud mymaas"? [18:25] https://jaas.ai/docs/maas-cloud [18:25] I was following "https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/rocky/install-juju.html" [18:26] oh, interesting [18:26] well, that should be equivalent [18:27] but you're prolly using a more updated juju version. there may be differences [18:27] but i think you're well on your way. good luck [18:28] So start the interactive with "juju add-cloud --local" [18:28] that will work, yes [18:29] Thanx! Was just confused by "add maas", thought it might mean removing and readding maas itself :) [18:29] ohh :) [18:30] So should I run that with sudo? [18:30] no [19:01] So you are probably well versed in maas, so let me ask a stupid question: Should the node machines be set to boot first from drive, or PXE after commissioning? [19:03] *always* PXE [19:06] You rock! [19:06] So Ubuntu is deploying to the juju node now [19:06] pmatulis does rock :) [19:06] and you solved the chicke or the egg question I have been mulling over since this started [19:07] 🥚 🐔 [19:08] Trying to get OpenStack deployed as a POC, taking me down a lot of new roads [19:08] to make matters worse, I am given a stack of Intel NUC's to do the project. [19:10] Does juju have a web interface, as does maas, to see whats going on, or is it all cli? [19:10] it does [19:11] it gets installed with the juju controller [19:12] is that the "juju gui"? [19:12] https://jaas.ai/docs/gui [19:12] I need to read the docs this weekend, as well as maas docs [19:13] yep [19:13] you can discuss stuff in the docs via a forum. there is a link at the bottom of each page that will bring you there [19:13] Maybe this node is bad, I got booted from tyhe maas box (ssh'd in). maas is still saying "Deploying Ubuntu 18...) [19:14] you will need to wait [19:14] until the node is deployed [19:14] I ssh'd back in [19:14] you mean you tried to ssh into the node? [19:15] no, back into the maas box [19:15] unsure how to see where juju is in the process now [19:16] what did you actually tell juju to do? 'juju bootstrap'? [19:16] patience padawan [19:16] yes [19:16] with constraint to "juju" tag [19:17] It picked up the correct node and started deploying the OS [19:17] ok, so juju told maas to deploy ubuntu onto a node and then juju will install controller stuff onto it [19:17] the maas gui shows it still deploying [19:18] this juju is very cool. [19:18] I think the issue is the NUC's. [19:19] Or this one in particular. If it doesnt complete I will try one of the larger NUC's, this is the smallest of the stack [19:19] Until juju gets the controller installed, no way to get a status I would think [19:20] 2 core/ 4g RAM [19:21] I assume that since it issued the command to maas, and maas began the process, the API creds are correct. [19:22] I wonder if the node will have to reboot after the OS is deployed? [19:24] if you fear things have gone pear-shaped you may need to go purely maas and test powering on/off and deploying. so no juju. just work within the maas gui [19:29] If I want to cancel the bootstrap, and try another node that is bigger, is there a way to do that? [19:30] maas has logs that are viewable via the gui. you can also view logs on the maas server. i would look at the logs before ctrl-c on juju [19:31] maas gui event logs are per the node being deployed [19:32] I took a look at the node, it is stuck at a reboot with a "boot:" prompt [19:33] Event "Installation complete - Node disabled netboot" [19:35] yeah, i sounds like your MAAS:NUC combo may need some study. i suggest asking in the maas forum: https://discourse.maas.io/ [19:37] If a tag another node as "juju" will it grab it, or do I need to remove this job first? [19:38] i would try a ctrl-c on the bootstrap command [19:39] I got thrown out of my ssh session, so I assume the bootstrap command died at that time? [20:12] update: confirmed on a second node. maas lays the OS down, performs a reboot, pxe grabs it and trys to hand off for a local boot and dies with a "boot:" prompt. [20:14] Thanks for the helpand time, looks like a dead project. [20:16] oddly if I ctrrl-alt-del reboot and catch it and select to start from the drive, the system comes up. juju controller never gets installed.