[02:20] <wallyworld> 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] <kelvinliu> wallyworld: not yet, will ping u when it's ready
[02:21] <wallyworld> ok
[02:43] <hpidcock> wallyworld: PRs look good, exit code one just needs to update Gopkg.lock
[02:44] <wallyworld> oh right yeah, for the k8s dep
[02:44] <wallyworld> got sucked back into this verizon thing, so still not done with yours sorry
[02:45] <hpidcock> np
[04:40] <wallyworld> hpidcock: i left a few more comments - wouldn't mind a chat perhaps once you read them
[04:42] <hpidcock> hpidcock: not needed, I think I understand them all
[04:42] <wallyworld> ok
[04:44] <wallyworld> 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] <wallyworld> so where we do have env vars available, we should continue to use that pattern
[04:45] <hpidcock> wallyworld: seems pretty heavy to send the ca cert for every call
[04:45] <wallyworld> yeah, true that
[04:45] <wallyworld> we could write that to the /var/lib/juju directory
[04:46] <kelvinliu> wallyworld: wanna have a discuss testing podspecv2, ru free now?
[04:46] <wallyworld> hpidcock:  so i guess the operator file in some form might be reasonable after all
[04:48] <hpidcock> 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=<path-to-ca.crt>
[04:48] <wallyworld> 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] <wallyworld> yup, works for me
[04:48] <hpidcock> ^
[04:48] <hpidcock> ok
[04:48] <wallyworld> kelvinliu: sure, free now
[05:25] <wallyworld> 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] <kelvinliu> wallyworld: lgtm thx
[05:26] <wallyworld> ty
[14:03] <cjwatson> 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] <cjwatson> ... 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] <cjwatson> Oh, never mind.  I think my controller upgrade hadn't quite finished at the point when I did the deployment
[14:10] <cjwatson> Nice nice, this is there now
[14:51] <hml> cjwatson: glad that was resolved.  definately recomment juju 2.6.8 for using lxdprofiles over 2.5.x
[18:08] <pepperhead> o/
[18:09] <pepperhead> Is it normal for, when adding credentials, the pasted API key doesnt print to screen? My juju is all messed up.
[18:10] <pmatulis> pepperhead, yes, that sounds right
[18:10] <pmatulis> pepperhead, messed up how?
[18:10] <pepperhead> I enter "juju status" and get "ERROR no API addresses"
[18:11] <pmatulis> it sounds like you cannot contact the controller
[18:12] <pepperhead> Is there any way to uninstall juju and start fresh?
[18:12] <pmatulis> do you have anything deployed?
[18:13] <pepperhead> 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] <pmatulis> what i meant was, did you deploy anything with juju (ex: juju deploy <something>)
[18:14] <pepperhead> 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] <pepperhead> The only thing successfully deployed previously was the controller
[18:16] <pmatulis> yes, juju cannot see the new maas
[18:16] <pepperhead> So do I have to wipe the system and start from scratch?
[18:16] <pmatulis> you can do a few things. uninstall completely or just tell juju to forget about the controller
[18:17] <pepperhead> Whats weird is I tried to deploy the controller, and it deployed Ubuntu to the node and hiot a wall.
[18:18] <pmatulis> does 'juju clouds --local' show your maas cloud?
[18:18] <pepperhead> Can I do both? How can I tell juju to forget the controller, AND uninstall to ensure I am clean?
[18:18] <pmatulis> uninstalling will include forgetting the controller
[18:19] <pmatulis> did you install juju by deb package or by snap?
[18:19] <pepperhead> I get "mymaas                0                   maas        Metal As A Service"
[18:19] <pepperhead> deb
[18:19] <pmatulis> we usually encourage snaps these days
[18:19] <pepperhead> I am cool with switching, if that is possible
[18:19] <pmatulis> ok
[18:20] <pepperhead> New to Snaps, and juju, and maas :(
[18:20] <pmatulis> 'sudo apt purge juju'
[18:20] <pepperhead> done
[18:21] <pmatulis> and remove ~/.local/share/juju if it's still there
[18:22] <pepperhead> it was there, removed
[18:22] <pmatulis> now 'sudo snap install juju --classic'
[18:22] <pepperhead> "juju 2.6.8 from Canonical✓ installed"
[18:23] <pepperhead> I need to research Snap
[18:23] <pmatulis> perfect. now add your MAAS. you've done that before right?
[18:24] <pmatulis> (add-cloud command)
[18:24] <pepperhead> Unsure what that means, maas is running already
[18:24] <pmatulis> yes, but you need to tell juju about it
[18:24] <pmatulis> (how did you get a maas before? you said it showed up with 'juju clouds --local')
[18:25] <pepperhead> "juju add-cloud mymaas"?
[18:25] <pmatulis> https://jaas.ai/docs/maas-cloud
[18:25] <pepperhead> I was following "https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/rocky/install-juju.html"
[18:26] <pmatulis> oh, interesting
[18:26] <pmatulis> well, that should be equivalent
[18:27] <pmatulis> but you're prolly using a more updated juju version. there may be differences
[18:27] <pmatulis> but i think you're well on your way. good luck
[18:28] <pepperhead> So start the interactive with "juju add-cloud --local"
[18:28] <pmatulis> that will work, yes
[18:29] <pepperhead> Thanx! Was just confused by "add maas", thought it might mean removing and readding maas itself :)
[18:29] <pmatulis> ohh :)
[18:30] <pepperhead> So should I run that with sudo?
[18:30] <pmatulis> no
[19:01] <pepperhead> 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] <pmatulis> *always* PXE
[19:06] <pepperhead> You rock!
[19:06] <pepperhead> So Ubuntu is deploying to the juju node now
[19:06] <roadmr> pmatulis does rock :)
[19:06] <pepperhead> and you solved the chicke or the egg question I have been mulling over since this started
[19:07] <roadmr> 🥚  🐔
[19:08] <pepperhead> Trying to get OpenStack deployed as a POC, taking me down a lot of new roads
[19:08] <pepperhead> to make matters worse, I am given a stack of Intel NUC's to do the project.
[19:10] <pepperhead> Does juju have a web interface, as does maas, to see whats going on, or is it all cli?
[19:10] <pmatulis> it does
[19:11] <pmatulis> it gets installed with the juju controller
[19:12] <pepperhead> is that the "juju gui"?
[19:12] <pmatulis> https://jaas.ai/docs/gui
[19:12] <pepperhead> I need to read the docs this weekend, as well as maas docs
[19:13] <pmatulis> yep
[19:13] <pmatulis> 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] <pepperhead> Maybe this node is bad, I got booted from tyhe maas box (ssh'd in). maas is still saying "Deploying Ubuntu 18...)
[19:14] <pmatulis> you will need to wait
[19:14] <pmatulis> until the node is deployed
[19:14] <pepperhead> I ssh'd back in
[19:14] <pmatulis> you mean you tried to ssh into the node?
[19:15] <pepperhead> no, back into the maas box
[19:15] <pepperhead> unsure how to see where juju is in the process now
[19:16] <pmatulis> what did you actually tell juju to do? 'juju bootstrap'?
[19:16] <pepperhead> patience padawan
[19:16] <pepperhead> yes
[19:16] <pepperhead> with constraint to "juju" tag
[19:17] <pepperhead> It    picked up the correct node and started deploying the OS
[19:17] <pmatulis> ok, so juju told maas to deploy ubuntu onto a node and then juju will install controller stuff onto it
[19:17] <pepperhead> the maas gui shows it still deploying
[19:18] <pepperhead> this juju is very cool.
[19:18] <pepperhead> I think the issue is the NUC's.
[19:19] <pepperhead> 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] <pepperhead> Until juju gets the controller installed, no way to get a status I would think
[19:20] <pepperhead> 2 core/ 4g RAM
[19:21] <pepperhead> I assume that since it issued the command to maas, and maas began the process, the API creds are correct.
[19:22] <pepperhead> I wonder if the node will have to reboot after the OS is deployed?
[19:24] <pmatulis> 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] <pepperhead> If I want to cancel the bootstrap, and try another node that is bigger, is there a way to do that?
[19:30] <pmatulis> 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] <pmatulis> maas gui event logs are per the node being deployed
[19:32] <pepperhead> I took a look at the node, it is stuck at a reboot with a "boot:" prompt
[19:33] <pepperhead> Event "Installation complete - Node disabled netboot"
[19:35] <pmatulis> 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] <pepperhead> If a tag another node as "juju" will it grab it, or do I need to remove this job first?
[19:38] <pmatulis> i would try a ctrl-c on the bootstrap command
[19:39] <pepperhead> I got thrown out of my ssh session, so I assume the bootstrap command died at that time?
[20:12] <pepperhead> 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] <pepperhead> Thanks for the helpand time, looks like a dead project.
[20:16] <pepperhead> 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.