[00:17] <kelvinliu> wallyworld_:  https://github.com/juju/juju/pull/11120. +1 plz
[00:21] <lucidone> Is there a full spec for the charm metadata.yaml somewhere?
[00:22] <lucidone> Specifically after info for oci-image resources - https://discourse.jujucharms.com/t/charm-metadata/1043 says '"file" is the only type supported currently' ..which is outdated
[00:43] <thumper> wallyworld_: ^^
[00:43] <thumper> lucidone: I'm not sure if there is a full spec defined anywhere... there should be
[00:43] <thumper> but I bet many people just read the code (which isn't the right answer)
[00:45] <lucidone> Yea, looking at some code it looks like you provide the default image with resources.X.upstream-source ? .. I would expect a "default" key like in config.yaml though
[00:47] <evhan> lucidone: I think resources: is a hash that the charm can do whatever it wants with.
[00:48] <lucidone> Ah right, that works too I guess :D I wonder what type=oci-image does if that's the case?
[00:49] <thumper> lucidone: wallyworld_ or kelvinliu could probably explain the oci-image type resource
[00:51] <kelvinliu> sorry, just finished standup.
[00:51] <evhan> AFAICT it's to indicate that it's a reference to an image on a registry (as opposed to a file, meaning it's not a filename).
[00:51] <kelvinliu> lucidone: oci-image is the container image path.
[00:51] <thumper> yes, that is right
[00:53] <lucidone> Ah right, so I guess the main difference in handling is because it's _not_ type=file ?
[00:54] <kelvinliu> if u defined the docker image path in metadata.yaml file then u can set it in deployment time like `juju deploy x-charm --resource mysql_image=mariadb
[00:54] <lucidone> So I should have resources.X.oci-image=python:buster?
[00:54] <lucidone> Ah, that's nice behaviour
[00:54] <kelvinliu> the charm then can fetch the resource like `layer.docker_resource.fetch('mysql_image')` then set the podspec
[00:55] <lucidone> How would that look with the operator framework?
[00:57] <kelvinliu> lucidone: so the format of is same like file resource, https://pastebin.ubuntu.com/p/7Qrt6TX7F4/
[00:58] <kelvinliu> sorry, i m not familiar with the new operator framework yet.. but i think the metadata format should be same.
[01:00] <lucidone> Yea, that looks right - I'm just wondering where the default image would fit .. actually looks like OCIImageResource (resources.py) looks for registrypath in the yaml, so that's likely it
[01:00] <kelvinliu> but the way to fetch the resource in charm might use a different helper function.
[01:02] <evhan> lucidone: I'm currently translating it into the Python {'containers': {'imageDetails': {'imagePath': 'YOUR_IMAGE_HERE'}}}, which seems to be what the pod model expects.
[01:02] <kelvinliu> lucidone: https://github.com/johnsca/charm-gitlab-k8s/blob/master/metadata.yaml
[01:02] <kelvinliu> lucidone: jam have shared u an example charm, right?
[01:05] <kelvinliu> lucidone: here is how u can fetch the oci-image in charm https://github.com/johnsca/charm-gitlab-k8s/blob/master/src/charm.py#L38
[01:19] <kelvinliu> lucidone: sorry, missed ur question, how to set default oci-image, so u can attach a resource to charm, then u doesn't have to set --resource in deployment time.
[01:20] <kelvinliu> here is the doc #charm attach https://discourse.jujucharms.com/t/using-resources-developer-guide/1127
[01:22] <lucidone> Great thanks for that - yeap, working things out with a mix of that gitlab charm, operator framework source and discourse
[01:22] <lucidone> And you lot of course :)
[01:24] <kelvinliu> np :)
[04:12] <kelvinliu> wallyworld: did u wanna talk to me? sorry, clicked the btn too quickly..
[04:13] <wallyworld> kelvinliu: all good, jut tanked for for the PR review - all the bakery stuff now landed :-D
[04:13] <wallyworld> *yhanked
[04:13] <kelvinliu> wallyworld: awesome, nice work!
[04:13] <wallyworld> so over it - never want anything from a bakery again
[04:14] <kelvinliu> haha,
[04:19] <kelvinliu> wallyworld: got this PR to fix the annoying error messages of worker restarting, https://github.com/juju/juju/pull/11121/files
[04:19] <wallyworld> looking
[04:19] <kelvinliu> ty
[04:20] <wallyworld> kelvinliu: we dont' want to restart the entire agent - we just need to internally restart the watcher
[04:20] <wallyworld> thomas thinks there may be a new api we can use
[04:21] <kelvinliu> ok
[04:27] <wallyworld> kelvinliu: forgot to ask - is the snap integration done and tested now?
[04:27] <kelvinliu> wallyworld: ah, it should have been done. Im testing the microk8s side with juju now
[05:01] <kelvinliu> wallyworld: free to HO?
[05:02] <wallyworld> kelvinliu: sure
[05:02] <wallyworld> one sec
=== skay is now known as Guest35980
[09:41] <flxfoo> Hi all
[09:42] <flxfoo> quick one, I have a unit in failed state, because of a missing relation... can I remove the relation (which actually does not exists)?
[10:41] <manadart> flxfoo: What is the unit?
[10:41] <manadart> Need a review for migrating remote app macaroons. This should be the last piece for migrating CMRs. https://github.com/juju/juju/pull/11122
[10:57] <flxfoo> manadart: thanks for asking, but I created a new unit... thanks
[11:00]  * manadart nods.
[11:02] <achilleasa> manadart: looking
[11:17] <nammn_de> manadart: i've added your review feedback. Ready for another round: https://github.com/juju/juju/pull/11088
[11:17] <manadart> achilleasa: I had green tests for that, but CI-run is knocking it back. Might have to rebase...
[11:17] <manadart> nammn_de: OK, will look in a mo'
[11:18] <nammn_de> manadart: thanks! I will rebase after successful rev
[11:18] <achilleasa> manadart: code LGTM. I will run the QA steps next
[11:46] <nammn_de> manadart: should I wait for rick_h for ux of the cli (adding additional option/changing output)?
[11:47] <nammn_de> manadart: feel free to bug me if you see the need for me to add additional tests
[12:27] <achilleasa> manadart: got a small typo in consume command for the QA steps; should read "juju consume cmr-source:admin/default.dummy-source"
[12:28] <manadart> achilleasa: Ack. Fixed.
=== Guest35980 is now known as skay
[13:42] <rick_h> nammn_de:  go ahead with it for now to land in edge, please shoot me an email with the notes and I'll try to test it out over the weekend
[13:42] <rick_h> nammn_de:  I don't want to hold you up but not in a position to poke at stuff atm
[13:42] <nammn_de> rick_h: okay :-), will do!
[13:42] <nammn_de> rick_h: can always update /adjust
[13:44] <rick_h> nammn_de:  <3
[13:46] <nammn_de> rick_h: just one thing. Do we want to put in under a featureflag?  Some of those are under "PostNetCLIMVP"
[13:49] <rick_h> nammn_de:  it's only in the develop branch right? As long as it doesn't break things (and a show-* command shouldn't) it's ok
[13:49] <nammn_de> rick_h: right, it does not break anything and is only on develop
[13:50] <nammn_de> rick_h: did you mean, it's ok not to put under a featurebranch, as it is in develop and does not break things?
[13:50] <nammn_de> *featureflag
[13:51] <rick_h> nammn_de:  yea sorry, it's ok to not be flagged
[13:53] <nammn_de> rick_h: 🦸
[14:15] <nammn_de> manadart: I replied to 2 comments with some open questions https://github.com/juju/juju/pull/11088
[14:16] <achilleasa> hml: approved the utils PR. Please ping once you update the toml file on 11094
[14:16] <hml> achilleasa:  i need to update names.v3 as well a quick pr
[14:17] <achilleasa> hml: sure, send it my way
[14:20] <hml> achilleasa: rgr
[14:22] <hml> achilleasa:  i’m going to have to fix the job dependencies before i can merge
[15:56] <achilleasa> hml: don't forget to update title for 11119 ;-)
[15:56] <hml> achilleasa:  :-)
[19:28] <intrepidsilence> Hi everyone!  I have spent many hours on the web looking for an answer to this and I am stumped.
[19:28] <intrepidsilence> I have a new install of juju on an lxd/lxc node
[19:28] <intrepidsilence> juju bootstrap deploy the gui as part of the controller
[19:29] <intrepidsilence> "juju gui" properly spits out the web address of the GUI server
[19:29] <intrepidsilence> including the credentials
[19:30] <intrepidsilence> however, since the juju controller is using a private bridge interface the IP of the controller is private and not accessible remotely
[19:30] <intrepidsilence> since the controller is "hidden" from lxc/d i cannot expose it using a proxy
[19:31] <intrepidsilence> since it is the controller I also cannot use juju expose to expose it since it is not technically an application
[19:31] <intrepidsilence> i even tried ssh tunneling to the private IP and port but that did not work either
[19:31] <intrepidsilence> so I have no idea how I am going to access the GUI on the remote/private controller
[19:32] <intrepidsilence> any ideas will be welcomed with open arms and great thanks
[19:34] <intrepidsilence> fyi - i also tried to deploy juju-gui but that fails with python problems inside of the container it tries to deploy so i am kinda guessing that is not preferred anymore
[20:38] <intrepidsilence> does anyone know if you can tell juju to use the zfs storage pool that you are already using with lxd as the default pool?
[20:38] <intrepidsilence> i cannot seem to find an option for that in bootstrap
[20:41] <thumper> I don't recall, but it certainly seems like a reasonable request
=== narindergupta is now known as narinderguptamac