[00:34] <wallyworld> magicaltrout: are you trying to add your square brackets to an attribute in the "config:" section of the charm podspec yaml? can you post to the discourse topic the yaml or a suitable snippet so we can reproduce any issue? is this with juju 2.6?
[01:32] <thumper> anyone? https://github.com/juju/juju/pull/10594
[01:48] <babbageclunk> thumper: looking - trade you: https://github.com/juju/juju/pull/10588
[01:48] <thumper> ,e ;ppls
[01:48]  * thumper looks
[01:48] <babbageclunk> types without putting his fingers on home
[01:48] <thumper> :)
[01:51] <thumper> babbageclunk: why the two line test?
[01:52] <thumper> if you are outputting the same thing
[01:52] <thumper> aren't those to the same?
[01:52] <babbageclunk> You mean in the Makefile? No, they're subtly different - the old one includes the full list of packages which is super long
[01:53] <thumper> so what does it output now?
[01:53] <babbageclunk> The same command but with $PROJECT_PACKAGES instead of the actual packages
[01:54] <babbageclunk> thumper: It's the same thing we do in go-install
[01:55] <babbageclunk> It just means you don't get spammed with a huge list of packages when running `make test`
[01:56]  * babbageclunk finds an example...
[01:57]  * babbageclunk gets 2FA'd
[01:57] <thumper> I see it now
[01:57] <thumper> babbageclunk: I have a makefile change coming too
[01:57] <thumper> and it overlaps with yours
[01:58] <thumper> but let's get it reviewed, and I'll deal with the conflicts
[01:58] <babbageclunk> :)
[01:58] <babbageclunk> thanks
[01:59] <anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/10595
[02:00] <wallyworld> ok, give me 5
[02:01] <anastasiamac> nw \o/ thnx :)
[02:04] <thumper> babbageclunk: https://github.com/juju/juju/pull/10596
[02:08] <thumper> wallyworld: what is the best, most current, guide to follow to create k8s charms?
[02:09] <wallyworld> there's an (oldish) discourse post
[02:09] <wallyworld> i can find it
[02:13] <thumper> grr...
[02:13] <thumper> some of our tests don't honour tmpdir
[02:13]  * thumper digs
[02:17] <wallyworld> thumper: https://discourse.jujucharms.com/t/writing-a-kubernetes-charm
[02:18] <thumper> wallyworld: ta
[02:23]  * thumper wonders how to isolate which package is writing to /tmp...
[02:25] <babbageclunk> Put some logging into the stdlib
[02:25]  * babbageclunk half-winks
[02:26] <thumper> babbageclunk: with the simple TMPDIR change, we catch most of the /tmp files
[02:26] <thumper> definitely all the go-build and go-link ones
[02:26] <thumper> and the check- and the mgo ones
[02:26] <thumper> but there are a few store-lock ones left
[02:26] <thumper> based on timestamps, I think it is just two packages
[02:27] <wallyworld> anastasiamac: lgtm
[02:27] <anastasiamac> wallyworld: \i/
[02:27] <anastasiamac> \o/ even :)
[02:29]  * thumper decides to go one package at a time while doing emails
[02:35] <wallyworld> kelvinliu: here's that actions PR https://github.com/juju/juju/pull/10597
[02:37]  * thumper thinks there has to be a better way to do this
[02:37]  * thumper thinks of bashisms
[02:42] <wallyworld> thumper: when you are free, a huge PR https://github.com/juju/juju/pull/10598
[02:45] <anastasiamac> haha if thumper is going to run tests pkg by pkg, he is not likely to b free this century...
[02:45] <thumper> wallyworld: done
[02:45] <wallyworld> ta
[02:53] <thumper> anastasiamac: for i in $(ls -d */); do echo ${i%%/}; touch /tmp/latest; cd $i; TMPDIR=/tmp/fake go test ./...; cd ..; find /tmp -path /tmp/juju-store-lock-\* -newer /tmp/latest 2> /dev/null; done
[02:53] <thumper> that is what I came up with to keep my sanity
[02:53] <thumper> anastasiamac: and it tells me it is /api/backups
[02:53] <thumper> just like that
[02:54] <anastasiamac> thumper: m very impressed :) we do prefer it if u could do everything in ur power to keep ur sanity
[02:54] <anastasiamac> and backups need some attention (not just the tests of course)
[02:55]  * anastasiamac honestly does not know what's with this new trend of keeping leaders sane... 
[03:01] <thumper> yeah, I know
[03:05] <anastasiamac> but m kind of happy that it's backups and not something more recently developed :)
[03:28] <kelvinliu> wallyworld: just back home, looking soon
[03:28] <wallyworld> no worries
[05:19] <wallyworld> hpidcock: here's a PR which adds a new hook command that you may find interesting to look at. no rush. https://github.com/juju/juju/pull/10599
[05:20] <hpidcock> alright
[07:26] <parlos> Good Morning Juju!
[08:15] <yan0s> I'm trying to setup juju with an OpenStack provider and I get the following error
[08:16] <yan0s> caused by: failed executing the request https://ncc_url:8774/v2.1/servers
[08:16] <yan0s> caused by: Post https://ncc_url:8774/v2.1/servers: EOF
[08:17] <yan0s> I saw this related bug: https://bugs.launchpad.net/juju/+bug/1655716
[08:17] <mup> Bug #1655716: retry failed API calls <eda> <landscape> <Autopilot Log Analyser:Fix Committed by fginther> <juju:Triaged> <https://launchpad.net/bugs/1655716>
[09:28] <danboid> I want to set up a juju controller. Is it as simple as installing the juju snap?
[09:28] <danboid> Will that create the database for me too?
[09:29] <danboid> I'm looking at https://jaas.ai/docs/installing and it doesn't give any pointers as to what the next step is after having installed the snap
[09:30] <danboid> I had a look into setting this up a while back and I seem to remember the controller needs a DB
[09:31] <danboid> I ran out of time and didn't get it running but can't remember how far I got
[09:32] <stickupkid> danboid, to run it locally you should be able to do https://gist.github.com/SimonRichardson/1609d6f93dcfdfbd97771afa7c1b38f0
[09:33] <danboid> stickupkid, Thanks! `juju bootstrap lxd test` will do what exactly?
[09:34] <stickupkid> danboid, bootstrap to a local lxd provider.
[09:34] <stickupkid> danboid, so this will setup a juju controller for you on a lxd provider, is what I should of said
[09:36] <danboid> That will create a juju controller called test? I presume it will use lxd on localhost? If lxd isn't installed on the local machine, how does it know where to look for one?
[09:37] <stickupkid> danboid, you are correct, it will attempt to use the one on localhost. If lxd isn't installed, it will fail to bootstrap.
[09:37] <danboid> OK, sounds easy enough
[09:38] <stickupkid> danboid, let me know how your adventures go
[09:38] <danboid> stickupkid, I will. Thanks!
[09:40] <danboid> I presume it is advised to run the juju controller on a separate machine to your maas controller? It is possible for them to run on the same machine tho too right?
[09:41] <stickupkid> the latter is the way to go when first setting up, but yes you can run your controller somewhere else if you so desire
[09:43] <parlos> anybody got any idea how to handle "Unable to allocate static IP due to address exhaustion"...
[09:44] <stickupkid> parlos, you got any more info?
[09:45] <parlos> not really, my maas has lots of IP addresses available in all the networks juju may want to use...
[09:46] <parlos> stickupkid not really, my maas has lots of IP addresses available in all the networks juju may want to use...
[09:48] <stickupkid> parlos, i'm assuming you've filed a bug, so we can track it... that way i can point people in the right location
[09:49] <parlos> stickupkid nope, no bug filed.. Assumed that it was user error :( Not sure if its a juju or maas bug...
[09:49] <yan0s> Any thoughts on "juju bootstrap" resulting in:
[09:49] <stickupkid> parlos, one way to find out :D
[09:49] <yan0s> caused by: failed executing the request https://ncc_url:8774/v2.1/servers
[09:49] <stickupkid> parlos, https://bugs.launchpad.net/juju/+filebug
[09:49] <yan0s> caused by: Post https://ncc_url:8774/v2.1/servers: EOF
[09:51] <stickupkid> yan0s, what's the provider you're bootstrapping to (lxd, manual, MAAS)?
[09:51] <yan0s> openstack
[09:51] <yan0s> rocky release
[09:58] <danboid> stickupkid, I'm running lxd init on my maas controller. I said yes to "Would you like to connect to a MAAS server" now it is asking for an API key. Should I create a new MAAS user just for lxd or use my personal API key or...
[10:01] <parlos> anyway to 'replace' a machine that failed in a deployment. Without destroying the model and redeploying it?
[10:02] <danboid> stickupkid, I suppose the idea would be that every maas user would have their own juju controller/API key?
[10:03] <danboid> stickupkid, So is it not possible for multiple maas users to share a juju controller?
[10:04] <parlos> danboid, afaik no...
[10:04] <stickupkid> danboid, so you would allow juju to manage maas and allow juju manage the users...
[10:04] <stickupkid> danboid, see `juju users --help`
[10:05] <stickupkid> parlos, remove-machine?
[10:07] <parlos> danboid; In my setup, I've got one juju controller on it i deploy models from different different maas users/keys. So, enables me to track (on Maas) what nodes are ued by what user.. (would be nice to push tags from juju to maas during deployment)
[10:07] <parlos> stickupkid, would remove-machine trigger a redeployment of the apps that were destined for that machine?
[10:08] <stickupkid> parlos, nope, you'd have to use `--to` directive
[10:08] <stickupkid> when deploying
[10:09] <danboid> parlos, That sounds like a setup I want to try. So when you were configuring lxd, which API key did you give it?
[10:09] <parlos> stickupkid, so the work around would be to allocate a new machine, move the units to that machine and then remove the machine that failed...
[10:10] <stickupkid> parlos, rick_h would know more tbh
[10:10] <danboid> parlos, I'm configuring lxd on my maas controller, gonna run a juju controller on there too
[10:10] <stickupkid> he comes online soon
[10:11] <parlos> stickupkid, ok. Will submit bug, and hang around.
[10:20] <danboid> lxd init failed: `Couldn't find the specified machine`. When it asked "What's the name of this host in MAAS` I just gave the hostname of the MAAS controller which was the default but there is obvs some more, missing config
[10:21] <danboid> Hmm. No. Under MAAS General, MAAS name the controller has a name which is the same as the hostname so I dunno why lxd init failed
[10:23] <danboid> Maybe I can get away with skipping the MAAS options in lxd init if it is running on the same machine?
[10:26] <danboid> maybe it'll let me get away with using 127.0.0.1 for the controller name?
[10:29] <danboid> So I suppose my most important question is, does lxd need to be configured to access/use MAAS at all?
[10:31] <danboid> So long as juju can use lxd fine, is there any need to link lxd and MAAS?
[10:33] <danboid> I suppose I'll just have to try without and see how far I get
[10:50] <danboid> There seems to be a clash between bind running on my MAAS controller and lxd init wanting to create lxdbr0
[10:51] <danboid> So I either install lxd and juju ob a different machine or...
[10:53] <danboid> Not sure there is an or
[10:54] <danboid> unless MAAS doesn't need to use bind/named
[11:00] <danboid> I suppose the other option is to create the bridge interface myself then get lxd init to use that
[11:17] <rick_h> parlos:  no, it won't auto redeploy. Recovery is up to the operator because we don't know what restrictions the operator is expecting. "don't autodeploy to that machine, I'm keeping X and Y on different hosts..." or the like
[11:17] <rick_h> parlos:  so you'd in theory use add-unit for anything running with any constraints/placement notes
[11:18] <rick_h> parlos:  and then yes, remove the machine with the units on it when you were happy to deal with it
[12:00] <magicaltrout> https://discourse.jujucharms.com/t/square-brackets-in-env-vars/2024/2 rick_h !!! any ideas?! :)
[12:14] <parlos> rick_h; would have been nice with replace-machine, that would just deploy a new machine with the same specs as the one that failed...
[14:47] <danboid> Yay! I have a juju controller on my MAAS box now! :)
[14:49] <danboid> No idea what to do with it now :)
[14:49] <stickupkid> danboid, congrats
[14:49] <stickupkid> danboid, juju deploy :D
[14:49] <danboid> stickupkid, Thanks! :)
[14:50] <danboid> This is to start playing with openstack
[14:50] <danboid> juju deploy openstack ?
[14:51] <danboid> I'm sure there will be a guide online somewhere, I'm just being a bit overly lax :)
[14:53] <pmatulis> danboid, https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/install-openstack.html#deploy-openstack
[14:53] <danboid> pmatulis, Thanks!
[14:54] <pmatulis> danboid, kindly open doc bugs if needed --> https://bugs.launchpad.net/charm-deployment-guide/+filebug
[14:55] <danboid> pmatulis, Yeah. I think the juju install page could do with a bit of tweaking too
[14:55] <pmatulis> danboid, that guide will take you through deploying OpenStack by individual service. you can also try a bundle
[14:56] <pmatulis> it all depends what you want to do/learn
[14:57] <pmatulis> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/install-openstack-bundle.html
[14:57] <danboid> pmatulis, Thanks!
[15:01] <pmatulis> danboid, how many MAAS nodes do you have? and what resources do they have? it's typical to require multiple disks and network cards
[15:05] <danboid> pmatulis, I have 1 MAAS controller with 5 nodes attached. They are Xeons, 3 have 64 GB RAM and 2 have 256 GB. They've all got at least 1 TB of disk space and multiple NICs
[15:06] <danboid> Before I run juju deploy, is it something I need to run under screen/tmux or will it background itself?
[15:06] <stickupkid> achilleasa, when we deploy a bundle, the overlay is merged on to the base bundle yaml, so I can upload that to the server to get the changes?
[15:07] <danboid> I'd imagine there is a bit more config before I can deploy the bundle. I'll need to tell it which nodes to use at least right?
[15:10] <danboid> or does it automaticaly use all available nodes?
[15:16] <pmatulis> danboid, it sounds like you should do some experimenting with stuff that is lighter than openstack
[15:17] <pmatulis> just to get the basics. did you look at the documentation yet?
[15:17] <pmatulis> https://jaas.ai/docs
[15:17] <danboid> Nope. I've been playing with MAAS for a while but not in-depth. I haven't touched juju yet
[15:19] <danboid> The problem is those docs seem to be JAAS centric, rather than focusing on a on-prem juju setup
[15:20] <stickupkid> jam, what happens if you want the BestFacadeVersion, but the facade doesn't exist on old controllers?
[15:22] <danboid> or at least thats the case for the Getting Started guide
[15:22] <pmatulis> danboid, nope. jaas is just one tiny thing in the docs. url notwithstanding
[15:24] <danboid> What would you suggest I try putting together before attempting openstack?
[15:26] <pmatulis> danboid, just go through the main topics in the docs. there are a couple of beginner tutorials
[15:36] <achilleasa> stickupkid: any overlays are sequentially merged to the base bundle. What do you mean by "upload to the server"?
[15:36] <stickupkid> achilleasa, ho?
[15:36] <achilleasa> omw
[15:51] <magicaltrout> hello fine people... if anyone in the US has any clue about https://discourse.jujucharms.com/t/square-brackets-in-env-vars/2024/2 that  would be very useful indeed! ;)
[15:52] <magicaltrout> like, does anyone know if there is something I can do to get GO to parse some YAML read by some Python? or do I need to chop up the upstream container to make it happen?
[15:53] <rick_h> magicaltrout:  was looking...stop breaking things! :P
[15:54] <rick_h> magicaltrout:  I think we'll have to create some test cases and get back to you unfortunately. Honestly it's probably better as a bug
[15:55] <magicaltrout> fair enough. Yeah I dunno what I can try cause I don't know how the yaml -> python -> go handoff works
[15:55] <magicaltrout> so i gave up at that point
[15:55] <magicaltrout> I'll file it and mash up the container for now
[15:55] <magicaltrout> want to get this demo stack done for ApacheCon next week
[16:03] <magicaltrout> https://bugs.launchpad.net/juju/+bug/1842691
[16:03] <magicaltrout> done
[16:04] <mup> Bug #1842691: Array in YAML causes Kubernetes charm failed deployment <juju:New> <https://launchpad.net/bugs/1842691>
[16:21] <stickupkid> achilleasa, i ejected - it would take to long, but my PR for exposing the method on the API server is solid - can you give a CR, i'll start on bringing this into pylib https://github.com/juju/juju/pull/10601
[16:21] <achilleasa> stickupkid: sure, let me check
[17:01] <stickupkid> rick_h, merge master into 2.7 branch, for pylibjuju https://github.com/juju/python-libjuju/pull/353