| bthomas | morning | 09:09 |
|---|---|---|
| facubatista | hola bthomas | 10:32 |
| facubatista | ¡Muy buenos días a todos! | 10:33 |
| Chipaca | facubatista: 👋❗ | 10:33 |
| facubatista | hola Chipaca :) | 10:33 |
| bthomas | नमस्ते facubatista : looks like you beat me to saying hola first today :-). So I am going back to saying नमस्ते | 10:34 |
| bthomas | Mui bein | 10:34 |
| facubatista | bthomas, yes, I read *your* "morning" and reacted to that :) | 10:34 |
| bthomas | :-) | 10:35 |
| Chipaca | facubatista: did you forget to push something to charmcraft#180? not seeing the changes you talk about there | 10:57 |
| mup | PR charmcraft#180: Support to create a library, first step in all the lifecycle <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/180> | 10:57 |
| facubatista | Chipaca, I didn't finish my "reaction to the review" | 11:00 |
| facubatista | (this is a github problem, in launchpad I send the responses to the comments all at the end) | 11:00 |
| Chipaca | facubatista: ␇ shame ␇ | 11:01 |
| Chipaca | facubatista: have you seen simple-term-menu? | 11:35 |
| facubatista | Chipaca, nop | 11:36 |
| facubatista | Chipaca, there I pushed my changes as per your review, note that I answered one of the items with an open question | 11:44 |
| facubatista | Chipaca, the '--lib-name' one | 11:44 |
| facubatista | Chipaca, so I'm happy to land this, but let's talk before about --lib-name | 11:59 |
| Chipaca | facubatista: ok. Why --lib-name and --charm-name for things that can only take one and not the other? is there a case of a command that might take both? | 11:59 |
| Chipaca | facubatista: note how --charm-file is now being a bother when we want to use it for a bundle or a charm, for example | 12:00 |
| facubatista | Chipaca, no case for a command taking both | 12:02 |
| facubatista | Chipaca, so both 'create-lib' and 'list-lib' can get a '--name' (the first one meaning a lib name, the second one meaning a charm name) | 12:03 |
| Chipaca | facubatista: are they optional? | 12:04 |
| facubatista | yes | 12:05 |
| Chipaca | k | 12:05 |
| facubatista | sorry | 12:05 |
| Chipaca | facubatista: what would the help lok like | 12:05 |
| facubatista | list-lib is | 12:05 |
| Chipaca | ah | 12:06 |
| Chipaca | facubatista: if it's not optional it shouldn't be an option (and you know this :) ) | 12:06 |
| facubatista | create-lib has a mandatory "name" parameter, the help is "The name of the library file (e.g. 'db')." | 12:06 |
| Chipaca | ok | 12:06 |
| Chipaca | right | 12:06 |
| Chipaca | yes, that's already so | 12:06 |
| Chipaca | good | 12:06 |
| facubatista | list-lib has an optional "--charm-name", the help is "The name of the charm." | 12:07 |
| Chipaca | facubatista: now, about list-lib, is --charm-name the right thing? | 12:07 |
| Chipaca | the right name for the option i mean | 12:07 |
| Chipaca | for create-lib's argument, 'name' makes the most sense, as what else would it be | 12:07 |
| facubatista | ack, changing it for create-lib | 12:08 |
| Chipaca | facubatista: this is my opinion, not an order :-p | 12:08 |
| Chipaca | pad everything with IMHOs | 12:08 |
| Chipaca | facubatista: i could also argue against myself 🙂 | 12:09 |
| Chipaca | but i'd rather if you did | 12:09 |
| facubatista | for list-lib is less clear | 12:09 |
| Chipaca | facubatista: for list-lib, --charm-name seems … i dunno, overly verbose? | 12:09 |
| Chipaca | OTOH I can see the argument of --name being ambiguous | 12:09 |
| Chipaca | but why not --charm ? | 12:09 |
| facubatista | Chipaca, I like --charm | 12:11 |
| facubatista | "get me all the libraries for this charm" | 12:11 |
| facubatista | s/get/list/ | 12:11 |
| JoseMasson | Good morning! | Buenos días! | शुभ प्रभात! | 12:12 |
| facubatista | hola JoseMasson :) | 12:14 |
| Chipaca | facubatista: OTOH | 12:15 |
| Chipaca | facubatista: what is the label of the table that list-lib produces under which you put the charm's name? | 12:15 |
| Chipaca | facubatista: the option should match that label | 12:15 |
| Chipaca | facubatista: probably(tm) | 12:15 |
| Chipaca | s/table/column of the table/ | 12:16 |
| facubatista | Chipaca, I don't put the charm name in the table (there's no point, all rows would just repeat that) | 12:17 |
| Chipaca | facubatista: but doesn't list-lib list all libs across charms? | 12:18 |
| Chipaca | facubatista: looking at the draft i see it's only ever for one charm | 12:26 |
| facubatista | Chipaca, no, list-lib list all libs for a charm | 12:26 |
| facubatista | right | 12:26 |
| Chipaca | facubatista: but i'm a bit confused because if i do create-lib, the lib i created is not in list-lib | 12:26 |
| facubatista | Chipaca, yes it is, the lib created is for your charm | 12:27 |
| facubatista | list-lib by default lists all libs for your charm, so | 12:28 |
| Chipaca | facubatista: i get 'Noting found.' | 12:28 |
| facubatista | mmm... well, did you *publish* it? | 12:28 |
| Chipaca | no | 12:29 |
| facubatista | anyway, I need to run or I won't get to the bank | 12:29 |
| Chipaca | run run | 12:29 |
| facubatista | we can talk later about this, thanks! | 12:29 |
| Chipaca | i need to have lunch soon or i won't have time for it | 12:29 |
| mup | PR operator#446 opened: Minor clarification for deferred event doc string <Created by balbirthomas> <https://github.com/canonical/operator/pull/446> | 12:43 |
| bthomas | ^ minor doc string update | 12:43 |
| Chipaca | bthomas: s/being/begin/ | 12:55 |
| Chipaca | bthomas: but | 12:56 |
| Chipaca | bthomas: that last statement probably confuses more than it helps | 12:56 |
| Chipaca | bthomas: if you're not already thinking it's some sort of magic continuation, it'll throw you for a loop | 12:56 |
| bthomas | Chipaca: Maybe it is just me but I did have to think about if event.defer() continued from the same point or not. I can remove the second statement but if you have a alternative phrasing I would be interested to know. | 13:00 |
| Chipaca | bthomas: I think it's worthwhile rephrasing the whole thing to make it crystal clear what it does (and what it does not). Let me think about it for a bit. | 13:02 |
| bthomas | Awesome. Just edit the github PR when you do makeup your mind. | 13:02 |
| * bthomas -> lunch | 13:51 | |
| * facubatista is back | 14:08 | |
| * bthomas too | 14:21 | |
| morphis | hey all! | 14:22 |
| morphis | DominikF and I currently working on a charm where pip ends up pulling in binaries (specifically via pynacl) into the charms venv which makes the charm architecture specific. Is their a recommendation on how to deal with this problem? In the end charms should be architecture-independent, right? | 14:23 |
| Chipaca | no, charms will be arch-dependent | 14:26 |
| Chipaca | that's fine | 14:26 |
| Chipaca | (well, not everything is in place to make them work 'right' all the time, but if your world is all amd64 it'll be fine until we get everything in place) | 14:26 |
| Chipaca | morphis: ^ | 14:27 |
| morphis | Chipaca: hm, so the store will be able to distribute different revisions depending on the architecture same as we have for snaps? | 14:36 |
| Chipaca | morphis: yup | 14:36 |
| morphis | ah ok | 14:36 |
| morphis | Chipaca: how much of this is already in place? | 14:36 |
| Chipaca | morphis: the store is multi-arch-aware but nothing else is afaik | 14:37 |
| Chipaca | morphis: for now everything is assumed to be arch: all | 14:37 |
| morphis | so we have to workaround with shipping two different venv's until that is fixed | 14:37 |
| Chipaca | morphis: you're wanting to support multiple arches? | 14:38 |
| morphis | yes, we have to support both arm64 and x86 with the same charm | 14:38 |
| Chipaca | bummer | 14:39 |
| Chipaca | but, yes | 14:39 |
| morphis | it wouldn't be too much of an issue just complicates the build process a bit | 14:39 |
| Chipaca | morphis: is this for running on juju >=1.8? | 14:40 |
| morphis | oh yeah, assume the latest juju | 14:40 |
| Chipaca | morphis: ok | 14:40 |
| Chipaca | facubatista: ^^^ please read from morphis' "hey all" down | 14:40 |
| morphis | Chipaca, facubatista: happy to sync on a call on this | 14:41 |
| DominikF | would, love to be included in that call | 14:49 |
| * Chipaca bans DominikF | 14:49 | |
| * Chipaca hides | 14:49 | |
| Chipaca | 🙂 | 14:49 |
| DominikF | 😂 | 14:51 |
| facubatista | reading | 14:51 |
| facubatista | morphis, what you could do (as a hack, until all the rest is in place and fully automatic (*)), is to `pip install your-dep` on the "install" hook, and postpone the import of that after that | 14:54 |
| Chipaca | facubatista: i think doing the multi-venv is better | 14:54 |
| Chipaca | otherwise your charm suddenly needs The Internet | 14:54 |
| Chipaca | and set up gets slower, and all the bad things we know about | 14:55 |
| morphis | yes, it needs the internet + gcc, ... | 14:55 |
| Chipaca | exactly | 14:55 |
| Chipaca | and libnacl is scary | 14:55 |
| Chipaca | deps-wise | 14:55 |
| Chipaca | (iirc) | 14:55 |
| facubatista | (*) fully automatic: in the future you'll declare what archs you need, and "charmcraft pack" will pack your charm creating with the libs installed under those archs, having N results, which you could publish in the store for each arch, and the consumer will just get what it needs | 14:55 |
| Chipaca | facubatista: does the store support arch: many for charms? | 14:56 |
| morphis | how would charmcraft deal with the cross compilations aspects? | 14:56 |
| Chipaca | multi? | 14:56 |
| Chipaca | arch: [amd64, i386] | 14:56 |
| facubatista | morphis, similar to how snapacraft does it today | 14:56 |
| facubatista | probably using multipass, if you do it in your machine | 14:56 |
| morphis | so you either offload to a remote arm machine or you run on arm | 14:56 |
| Chipaca | morphis: launchpad builders or equivalent, yes' | 14:57 |
| morphis | ok | 14:57 |
| facubatista | morphis, and eventually we would have launchpad builders | 14:57 |
| facubatista | that | 14:57 |
| Chipaca | that's in the fullness of time, which is a way aways 🙂 | 14:57 |
| morphis | hehe | 14:57 |
| morphis | ok, I think for now we will manually perform what charmcraft is doing to generate the multi venvs | 14:57 |
| Chipaca | facubatista: for now, if you have a way of doing a 'charmcraft build' on x86 and amd64, you can then bring them together | 14:58 |
| Chipaca | morphis: ^ | 14:58 |
| facubatista | Chipaca, how? | 14:58 |
| Chipaca | morphis: and if it's only for new jujus, nuke hooks/* and put the arch thing in dispatch | 14:58 |
| Chipaca | morphis: note that it's called venv, but it's not a venv, just a lib | 14:58 |
| Chipaca | should be straightforward to rename it and pivot in the dispatch (which is a shell script) | 14:59 |
| Chipaca | anyway, i'm off (more meetings) | 14:59 |
| facubatista | Chipaca, ah, got it | 14:59 |
| facubatista | morphis, do you understand what Chipaca is proposing? else I can help you | 14:59 |
| morphis | Chipaca: yes, we can easily do a uname -m check in the dispatch script and switch the venv/lib there | 14:59 |
| morphis | facubatista: yes I do, will ping you if we run into any problems | 14:59 |
| facubatista | morphis, wonderful | 14:59 |
| morphis | thanks facubatista & Chipaca ! | 15:00 |
| facubatista | :) | 15:00 |
| ionutbalutoiu | Hello everyone! | 15:04 |
| JoseMasson | Hello ionutbalutoiu! | 15:08 |
| Chipaca | ionutbalutoiu: 👋 | 15:51 |
| Chipaca | facubatista: in charms.foo.v0.bar, is v0 the API version of bar? | 16:05 |
| facubatista | Chipaca, yes | 16:06 |
| facubatista | hello ionutbalutoiu | 16:06 |
| Chipaca | facubatista: new_library.py.j2 has a syntax error unless I'm misunderstanding something | 16:07 |
| Chipaca | facubatista: is that on purpose? | 16:07 |
| Chipaca | … and you merged it, o no :) | 16:08 |
| Chipaca | facubatista: you're missing tests, obviously, because otherwise you would've caught the error | 16:09 |
| Chipaca | facubatista: see the tests for 'init', maybe? | 16:09 |
| Chipaca | or _something_ :) | 16:09 |
| facubatista | Chipaca, will add a test for it be a valid Python file | 16:24 |
| bthomas | Chipaca facubatista between 6pm and 7pm UK time I will be going out to pickup dinner. But should I have any question after that will at least one of you be around ? | 17:07 |
| Chipaca | bthomas: I'm going to pop out now, go for a run, and be back at about 19:30 | 17:10 |
| bthomas | thanks | 17:10 |
| Chipaca | bthomas: ie in 2 hours and a bit | 17:10 |
| bthomas | no problem | 17:10 |
| Chipaca | (time to get changed + 2 hour run + shower) | 17:10 |
| bthomas | nice | 17:10 |
| bthomas | Prometheus altermanager changes have quite a few merge conflicts. I am working through them now. | 17:24 |
| facubatista | bthomas, it's better to always talk in UTC-0, because of DST and everything I don't know that is 6pm uk time | 17:24 |
| bthomas | facubatista: agreed. I think I am UTC+1 zone. | 17:24 |
| facubatista | I'll be off between 19:00z and 21:30z | 17:25 |
| bthomas | I just fixed the merge conflicts for the prometheus alertmanager changes from dylan. I will review and approve so I can merge after a short tea break. I will need a second review and approval to be able to merge this pull request https://github.com/canonical/prometheus-operator/pull/5 | 17:39 |
| mup | PR prometheus-operator#5: Alertmanager support <Created by dstathis> <https://github.com/canonical/prometheus-operator/pull/5> | 17:39 |
| * bthomas goes to make some tea | 17:39 | |
| * bthomas is back | 17:54 | |
| bthomas | I am off to get some groceries and dinner. Will be back in an hour. | 18:09 |
| bthomas | I need one more approval on ^ pull request. Will merge when back. | 18:09 |
| * bthomas goes | 18:09 | |
| facubatista | reviews appreciated! https://github.com/canonical/charmcraft/pull/181 | 18:31 |
| mup | PR charmcraft#181: Support for publishing libraries <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/181> | 18:31 |
| * facubatista bbl | 18:59 | |
| * bthomas is back | 19:46 | |
| bthomas | Five guys are also under lockdown. This is depressing. :( | 19:46 |
| * Chipaca is _almost_ back | 19:55 | |
| bthomas | Chipaca: All you have to do is click OK :-) https://github.com/canonical/prometheus-operator/pull/5 | 20:11 |
| mup | PR prometheus-operator#5: Alertmanager support <Created by dstathis> <https://github.com/canonical/prometheus-operator/pull/5> | 20:11 |
| justinclark | bthomas, just approved | 20:11 |
| bthomas | Ah thanks justinclark | 20:12 |
| bthomas | wait I still see merging is blocked | 20:12 |
| bthomas | Never mind I just did the second approve. :-) | 20:13 |
| Chipaca | bthomas: no README? | 20:13 |
| Chipaca | wait, wrong project | 20:14 |
| Chipaca | bthomas: how's the alertmanager README etc coming? | 20:15 |
| bthomas | Chipaca: I will create another pull request with README for alertmanager-operator | 20:16 |
| bthomas | Cleaning commings to merge alertmanager changes to prometheus operator | 20:16 |
| Chipaca | ok,fair | 20:16 |
| Chipaca | bthomas: do you need me to review https://github.com/canonical/alertmanager-operator/pull/1 ? | 20:17 |
| mup | PR alertmanager-operator#1: MVP for alertmanager charm <Created by dstathis> <https://github.com/canonical/alertmanager-operator/pull/1> | 20:17 |
| bthomas | Chipaca: Any input you can give on alertmanager-operator PR will be helpfull. I have already reviewed. I can approve too due to paucity of time. If you want to make any suggested edits can I review and merge. I will then create another PR with readme. | 20:19 |
| bthomas | Merged changes into prometheus. Building prometheus to check nothing broke | 20:23 |
| Chipaca | bthomas: reviewed the https://github.com/canonical/alertmanager-operator/pull/1, +1 with notes | 20:27 |
| mup | PR alertmanager-operator#1: MVP for alertmanager charm <Created by dstathis> <https://github.com/canonical/alertmanager-operator/pull/1> | 20:27 |
| * Chipaca digs into his guiso de lentejas | 20:27 | |
| Chipaca | (a spanish dhal) | 20:28 |
| bthomas | Chipaca: Thank you. justinclark Chipaca One more quick fix. With this fix prometheus runs and works ok. Please see commit message explaining need for fix. https://github.com/canonical/prometheus-operator/pull/12 | 20:31 |
| mup | PR prometheus-operator#12: Fix incorrect label for stored state <Created by balbirthomas> <https://github.com/canonical/prometheus-operator/pull/12> | 20:31 |
| bthomas | Going to merge alertmanager-operator build and test now. If it works and can form relations with prometheus I will create another pull request with README for alertmanager operator | 20:32 |
| justinclark | bthomas, just reviewed | 20:39 |
| bthomas | thanks justinclark | 20:39 |
| justinclark | Need to make the same change in the tests | 20:39 |
| bthomas | just deployed alertmanager and prometheus and related them. No errors. Trying to figure out if the relation actually worked. | 20:40 |
| bthomas | justinclark: thanks will edit and push changes to test in same commit . You may need to reapprove if you do that. Alternatively if you just make and edit suggestions I can accept and it will work, without the need for reapproval. | 20:40 |
| bthomas | Chipaca: from juju debug logs I can see that when I added alertmanager and prometheus relation. The relation changed event triggered for alertmanager and there were no errors. Is this good enough ? | 20:42 |
| Chipaca | jldev: ^ i think that is what you meant? | 20:51 |
| Chipaca | unless he meant in the alertmanager logs itself | 20:51 |
| justinclark | bthomas, I'm fixing tests now and will push to that PR | 20:54 |
| bthomas | jldev: Chipaca just looking at logs. There are no errors but no information regarding alertmanager joining. | 20:55 |
| bthomas | thanks justinclark | 20:55 |
| * bthomas googles how to check alertmanager prometheus interaction | 20:56 | |
| justinclark | If it's alright with you, I'm also going to change grafana-dashsource to grafana-datasource if you don't think it'll muddy the PR too much :) | 20:56 |
| justinclark | bthomas ^ | 20:56 |
| bthomas | justinclark: I have no preference either way. Check if jldev has any preference. | 20:57 |
| bthomas | justinclark: please keep commits separate . Not great to be missing alertmanager commits with grafana commits | 20:57 |
| justinclark | Will do. That is the name we agreed on, but didn't know if I should sneak the commit into this PR or not. | 20:59 |
| bthomas | jldev: Chipaca Also I can confirm that alertmanager unit gets added as a target to the prometheus configuration file /etc/prometheus/prometheus.yml . So this may be further indication that the relation worked. | 21:00 |
| bthomas | I am not sure what else to check. | 21:00 |
| bthomas | justinclark: I am done testing alertmanager and prometheus relation for now so will start on README, if you were planning to fix tests. If not I will fix tests. Let me know. | 21:01 |
| justinclark | I will fix tests. Feel free to focus on the README | 21:02 |
| bthomas | awesome thanks | 21:02 |
| bthomas | justinclark: you are an angel :-) | 21:02 |
| justinclark | :) | 21:30 |
| bthomas | Readme is baking, will be ready soon | 21:30 |
| justinclark | It looks like one issue may have to do with the harness. When we update the app relation data rather than unit relation data, the event.unit is None in the *-relation-changed event. Is this the expected behavior? | 21:32 |
| bthomas | justinclark: I think it is. Chipaca facubatista may be better informed here. | 21:32 |
| Chipaca | yes that is expected behaviour | 21:32 |
| justinclark | Okay cool. Then the tests just need to be rewritten. | 21:33 |
| Chipaca | event.unit is None for app data changes | 21:33 |
| * facubatista is back | 21:33 | |
| * Chipaca goes for a cuppa (and some digestives why not) | 21:38 | |
| bthomas | Chipaca: when you are back https://github.com/canonical/alertmanager-operator/pull/2 | 21:43 |
| mup | PR alertmanager-operator#2: Updated readme <Created by balbirthomas> <https://github.com/canonical/alertmanager-operator/pull/2> | 21:43 |
| * Chipaca is back | 21:44 | |
| bthomas | justinclark: I am done with readme. Do you need help with tests ? | 21:44 |
| justinclark | bthomas, just finishing up. | 21:44 |
| bthomas | awesome | 21:44 |
| Chipaca | bthomas: ooh, typo | 21:44 |
| bthomas | I am going to hammer another coffin name while Chipaca rips my README to shreds :-) | 21:45 |
| * bthomas goes for a puff | 21:45 | |
| justinclark | There is definitely still some logic that doesn't make sense given the alertmanager changes. | 21:46 |
| Chipaca | bthomas: 1st suggestion, to make it easier to write markdown text with lots of links, embrace the 'reference' style using | 21:47 |
| Chipaca | ah, if you're gone, i'll make the suggestions in code | 21:48 |
| * bthomas is back | 21:53 | |
| * bthomas picks up the pieces of the README :-) | 21:53 | |
| * bthomas googles reference style in Markdown | 21:53 | |
| * bthomas reads https://www.simondcoll.com/references-markdown-zotero/ | 21:54 | |
| Chipaca | bthomas: ah, just pushed my +1 with suggestions | 21:57 |
| bthomas | Thanks Chipaca | 21:57 |
| justinclark | The alertmanager charm is setting the relation data "addrs" to be a list, and prometheus still assumes it's a dictionary in _alertmanager_relation_departed. | 22:01 |
| bthomas | justinclark: that should be in the test only. Though there were merge conflicts like that, they should have been resolved for the charm. | 22:02 |
| bthomas | I am merging readme now | 22:02 |
| justinclark | I see - the relation-departed is still in the charm when it should have been replaced with relation broken | 22:04 |
| bthomas | justinclark: My understanding was relation departed removes on particular alertmanager but relation broken clears the entire list. | 22:05 |
| justinclark | That's not how it would work in the current iteration. addrs is being stored in _stored.alertmanagers which is a list | 22:07 |
| justinclark | relation-departed is popping as if it were still a dictionary | 22:07 |
| bthomas | justinclark: you are right . That merging was not right. The correct thing to do is search for event.unit.name in the list and remove it if found. | 22:09 |
| justinclark | I see. I'll add a quick fix. | 22:10 |
| justinclark | I'm actually not sure why we need departed. | 22:13 |
| bthomas | justinclark: looks like that may not have been a merge issue. It is a syntax/semantics issue. List pop method requires an index not name. | 22:13 |
| bthomas | justinclark: Departed is when one unit goes out of the relation. When they relation itself is terminated then it is said to be broken. | 22:14 |
| bthomas | At least that is how I understand it. | 22:14 |
| justinclark | How would we know which unit to remove? | 22:16 |
| justinclark | Alertmanager is sending the k8s hostnames, but those can be shuffled around. I'm not sure we'd be able to identify which hostname should be removed just based on the relation information | 22:17 |
| bthomas | From my reading of Dylans code I understand he was saving the alertmanager hostnames names in a list. | 22:17 |
| bthomas | When an alertmanager relation departs. I think you get the unit name as part of the event | 22:17 |
| justinclark | e.g. alertmanager/2 could be tied to alertmanager-1.xxx.endpoints | 22:18 |
| justinclark | Maybe I'm overcomplicating it in my head | 22:18 |
| bthomas | hang on, I am double checking | 22:18 |
| bthomas | justinclark: If you look at alertmanager charm.py | 22:20 |
| bthomas | he is saving the alertmanager unit hostname in the application relation data | 22:20 |
| bthomas | so prometheus should be storing them in its stored state list | 22:21 |
| bthomas | Seems like there is a need to translate between unit name and host name | 22:22 |
| * bthomas digs | 22:22 | |
| Chipaca | bthomas, justinclark, i'm still awake but going to go read stuff and slowly crash; mention me if you need me and i'll pop by | 22:22 |
| justinclark | Thanks Chipaca | 22:23 |
| Chipaca | of course my internet cuts off in 40 minutes to help me sleep so after that you're on your own 🙂 | 22:23 |
| bthomas | Chipaca: we will try not to disturb you unless the sky begins to fall. Good night. | 22:23 |
| Chipaca | (bah, if the world is on fire, you can @ me on mattermost -- my phone still works) | 22:23 |
| justinclark | bthomas, I know it's late for you too. Don't feel the need to stay up. I was just a bit perplexed by the logic. | 22:24 |
| bthomas | justinclark: looks like the logic of removing alertmanager units from the prometheus unit was not completely implemented. Little wonder that pull request on prometheus repository was still in a draft stage. I actually convert it to a pull request so I could merge and test. | 22:25 |
| bthomas | justinclark: it may be faster if we pair on this. I can hang on for another hour or so without falling off my chair. Your call ? | 22:25 |
| bthomas | If you like I can get on to hangouts. | 22:26 |
| justinclark | Maybe we wait for Dylan in the morning? He may already have thoughts about this since he's been working on it. | 22:27 |
| bthomas | justinclark: Do you know when this should be done by ? I know for sure before next tuesday. Is jldev around ? | 22:28 |
| justinclark | I know he asked that Graylog be done by tomorrow. I would suspect the same is true for alertmanager/prometheus | 22:29 |
| bthomas | I am messaging him on mm now. | 22:30 |
| bthomas | waiting for response from jldev | 22:35 |
| justinclark | ack | 22:36 |
| justinclark | I have dinner plans with the wife soon. I think it might be best to wait until tomorrow. I'm sure we can have it done before standup if we pair and bring Dylan into the convo | 22:39 |
| bthomas | justinclark: OK. Looks like jldev is away and I am getting weary. | 22:40 |
| bthomas | sleepy programmers are not good programmers | 22:40 |
| justinclark | I can also get back to it after dinner if it's absolutely critical that it's done today. | 22:40 |
| justinclark | Haha have a good rest of the night bthomas. | 22:40 |
| bthomas | justinclark: your call. If jldev is around catchup with him. It all depends on what kind of a demo we are trying to do. On the prometheus repository there is still a branch for monitoring k8s that can feed in data to prometheus which can be related to grafana and you can get some pretty graphs. | 22:41 |
| bthomas | Last thing I will try and do now is rebase that monitoring k8s branch on latest master to keep it updated. | 22:42 |
| bthomas | This will help since it provides a means to feed data into prometheus for demo purposes. Since we still need to add an alerting rules and scrapping rules relation to prometheus. | 22:43 |
| * bthomas is going to EOD now | 22:44 | |
| * bthomas goes | 22:51 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!