[15:58] heyyyya [15:59] how can my users login to a controller from another host? [16:00] I thought it may be as simple as running `juju register [16:00] I can't find any docs on this [16:06] ahh got it [16:07] they just run the register command, but with the ip of the controller, instead of the register hash [16:08] hmmmm ... well thatt doesn't work [16:14] https://bugs.launchpad.net/juju/+bug/1754701 [16:14] Bug #1754701: `juju register` workflow ? [16:21] followed it up with a docs bug too https://github.com/juju/docs/issues/2513 [16:51] rahwork, rick_h: rahworkx@external/devops-sandbox [16:52] ^ model stuck in destroying in jaas [16:52] the machine in that model was a manually added machine that was physically removed, but then never removed in the context of juju [16:53] now trying to remove the model it hangs [16:53] never destroys [16:55] bdx check .local/share/juju/models.yaml, there may be a stale entry that you can remove if you're sure the machines are gone. [16:55] ryebot: cool ... I mean I can still get `juju status` on the model .... [16:56] ryebot: I would think that would indicate that the model still actually exists ? [16:58] ryebot: https://pastebin.com/qisLu5dm [16:58] bdx looking [16:58] What happens if you force remove that machine? [16:59] bdx^ [16:59] it never leaves [17:00] bdx can you confirm it's actually gone via aws console or cli? [17:01] ryebot: one interesting observation https://pastebin.com/uURCXgUL [17:02] after trying to --force remove the machine, it seems the juju agent has come back to life lol [17:02] Oh, weird. [17:03] I'd probably try another force removal [17:03] yeah, I just hammered it with ~20ish [17:03] Ah, well then. [17:04] I'm cracking open another bug for this [17:04] ryebot: thanks for your insight [17:04] I think at this point I'd destroy the machine via aws cli/console and then wipe the model [17:04] its a manually added machine [17:04] bdx np good luck [17:05] no one who has access to the model has access to the physical machine anymore lol [17:15] bdx: can you destroy-machine --force? [17:16] rick_h: I can run the command, but it has no affect [17:16] oh [17:16] destroy-machine? [17:16] bdx: right, go to the model, destroy-machine --force all the machines [17:16] oh lol ... nope cant run that one [17:16] then destroy-model (now empty) [17:17] :( [17:17] have to go the bug route and see what we can figure out sorry. That's the best get out of jail card I know for that [17:17] destroy-model [17:17] is a thing [17:17] destroy-machine isnt [17:18] remove-machine? [17:18] I thought it was destroy [17:18] but yeah ... got the friday bug attack all lit up [17:18] https://bugs.launchpad.net/juju/+bug/1754711 [17:18] Bug #1754711: `juju destroy-model ` - model never destroys [17:18] bdx: sorry, remove-machine --force [17:18] yeah, rick_h .... ya know what that did? [17:18] heh..no [17:19] interesting behavior https://paste.ubuntu.com/p/ywJ7Cns8HS/ [17:19] lol [19:02] Hello all, does anyone know a way to provision multiple kube-api-loadbalancer aws instances in the cdk bundle.yml ? [19:28] Hello all was also wondering when bootstrapping a aws controller is there a way to config open port source ip's? [20:51] rahworkx: this will open ports on any unit: juju run --unit / open-port XXXX' [20:51] or if you wanted ports for multiple units, you could do it at the application level with: juju run --application 'open-port XXXX' [20:51] or everthing with: juju run --all 'open-port XXXX' [20:52] but typically you'd rely on the charm author to open the right ports for their application. is there a reason you want additional ports opened outside of the charm's defaults? [20:53] oh wait, i may be misunderstanding your question -- you wanted ports opened at bootstrap time? for the controller or a specific app or what?