[04:58] <jam> morning all
[08:37] <DominikF> Morning everyone! So I'm working on a Kubernetes Charm with the new framework, and the docker image I'm using doesn't have python3 installed.  How should I proceed if I want actions? What is the best practice of using actions with bash? Preferably i would install python on the pod each time I instantiate one, but don't know if thats possible.
[08:48] <Chipaca> mo'in!
[08:50] <jam> Hi DominikF. You can do actions in bash, though the python framework obviously can't help you.
[08:50] <jam> You could have a bash script that then installs python, but I'm not sure that fits with how people expect K8s pods to work
[08:51] <jam> You could use the docker image as a base and build another image on top of it that *does* include python
[08:53] <DominikF> jam: yes, I was thinking about something like that, what is your guys plan for this in the future?
[08:54] <DominikF> jam: If I would do it in bash I would I just add an actions folder like in the previous charms?
[08:58] <jam> DominikF, correct. even when using the framework, if you have an actions directory with scripts in there, the framework will call them.
[08:59] <jam> DominikF, "plan for this". How to get python where you need it?
[08:59] <DominikF> jam: yep
[08:59] <jam> morning Chipaca
[09:00] <jam> DominikF, so my recommendation would be to build a container based on the one you want that also includes python, as it seems the most k8s/docker consistent
[09:03] <DominikF> jam: thanks, that clears up my doubts! Just wanted to make sure I'm doing it the right way as we are going to show this Charm in the next OSM Hackfest.
[09:23] <Chipaca> MarkMaglana: I'll reach out to you to get that k8s.py usable via the library/plugin mechanism, early next week
[09:23] <MarkMaglana> Chipaca: rock on!
[09:24] <Chipaca> MarkMaglana: great that you said it was yours, because that was my next task :) figuring out its origin
[09:44] <Chipaca> jam: wrt breaking changes, i'd like to at least talk about moving away from action-as-a-property
[09:44] <Chipaca> but that's a big one, we change that we break everybody :)
[09:44]  * Chipaca breaks the world
[09:44] <Chipaca> good movie, that
[09:44] <Chipaca> er
[09:44] <Chipaca> jam: i said action i meant status
[09:45] <jam> Chipaca, ah, I was a bit confused and started looking at where action was a property. :)
[09:45] <jam> Chipaca, the medium term discussion was that we could do both (have it as a property and as something you can set via method)
[09:45] <Chipaca> jam: and exceptions?
[09:46] <jam> Chipaca, so in my head having exceptions have a status that will be set if they bubble up doesn't have to change *how* we set the status otherwies
[09:47] <Chipaca> jam: I meant: (drop charm.status and instead) have charm.set_maintenance(...) and charm.set_active(...) but raise Waiting() and raise Blocked()
[09:49] <Chipaca> (set_active is a bad name, but you get the idea)
[09:50] <Chipaca> this accomplishes, transparently, the "let me set these while running but only set these at the end", imho
[09:51] <Chipaca> and those same semantics via charm.status = …  are super weird (again imho)
[09:54] <jam> Chipaca, I think you should raise an exception to set Active status... clearly. :)
[09:55] <jam> Chipaca, I like where you're thinking is going, I don't know that we "have to break everyone" to have that behavior, but we could certainly deprecate it, or just break it with a .X release.
[10:10] <Chipaca> jam: in any case we need to fix #278 :)
[10:10] <mup_> Issue #278: Unit.status not unit tested <bug> <Created by jameinel> <https://github.com/canonical/operator/issues/278>
[10:10]  * Chipaca gets on it
[10:10] <Chipaca> jam: dunno if you saw I moved #190 out of draft
[10:10] <mup_> PR #190: README: a significant rework <Created by chipaca> <https://github.com/canonical/operator/pull/190>
[10:17] <jam> Chipaca, commented on 190
[10:26] <Chipaca> jam: right back atcha
[11:06] <Chipaca> jam: should there be an 'invalidate' for _status?
[11:07] <Chipaca> or rather, should Application and Unit have _invalidate i guess
[11:08] <jam> Chipaca, you're trying to invalidate what the status is?
[11:08] <Chipaca> jam: yup
[11:09] <Chipaca> it's cached very aggressively which means the call to status-get is hard to test for reliably :)
[11:10] <facubatista> Muy buenos días a todos!
[11:10] <Chipaca> facubatista: 👋
[11:10] <facubatista> hola Chipaca
[11:14] <jam> morning facubatista
[11:14] <facubatista> hola jam
[11:14] <jam> Chipaca, so status-get has always been a bit weird, because you're the one responsible for telling *us* what the status is
[11:15] <facubatista> jam, let me know when you have a minute to continue (here) my eternal blog-apache talk, thanks
[11:18] <jam> facubatista, just making coffee and then we can chat
[11:18] <facubatista> great, thanks
[11:19] <jam> Chipaca, i'm fine with an invalidate, I would just caution that I don't really want to ever change status 'behind the back' of the charm.
[11:26] <Chipaca> jam: i fear there's a bug
[11:26] <Chipaca> shocking i know
[11:26] <Chipaca> getting details now
[11:26] <jam> Chipaca, no bugs, only opportunities for enlightenment
[11:27] <Chipaca> jam: the harnes's status_get returns the (status, message), or None
[11:28] <Chipaca> jam: and that's then used for StatusBase.from_name(s['status'], s['message'])
[11:28] <Chipaca> jam: neither tuples, nor None, are dicts :-)
[11:29] <jam> Chipaca, indeed, status_set / status_get were certainly something I didn't test via Model
[11:29] <Chipaca> status_set is tested, in     def test_local_set_valid_app_status(self):
[11:29] <jam> Chipaca, I think it was something I threw together as a prototype, and then added tests, but of course, my tests conformed to my implementation, but not to the *contract* of status_get :)
[11:29] <Chipaca> status_get isn't because _status gloms the value
[11:30] <Chipaca> :)
[11:30] <Chipaca> jam: i'll fix
[11:33] <jam> Chipaca, thanks for the catch
[11:37] <facubatista> jam, so, what I did after my talk is to also register my `on_apache_relation_joined` method to the upgrade-charm hook, so I could work on it until I have it in good shape
[11:37] <facubatista> of course, I don't have the relation from the event, so I just grabbed it from elsewhere
[11:37] <jam> facubatista, sorry, I am back if you want to chat
[11:38] <facubatista> so, I first tried this:  relation_data = self.model.get_relation('apache').data['apache2']
[11:38] <facubatista> but I got a  *** KeyError: 'apache2'
[11:38] <facubatista> so I explored a little, and end up doing this:
[11:38] <facubatista>         relation_data = [v for k, v in self.model.get_relation('apache').data.items() if k.name == 'apache2'][0]
[11:39]  * facubatista waits for jam's horror scream
[11:39] <jam> facubatista, it is an Application, not a string
[11:39] <jam> facubatista, relation = self.model.get_relation('apache'); relation_data = relation[relation.app] would work
[11:39] <jam> It isn't how I'd like to see in production code, but for testing things it seems ok
[11:41] <facubatista> jam, it will give me the same thing I grabbed juggling with the code above, right?
[11:42] <jam> facubatista, indeed, but means you can relate to something that isn't exactly named 'apache2' and have it continue to work
[11:42] <facubatista> jam, why you wouldn't want it in prod?
[11:43] <jam> facubatista, for x in y: if x.name == "apache2"
[11:43] <jam> means you can only relate your charm to exactly an application named "apache2"A
[11:43] <jam> if I do "juju deploy apache2 custom-apache" it will break
[11:43] <jam> juju relate custom-apache facus-blog
[11:44] <jam> will look for an object named "apache2"A but only find an object named "custom-apache"
[11:45] <facubatista> jam, ah, I thought that you wouldn't want *your* code snippet in prod
[11:45] <facubatista> of course, I wouldn't want that horrible listcomp from mine in prod either
[11:46] <facubatista> so, let's move to your code
[11:48] <jam> (fwiw, it would be easier to hook into relation-changed, and then use 'juju run --unit apache2/0 relation-set blah=1' to trigger relation-changed again)
[11:48] <facubatista> jam, relation_data = relation[relation.app] --> TypeError: 'Relation' object is not subscriptable
[11:48] <jam> facubatista, relation_data = relation.data[relation.app]
[11:48] <jam> sorry, I left out an attr
[11:50] <facubatista> jam, great, so I reached the same point that yesterday, which originated my question
[11:51] <jam> facubatista, so you're able to trigger the code as you want?
[11:52] <facubatista> jam, yes! and I set data in the relation, data, but then I get a:   ops.model.RelationDataError: cannot set relation data for apache2
[11:53] <facubatista> jam, this is the method code and log relevant part, fwiw: https://paste.ubuntu.com/p/C82HRtdDtY/
[11:54] <jam> facubatista, relation.data[relation.app] is the data being sent by apache2
[11:54] <jam> to set data you need to
[11:54] <jam> relation.data[self.app]
[11:55] <jam> eg, set the data in *your* bucket, so that the other units can read the data you are sending.
[11:59] <facubatista> so frustrated with this
[11:59] <facubatista> I still feel it backwards
[12:04] <jam> facubatista, you are telling apache about yourself, not telling it how it should be configured.
[12:04] <jam> what happens when there are 3 different relations to apache, each one can't set apache directly
[12:04] <facubatista> but, but... I DO want to tell it how it should be configured!!
[12:04] <jam> they tell apache about themselves and apache responds
[12:05] <facubatista> how it should be configured *regarding me*, of course
[12:05] <facubatista> why would I want to tell apache how it would be configured regarding somebody else?
[12:06] <facubatista> jam, how many "buckets" may we have in relation.data ?
[12:07] <jam> facubatista, each unit and each app has their own bucket
[12:07] <facubatista> jam, each unit/app in the whole system, or in the relation?
[12:07] <jam> in the relation
[12:07] <facubatista> so, always four? two on the other end of the relation, and two here?
[12:09] <jam> facubatista, well, more if you have more than 1 unit on either ide
[12:09] <jam> side
[12:10] <facubatista> and in "this side" always two, right?
[12:13] <jam> a given unit will have its data bucket which it can read/write. and it can read other units data, and the remote app data
[12:13] <jam> if it is the leader, it then also gets to read/write its app data bucket
[12:20] <jam> Chipaca, I've tested #283 with Juju 2.7 and 2.8 and a couple permutations of symlinks vs shell scripts
[12:20] <mup_> PR #283: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
[12:20] <jam> I think we should probably land it, but it doesn't handle Juju 2.7 and hooks/install is a script
[12:20] <jam> (it thinks it is being invoked as dispatch but no JUJU_DISPATCH_PATH is set)
[12:20] <jam> I'm not sure if we *can* support that case
[12:26] <facubatista> jam, is this accurate? https://docs.google.com/document/d/1EXXsHXOb3ECAev-M2M2IIljnWgXEenrX2g86b57Wwwo/edit (feel free to edit to improve wording) -- thanks!!
[12:27] <jam> facubatista, "how the other end presents to you", "what the other end is presenting to you" might be clearer,
[12:27] <jam> but yes, looks correct to me
[12:28] <facubatista> clearer how? I think being as precise as possible there improves the value, I was vague, but because I lack deep understanding of that point exactly
[12:35] <jam> It feels like it is clearer English.
[12:35] <facubatista> "Virtual host templates can also be specified via relation. See the vhost-config relation section below for more information." <-- aja! I'm setting the data in the wrong relation
[12:36] <facubatista> " A candidate charm should provide a relation on the apache-vhost-config interface." ... /me adds a "provides" in blog's metadata yaml
[12:38] <jam> facubatista, apache-website docs say "site_config- A vhost configuration block"
[12:39] <facubatista> jam, yeap
[12:40] <facubatista> jam, I'm setting this: https://paste.ubuntu.com/p/QhhFd3w4KH/
[12:40] <facubatista> (but IIUC in the wrong relation)
[12:42] <jam> looking at https://api.jujucharms.com/charmstore/v5/apache2-35/archive/hooks/hooks.py it looks to write out a file into sites_dir/name.conf containing the vhost config
[12:44] <facubatista> jam, you're cheating looking at the apache's charm source code, if we want wide adoption the docs should be clear enough :p
[12:45] <jam> facubatista, I'm not trying to fix legacy/reactive charms just yet.
[12:45] <jam> I don't disagree, but that is future world
[12:45] <facubatista> jam, note that there are two ways of setting the config
[12:45] <facubatista> jam, one through a config change, other through the vhost relation, which allows to be set *from the subordinate charm*
[13:05] <jam> facubatista, can you look at #264 again? I think I cleaned up the merge.
[13:05] <mup_> PR #264: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <https://github.com/canonical/operator/pull/264>
[13:05] <facubatista> jam, will do, yes
[13:06] <jam> thx
[13:18] <facubatista> Chipaca, I was wrong, Enum defaults to a nice way of seeing the value:
[13:18] <facubatista> >>> Relations = enum.Enum('Relations', 'PEER PROVIDES REQUIRES')
[13:18] <facubatista> >>> str(Relations.PEER)
[13:18] <facubatista> 'Relations.PEER'
[13:18] <mup_> PR operator#284 opened: ops/model: cover app.status and unit.status better <Created by chipaca> <https://github.com/canonical/operator/pull/284>
[13:18] <jam> facubatista, internally they are still ints, though. right?
[13:18] <facubatista> (if you do repr() you will see the underlying int... but you can also define the internal values as the same string, which I'm not sure it's needed)
[13:19] <facubatista> jam, they're by default, yes
[13:19] <jam> Chipaca is trying to make it look like he was working today instead of just galavanting around in his backyard
[13:19] <facubatista> jam, galavanting?
[13:19]  * Chipaca gallivants with flair
[13:19] <jam> "go around from one place to another in the pursuit of pleasure or entertainment."
[13:20] <facubatista> "less common spelling of gallivant"
[13:20] <jam> just misspelled :)
[13:29] <facubatista> jam, +1 to 264, please see the comment, thanks!
[14:11] <Chipaca> jam: i'm going to emulate the "2.7 with dispatch and hooks/install not a symlink" by also supporting "no dispatch and hooks/install not a symlink" directly (which i think master supports)
[14:12] <jam> Chipaca, so hooks/install as a script works if you set JUJU_DISPATCH_PATH, but 2.7 won't be setting that
[14:13] <jam> which is the thing we need to fix
[14:13] <Chipaca> yep yep
[14:13] <jam> "no dispatch and hooks/install is a script and no JUJU_DISPATCH_PATH" sounds great
[14:19] <jam> So it seems that since ops is part of 'github.com/canonical' we end up getting serialized in travis with all other Canonical projc.ts
[14:36] <MarkMaglana> good meeting! glad i could help!
[14:36] <facubatista> MarkMaglana, :)
[15:35] <Chipaca> jam: i didn't realise you were still around, i pushed the signature fix to 264 for you
[15:35] <jam> Chipaca, I stopped by to check on the progress, and was pleased to see that you fixed my bug for me
[15:35] <Chipaca> jam: now travis is being travis
[15:35] <jam> Chipaca, not really around :) Just trying to follow up on my PR before the weekend
[15:35] <jam> it just started mine again
[15:37] <jam> Chipaca, from what I can tell, Travis will only let 2 jobs from 'canonical' run, and multipass has a 2hr job
[15:38] <Chipaca> jam: the limit is 5 simultaneous workers, for free tier users
[15:39] <jam> Chipaca, clearly that isn't the number they are actually running
[15:39] <Chipaca> jam: 264 now green fwiw
[15:39] <jam> Chipaca, yeah, I'm writing the commit now
[15:40] <Chipaca> jam: per organisation? i see 3 in use for cloud-init right now for example
[15:41] <jam> Chipaca, ah, I only see 1 "job" but it is a top level job. I guess it is indivi
[15:41] <jam> sub jobs that are limited to 5
[15:41] <Chipaca> yeah, by workers i meant the vms
[15:42] <Chipaca> you can limit it to less than 5 to be fairer within the org
[15:42] <Chipaca> or you can pay them :)
[15:42] <jam> landed #264
[15:42] <mup_> PR #264: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/264>
[15:43] <Chipaca> woop woop
[15:43] <mup_> PR operator#264 closed: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/264>
[16:28] <facubatista> jam, pushed another version of charmcraft#1 and answered all conversation
[16:28] <facubatista> s
[16:28] <mup_> PR charmcraft#1: Charmcraft tool base skeleton <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/1>
[16:53] <Chipaca> facubatista: thanks for the review on 190, i've commented out the TBD links
[16:57] <facubatista> Chipaca, in #283 I'm really confused about "legacy"... you wrote a "run_any_legacy_hook" method that starts working with "dispatch" (which is not a legacy hook, right?), and if dispatch is not there, it's looged like "Legacy <this> is not there"
[16:57] <mup_> PR #283: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
[16:57] <facubatista> Chipaca, mind to explain that a little to me? thanks!
[16:58] <Chipaca> facubatista: say you have a charm running under 2.8
[16:59] <Chipaca> facubatista: and your charm has a dispatch file
[16:59] <Chipaca> facubatista: and your charm also has hooks/install
[16:59] <Chipaca> facubatista: juju will see the dispatch file and call it, ignoring all hooks/* guff
[16:59] <facubatista> yes
[17:00] <Chipaca> facubatista: it is dispatch's responsibility to call the legacy hooks/install file
[17:00] <facubatista> yes
[17:00] <Chipaca> facubatista: the end
[17:00] <facubatista> not the OF
[17:00] <Chipaca> facubatista: not the OF?
[17:00] <Chipaca> ah, the operator framework
[17:00] <Chipaca> facubatista: what do you mean, not the OF?
[17:02] <facubatista> mmm... I was expecting that if the developer put a dispatch file, and still wanted her hooks/* scripts to be called, that she would handle that in the dispatch file
[17:03] <facubatista> but yes, we could handle that
[17:03] <facubatista> and put a dispatch that is a symlink to the source, and we'll make the hooks/* to be called
[17:03] <Chipaca> facubatista: that is already supported
[17:03] <facubatista> if she doesn't want the hooks/* to be called after setting the dispatch file, she can remove them
[17:04] <Chipaca> facubatista: this is about dispatch being a shim that still calls us, we still need to do this -- or the shim does, but we want the shim to be minimal
[17:05] <Chipaca> facubatista: for a custom dispatch all they need to do is unset the appropriate variable
[17:05] <Chipaca> facubatista: and everything would carry on as before :)
[17:05] <facubatista> unset which variable?
[17:05] <Chipaca> MAKE_FACUNDOBATISTA_GREAT_AGAIN
[17:06] <Chipaca> facubatista: or maybe JUJU_DISPATCH_PATH
[17:06] <Chipaca> facubatista: if JUJU_DISPATCH_PATH is unset by dispatch, and they then execute e.g. hooks/install (that's a symlink to src/charm.py), it'll Just Work (tm)
[17:07] <facubatista> yes
[17:07] <Chipaca> facubatista: anything else i can answer? otherwise i'm going to eod
[17:08] <facubatista> Chipaca, I need to see this with fresher eyes, no worries
[17:08] <Chipaca> i can mail you one of my son's eyes
[17:08] <Chipaca> i'm sure they won't mind
[17:08] <Chipaca> they've got, like, four of them
[17:39] <facubatista> each?? :p
[19:07] <Chipaca> facubatista: yours dont?!?
[19:08] <facubatista> Chipaca, nop, only two eyes per kid... shall I ask for a rebate?
[20:03] <Chipaca> facubatista: are you sure they're not halflings?
[20:04]  * facubatista checks in the kids documentation
[20:30]  * facubatista is out
[20:35] <Chipaca> facubatista: take care
[20:35] <Chipaca> i too should wrap
[20:35] <facubatista> Chipaca, hasta mañana
[20:35] <Chipaca> facubatista: disfrute