| jam | morning all | 03:56 |
|---|---|---|
| t0mb0 | this may or may not be an operator specific problem but i'll ask here - how would one ensure a container is secured with TLS? Should the operator framework create an ingress or is that a Juju thing? jam you may know? | 07:49 |
| t0mb0 | I would have imagined that the operator pod would form a http relation with the ingress perhaps? | 07:50 |
| t0mb0 | I've set the charm options juju-external-hostname and kubernetes-ingress-allow-http=true however I'm not seeing any ingresses being created! | 07:51 |
| t0mb0 | note - I am using microk8s not charmed k8s | 07:55 |
| niemeyer | t0mb0: The answer depends on the charm and the interface being used indeed.. TLS is used by several independent protocols (we're doing IRC over TLS just now) | 08:03 |
| niemeyer | t0mb0: Is the question specific to microk8s? | 08:04 |
| jam | t0mb0, have you done "microk8s enable ingress" ? | 08:05 |
| jam | https://microk8s.io/docs/addons | 08:05 |
| jam | I believe for Juju itself you need to enable "dns" and "storage" but if the applications you're deploying need other K8s services like an ingress controller, then you need to have those enabled as well. | 08:06 |
| niemeyer | Morning jam | 08:10 |
| jam | morning niemeyer | 08:10 |
| t0mb0 | jam, thanks! I believe microk8s enable ingress was what I was looking for | 08:16 |
| t0mb0 | thanks for your input too niemeyer | 08:17 |
| niemeyer | t0mb0: np, glad it's sorted | 08:25 |
| jam | hi Chipaca . just in time for me to step out for lunch :) | 08:44 |
| Chipaca | jam: good morning! buen provecho :) | 08:45 |
| niemeyer | > We should be consistent on ordering. However, I do believe 'unittest.assertEqual' assumes (expected, actual) ordering. Because if you do: | 08:55 |
| niemeyer | jam: Added another comment there.. I don't think that's true. | 08:55 |
| niemeyer | Let's please keep the usual obtained, expected order.. even the examples in unittest.py itself order like that. | 08:56 |
| niemeyer | Also: https://github.com/python/cpython/tree/3.7/Lib/unittest/test | 09:03 |
| Chipaca | niemeyer: what should I see in that link? | 09:07 |
| niemeyer | Tests? :) | 09:07 |
| niemeyer | Chipaca: It's the tests for unittest itself | 09:07 |
| Chipaca | ah, gotcha | 09:07 |
| niemeyer | Chipaca: All of them follow obtained, expected.. | 09:07 |
| niemeyer | So it'd be slightly awkward if the author intended the opposite | 09:08 |
| Chipaca | i wonder why they chose the diff to go in the opposite direction then | 09:08 |
| niemeyer | Chipaca: I don't see it as reversed | 09:08 |
| niemeyer | Chipaca: I actually don't even know what I expect myself in that sense, though, to be honest | 09:09 |
| Chipaca | fair | 09:11 |
| jam | so my first hit for: "python unittest assertEqual expected" was that it was "expected, actual" according to xUnit conventions | 09:11 |
| jam | Python itself carefully says "first, second" | 09:12 |
| niemeyer | jam: Not so carefully, though.. just read the docstrings of these functions | 09:12 |
| jam | but the diff does read backward in my head for that. (this has been added / missing relative to?) | 09:12 |
| niemeyer | self.assertEqual(the_exception.error_code, 3) | 09:13 |
| niemeyer | This is in the docstring of assert raises | 09:13 |
| niemeyer | I find ("foo" == var) inverted given years of reading it the other way around, but I wouldn't mind adapting if we were following a pattern.. But we are not.. we'd both be making it awkward based on common style, and on the intended form of the testing library we use, so I'm -1 on it | 09:14 |
| niemeyer | jam: Isn't xunit coming from Java? | 09:15 |
| jam | https://bugs.python.org/issue10573 seems to be the bug, mfoord raised the issue of ordering so you get appropriate diffs | 09:17 |
| jam | https://mail.python.org/pipermail/python-dev/2010-December/106954.html is Guido's comment on it | 09:17 |
| jam | (old, new) matches diff and matches (expected, actual), but intentionally using "first, second" in the code instead. | 09:18 |
| jam | so, its fine, we can go with unittest's convention, but it does mean that all the diffs are "how expected differs from actual" rather than "how actual differs from expected" | 09:18 |
| niemeyer | This second link makes me sad.. | 09:19 |
| niemeyer | It's a glimpse of poor leadership.. | 09:19 |
| niemeyer | "Yeah, we do use that ordering in our code everywhere, but people elsewhere use different conventions.. so we don't care.. do whatever." | 09:20 |
| niemeyer | Multiply that by 3 decades, and bingo.. | 09:21 |
| jam | there is also https://youtrack.jetbrains.com/issue/PY-26471 for the ordering in PyCharm. | 09:23 |
| jam | And their example tutorial actually puts it as assertEqual(foo, 10), but then prints Expected: 'foo', Actual: 10. | 09:24 |
| jam | First, Second at least tells you where to look and makes you actually figure out which is expected and what is actual. | 09:24 |
| jam | I'll clean up Harness. | 09:24 |
| jam | to conform | 09:24 |
| niemeyer | Haha, priceless :P | 09:25 |
| mup_ | PR operator#235 opened: test/test_harness.py: Fix the ordering to assume actual/expected <Created by jameinel> <https://github.com/canonical/operator/pull/235> | 09:42 |
| facubatista | Muy buenos días a todos! | 11:01 |
| jam | morning facubatista | 11:01 |
| facubatista | hola jam | 11:01 |
| niemeyer | Morning Facundo | 11:11 |
| facubatista | hola niemeyer :) | 11:13 |
| facubatista | jam, I don't understand your comment about not replacing 'juju_exec_path' in Chipaca's branch | 11:53 |
| jam | facubatista, juju_exec_path = juju_exec_path.parent / dispatch_path | 11:54 |
| facubatista | jam, IIUC, we need to check if the juju_exec_path exist *and if it's not ourselves* (that check still missing), and only then execute it... but if we decide to execute it, we'll replace it, right? | 11:54 |
| jam | If you replace it, it becomes harder to tell "if it is ourself" | 11:54 |
| facubatista | jam, but that verification should be done before | 11:55 |
| jam | facubatista, well, I would expect to be done right around that point, as that is the point you are seeing if it exists and what it points at | 11:56 |
| Chipaca | yes that check is still missing, fwiw | 11:56 |
| facubatista | if juju_exec_path.exists() and juju_exec_path.resolve() != Path(sys.argv[0]).resolve(): | 11:57 |
| facubatista | jam, I'd do something like ^ | 11:57 |
| jam | facubatista, sure. my point was that juju_exec_path was already Path(sys.argv[0]), so you could just use it if you don't replace the var first. | 11:57 |
| facubatista | ack | 11:58 |
| pekkari | Hi guys, is there currently a path to retrieve the ip address of a unit? Model seems to hint you have to traverse the BindingMapping of the full model if you want so | 12:09 |
| Chipaca | pekkari: I don't think there is another way | 12:14 |
| Chipaca | pekkari: i'm not even sure there is an ip address of a unit without reference to a binding, so it's not clear to me this is a deficiency | 12:15 |
| jam | pekkari, in the juju model, you might be deployed to a machine that has multiple network cards and the operator wants different applications on different interfaces, so you have to go via the binding so the operator can tell you how that piece is configured. | 12:24 |
| jam | there is no "one true IP" for a unit as a whole | 12:24 |
| pekkari | yeah, multiple addresses is certainly something I understand, I'm just struggling to find from a charm event the way up to an ip address related to the binding of the relation we run on | 12:27 |
| jam | pekkari, def _on_changed(self, event): self.model.get_binding(relation_name).network ? | 12:31 |
| jam | are you in a Charm, or in a separate component ? | 12:31 |
| jam | binding key can be a relation as well, so if you wanted | 12:32 |
| pekkari | jam that may be it | 12:32 |
| jam | self.model.get_binding(event.relation) | 12:32 |
| pekkari | I'm in a charm, defining the on_identity_service_relation_joined, and there I need the ip of the binding it talks to keystone | 12:32 |
| jam | pekkari, I don't think you tell Keystone about the network details to keystone. I would expect you to tell keystone about some other binding. | 12:33 |
| pekkari | erm no, this charm tells it's ip address in the binding to keystone to setup the endpoint url | 12:34 |
| jam | pekkari, OS traditionally had public/private/admin bindings to describe the application you were deploying, so that would be, self.model.get_binding('public') | 12:34 |
| jam | pekkari, I would expect that a sysadmin would configure the binding of the keystone endpoint to "how keystone should talk to my app" but what you want to tell Keystone is "how should other apps (eg neutron/nova/etc) talk to my app" | 12:35 |
| jam | which is not the binding of the relationship to keystone, but a different binding on your charm. | 12:35 |
| pekkari | that is very true, however hardcoding the public binding makes me wonder if there is a better way to put it | 12:36 |
| pekkari | certainly may not be a problem, at the end of the day, you only want the service to be reached in public space | 12:37 |
| jam | pekkari, if its your charm, you define what endpoint you are advertising to keystone | 12:38 |
| pekkari | it may be right jam, as long as if you want another you can simply configure the public binding to point to another space | 12:38 |
| jam | if it is "all openstack charms", then you can pass in the name of the public binding in __init__ and have your code track that. | 12:38 |
| jam | pekkari, correct. that is the point of having an endpoint that sysadmins can bind | 12:39 |
| pekkari | thanks for the guidance! | 12:39 |
| * facubatista brb | 12:53 | |
| mup_ | PR operator#235 closed: test/test_harness.py: Fix the ordering to assume actual/expected <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/235> | 12:53 |
| Chipaca | facubatista: didn't #209 fix #198 ? | 12:57 |
| mup_ | PR #209: Enable stderr logging if JUJU_DEBUG is set <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/209> | 12:57 |
| mup_ | Issue #198: DEBUG log messages not emitted <bug> <Created by stub42> <https://github.com/canonical/operator/issues/198> | 12:57 |
| Chipaca | jam: or you :) | 12:57 |
| jam | Chipaca, no. I didn't do both at the same time. We still only put INFO messages to juju-log, as it wasn't clear to me if we wanted to change that behavior. I wasn't clear why we didn't default to DEBUG from the start, so I needed to understand that first. | 12:58 |
| jam | its a trivial change to change the level of that logger | 12:59 |
| jam | Chipaca, https://paste.ubuntu.com/p/3xf4gPctxV/ | 12:59 |
| jam | its just a question of why was it at INFO to start with, and if we chose to change it, is a small fix for 198 | 12:59 |
| facubatista | jam, Chipaca, we want that by default only INFO messages go to juju, and if charm developer decides to send DEBUG too, to be achievable (users always can control the level they see through `juju debug-log`, anyway) | 13:04 |
| facubatista | for that behaviour to happen, we need: | 13:04 |
| facubatista | - the juju handler to be in DEBUG level | 13:04 |
| facubatista | - the logger to be in INFO by default <-- this is what the charm developer can control | 13:04 |
| facubatista | I still didn't prepare a branch for #198 because I still do not understand how the charm code could change the log level according to something external, and if we could do that automatically | 13:05 |
| mup_ | Issue #198: DEBUG log messages not emitted <bug> <Created by stub42> <https://github.com/canonical/operator/issues/198> | 13:05 |
| facubatista | (so the charm would emit INFO or DEBUG according to something, not harcoded) | 13:06 |
| jam | facubatista, so if we call 'juju-log' then Juju itself will filter based on 'juju model-config logging-config' | 13:14 |
| jam | facubatista, we could ask for a way for juju to tell us a given unit's logging config, if we wanted to avoid triggering juju-log in the first place | 13:14 |
| facubatista | jam, but we'd need to ask that for every message, right? as it may change at anytime | 13:15 |
| jam | facubatista, so it can, but I could say that we don't notice a change inside a single hook execution | 13:15 |
| facubatista | jam, I like that optimization! JujuLogHandler will stop executing an external process for each message if it makes no sense | 13:17 |
| facubatista | jam, and all we need to do for that is set the level in JujuLogHandler according to what the config of the unit | 13:17 |
| jam | facubatista, it would need a juju change, so we'd have to deal with versions-of-juju, etc. | 13:17 |
| facubatista | if we have it, we use it | 13:18 |
| Chipaca | facubatista: jam: i think it's an optimisation we can add when/if juju gets the feature | 13:18 |
| facubatista | it's a good way also to "control the level of the charm"? | 13:19 |
| facubatista | or there's a better way? | 13:19 |
| facubatista | my point is: | 13:19 |
| facubatista | I have 5 units with 5 charms; I call `juju debug-log` with level in DEBUG because I want to see debug messages of *one* of those charms, the rest I want to see them in INFO ... which is the best way to achieve that? | 13:20 |
| facubatista | jam, which is the unit's logging level by default? | 13:21 |
| Chipaca | facubatista: juju debug-log --include=theunit ? | 13:24 |
| Chipaca | The '--include' and '--exclude' options filter by entity. The entity can be | 13:24 |
| Chipaca | a machine, unit, or application for vm models, but can be application only | 13:24 |
| Chipaca | for k8s models. | 13:24 |
| facubatista | Chipaca, that will not show me the other ones ... my point is seeing all of them, one in DEBUG the rest in INFO | 13:28 |
| facubatista | jam, how do I change the unit's logging config? | 13:28 |
| jam | facubatista, 'juju model-config logging-config="unit.?=INFO"' | 13:29 |
| jam | by default 'unit=DEBUG' | 13:29 |
| jam | you can do | 13:29 |
| jam | 'juju model-config logging-config' | 13:29 |
| jam | to see what the default ais | 13:29 |
| facubatista | <root>=INFO;unit=DEBUG | 13:30 |
| facubatista | root? | 13:30 |
| jam | juju model-config "logging-config=<root>=INFO;unit.unit-postgresql-0=DEBUG;unit=INFO" | 13:44 |
| jam | facubatista, ^^ | 13:44 |
| Chipaca | parallalysed == paralysed by parallelism | 13:56 |
| jam | niemeyer, https://github.com/canonical/operator/pull/196 still needs your follow up review | 14:09 |
| mup_ | PR #196: Factor out the Harness changes for test_model.py <Created by jameinel> <https://github.com/canonical/operator/pull/196> | 14:09 |
| jam | facubatista, I think #230 doesn't have a comment from you yet. but I think I addressed Chipaca's comments. | 14:09 |
| mup_ | PR #230: Testing harness no events for own data <Created by jameinel> <https://github.com/canonical/operator/pull/230> | 14:09 |
| jam | niemeyer, looking at 196, I see a couple things that I think have been superseded. wait on that one until tomorrow. | 14:10 |
| niemeyer | jam: ack | 14:11 |
| jam | Id like to land 230 and then clean up the diff | 14:11 |
| facubatista | jam, will check | 14:12 |
| jam | th | 14:12 |
| jam | thx | 14:12 |
| Chipaca | travis is slow today | 14:13 |
| Chipaca | i guess it's because we share org with something else | 14:13 |
| niemeyer | jam: Added a comment in #230 | 14:13 |
| mup_ | PR #230: Testing harness no events for own data <Created by jameinel> <https://github.com/canonical/operator/pull/230> | 14:13 |
| niemeyer | jam: As I said, looks reasonable overall.. was just curious about that small detail | 14:14 |
| Chipaca | how reasonable would it be to make it so that, if you execute your charm directly with no JUJU_ stuff defined (or maybe the trigger is running it from a terminal) you get an interactive session? | 14:15 |
| Chipaca | like ipython with the charm already built for you to play with | 14:16 |
| jam | Chipaca, so there are a bunch of bits that you'd need (what is your unit name, what app are you, what is your config, etc). that makes it a bit hard to be initialized and interactive without sufficient context to know what to actually do | 14:16 |
| jam | what 'hook' are you wanting to run right now. | 14:16 |
| niemeyer | Chipaca: That sounds like a pretty cool idea | 14:16 |
| niemeyer | jam: Imagine dropping it in a shell with a Harness | 14:16 |
| facubatista | that would be neat | 14:17 |
| Chipaca | if we could do it without a harness even better (but yeah that'd require _some_ JUJU_ stuff | 14:17 |
| Chipaca | um | 14:17 |
| jam | niemeyer, I think having a good way to do that is great. I don't think 'dispatch' would quite be the entry point for that. | 14:17 |
| Chipaca | does 'juju ssh' give you JUJU_ things? | 14:17 |
| jam | Chipaca, 'juju run --unit X' does, IIRC | 14:18 |
| niemeyer | jam: It might error out nicely saying "Hey, you are not in a juju environment.. if you wanna play, try dispatch --foobar" | 14:18 |
| Chipaca | yeah something like that | 14:18 |
| Chipaca | all the things :) | 14:18 |
| niemeyer | Chipaca: Not sure we could do without a harness.. as jam mentioned, there's a bunch of things required. It's hard to do something when there's no data, no CLIs, no ... | 14:18 |
| Chipaca | yep | 14:18 |
| Chipaca | i'll try to spec it out a bit more so we can discuss (mostly just with examples of what i'd like to see) | 14:19 |
| Chipaca | now that i know it's not completely zany :) | 14:19 |
| niemeyer | Thanks for that | 14:20 |
| jam | niemeyer, so 'relation.data[entity]' doesn't load that entities data until you do something with it. It actually doesn't even load the data if you do "relation.data[entity]['foo'] = 'bar'" because it doesn't need to know the old content of foo to set it to bar | 14:37 |
| jam | it only loads it if you access foo, or iterate or len(relation.data[entity]) | 14:37 |
| niemeyer | jam: Makes sense. Would you mind to add a short note stating that, just to remind the next reader? | 14:38 |
| jam | sure | 14:38 |
| niemeyer | Thanks! | 14:38 |
| jam | niemeyer, I confirmed with some debug statements inside the _load when you wouldn't want it to be loaded. :) | 14:40 |
| * jam heads for EOD | 14:41 | |
| niemeyer | Cheers | 14:43 |
| niemeyer | jam: Have a good EOD | 14:43 |
| * Chipaca shakes fist at multipass | 15:04 | |
| * facubatista -> lunch | 15:07 | |
| Chipaca | stub: 👋 | 15:14 |
| Chipaca | stub: is there a usable-for-simple-stuff postgres interface I could use? | 15:15 |
| Chipaca | facubatista: 2FA shenanigans, i'll be there as soon as it lets me | 16:00 |
| Chipaca | wait, google signed me out everywhere again | 16:01 |
| Chipaca | sigh | 16:01 |
| Chipaca | facubatista: I'm guessing something's come up at your end as well. Let's reschedule. | 16:09 |
| mup_ | Issue operator#231 closed: Harness: Has errors on charms which define action handlers <Created by Vultaire> <Closed by chipaca> <https://github.com/canonical/operator/issues/231> | 16:10 |
| mup_ | PR operator#232 closed: ops.testing.Harness actions metadata support. (#231) <Created by Vultaire> <Merged by chipaca> <https://github.com/canonical/operator/pull/232> | 16:10 |
| niemeyer | Chipaca: Is there something holding #203 back still? | 16:11 |
| mup_ | PR #203: ops, test: revert the EventSet change, make EventsBase ObjectEvents <Created by chipaca> <https://github.com/canonical/operator/pull/203> | 16:11 |
| Chipaca | niemeyer: a review? (and now a deconflict also) | 16:11 |
| niemeyer | We should make a push to these old PRs through or out | 16:11 |
| niemeyer | Chipaca: My +1 has 12 days | 16:12 |
| facubatista | Chipaca, grrr, had the alarm off, sorry | 16:14 |
| * facubatista is back | 16:14 | |
| Chipaca | facubatista: huh | 16:29 |
| Chipaca | facubatista: https://github.com/canonical/operator/blob/master/test/test_framework.py#L773 | 16:29 |
| Chipaca | is a bit weird | 16:29 |
| Chipaca | I think you meant FooEvent(EventBase) | 16:29 |
| Chipaca | I'm mostly-EOD. Might pop in later to tinker with dispatch a little as i'm behind on where i wanted to be. | 17:04 |
| Chipaca | 👋 | 17:04 |
| * facubatista brb | 17:09 | |
| facubatista | niemeyer, did you read this? https://setuptools.readthedocs.io/en/latest/pkg_resources.html#entry-points | 20:01 |
| niemeyer | facubatista: I hadn't, will look in detail tomorrow, thanks! | 20:05 |
| facubatista | :) | 20:06 |
| * facubatista eods | 21:22 | |
| mup_ | PR operator#203 closed: ops, test: revert the EventSet change, make EventsBase ObjectEvents <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/203> | 21:59 |
| === narindergupta is now known as narinderguptamac | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!