#smooth-operator 2020-08-02 <mup> PR operator#363 opened: 0.8 test charm no pickle <Created by jameinel> <https://github.com/canonical/operator/pull/363> #smooth-operator 2020-08-03 <Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ ï½ï½ï½ï½ï½ï½ï½ï¼ * ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.7.0 || charmcraft 0.3.0 <Chipaca> brb, dog's whining about something <jam> morning Chipaca <Chipaca> jam: you should now be able to ask chanserv to change the channel topic (and other fun stuff) <jam> Chipaca, I can feel the power.... <Chipaca> jam: that heady feeling of being able to kickban people <facubatista> Â¡Muy buenos dÃ­as a todos! <Chipaca> facubatista: ð! <facubatista> hola Chipaca! <jam> Chipaca, question about Harness. While I'm adding support for auto triggering relations. There is a question for Peer relations. <jam> Currently with Harness, you have to call 'add_relation' even for peer relations that 'always exist'. <jam> I'd like for begin_with_hooks to do so automatically <jam> but should we also do so for just begin()? IMO it makes it harder to figure out when the associated hook would fire, etc. <Chipaca> jam: that seems in line with the difference between begin and begin_with_hooks <jam> Chipaca, chans-erv seems to have issues with facu :) <Chipaca> jam: the first two are me being lazy with flags (it's easier to +* and then deop than figure out the right invocation to do it in one pass) <facubatista> jam, we're setting it up <Chipaca> jam: i'm guessing the second is facu poking around :-) <jam> morning facubatista <Chipaca> jam: by 'in line' i mean, 'begin' should continue being barebones, so you can poke at things without everything else happening <jam> Chipaca, yeah, that's how I read it. SGTM <Chipaca> jam: and begin_with_hooks can be the 'what does it look like in the middle of an actual run' <Chipaca> bthomas: ð <bthomas> thanks Chipaca <Chipaca> facubatista: there's a bug with the charmcraft release you did :-/ <Chipaca> facubatista: and with the HOWTO i guess <Chipaca> facubatista: you're building locally, meaning you only build for amd64 <Chipaca> facubatista: so charmcraft 0.3 is only out for amd64, any other arch gets 0.2 <Chipaca> facubatista: 'snapcraft remote' should probably be in there :-| <Chipaca> remote-build* <facubatista> Chipaca, let me see <facubatista> Chipaca, ah, yes, there's even a FIXME in the howto: # FIXME: what about other archs <Chipaca> facubatista: 'snapcraft remote-build' :-) <Chipaca> facubatista: although right now you could just promote edge to beta <Chipaca> i've just built 0.3.0 from github master <facubatista> the remote-build is currently working <facubatista> Chipaca, let's HO? <Chipaca> facubatista: in 5? <facubatista> deal <jam> Chipaca, facubatista : for 'Harness.begin_with_initial_hooks()'. Juju doesn't guarantee the order of firing hooks if you have more than 1 relation hook (I confirmed in the code that it iterates a map, which is not a stable ordering) <jam> for *testing* it seems it would be easier to write assertions if you had a stable ordering <jam> but I don't really want code written that assumes a stable ordering <jam> Chipaca, thoughts? <jam> should Harness emit events in a stable ordering to make testing easier, or intentionally unstable to avoid code that assumes the order <facubatista> even firing in random order in the testing harness will not make that clear <facubatista> if it passes, people may assume it's ordered, even if we trigger them at random <Chipaca> jam: let them be ordered or however is easiest to implement in python for the harness, but if you have more than one relation hook issue a warning from _with_hooks? <jam> Chipaca, but it isn't wrong to have a relation to DB and a peer relation <jam> Juju just doesn't guarantee whether peer-relation-created or db-relation-created will be fired first <Chipaca> jam: the warning would just be about the order of events <jam> Chipaca, so it is easiest in the Harness to just iterate a map, which will also be 'unordered' <Chipaca> jam: in python maps aren't unordered though, since 3.6 <Chipaca> jam: ask bthomas :-) <jam> Chipaca, I wonder if that introduces faults vs the old mechanism to avoid poisoned data <bthomas> :-) yep that bit me <jam> Chipaca, django used to have a security bug where the Query parameters were put into a dict <jam> and you could reverse engineer the dict ordering to make it collide. <jam> I guess if the hash index is still random at startup the iteration order can be stable but you can't force collisions on the hash table <facubatista> Chipaca, I did all the releases, and improved the text here: https://github.com/canonical/charmcraft/pull/101 <mup> PR charmcraft#101: Release 0.3.0 <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/101> * facubatista -> lunch * facubatista is back <Chipaca> facubatista: ð <Chipaca> facubatista: can you look at https://github.com/chipaca/ops-lib-k8s/pull/2/files and tell me if the _path thing is clear and readable, or if I should add an explanatory comment, or change the approach entirely? <mup> PR chipaca/ops-lib-k8s#2: lots of small tweaks and cleanup <Created by chipaca> <https://github.com/chipaca/ops-lib-k8s/pull/2> <facubatista> will do <mup> PR operator#364 opened: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <https://github.com/canonical/operator/pull/364> <jam> facubatista, Chipaca : I'm definitely way past EOD, but ^^ is up. I'm happy to bikeshed on the name of the functiona <jam> and if we look at that test and say "no we really should give a stable order" then we can fix it <jam> but it does what I wanted. <facubatista> jam, awesome, thanks <jesseleo> Hello facubatista I'm still running into the error of adding a resource to my test harness <jesseleo> facubatista https://paste.ubuntu.com/p/MJd3cDKfxG/ <Chipaca> jesseleo: what version of ops are you using? <Chipaca> jesseleo: because the version with add_resource was added in #359 which has not been released yet <mup> PR #359: ops/testing.py: Harness.add_resource <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/359> <Chipaca> jesseleo: so unless you're runing with master, that error is expected <jesseleo> yeah I have this in my requirements git+https://github.com/canonical/operator.git@master <Chipaca> jesseleo: to answer the 'what version' question, just add "raise Exception(ops.__version__)" to the top of yor test method <Chipaca> it should give you something like 0.7.0+8.g<hex> <Chipaca> to be more precise, master is 0.7.0+6g169794c right now <Chipaca> jesseleo: what I imagine might be happening is that your test environment has a different ops version and you need to update/upgrade/refresh it <Chipaca> thus my suggestion <jesseleo> oh yes I see I did have ops installed at the system level and wasn't activating my virtual env Chipaca facubatista <jesseleo> everything looks good now <jesseleo> thanks for being so responsive <Chipaca> jesseleo: glad we got it working! * Chipaca EODs <Chipaca> ð <facubatista> jesseleo, as a general rule, I don't ever never do "sudo pip install", as at some point always confuse things * facubatista eods #smooth-operator 2020-08-04 <mup> Issue operator#286 closed: charms/test_main should not use Pickle <Created by jameinel> <Closed by jameinel> <https://github.com/canonical/operator/issues/286> <mup> PR operator#363 closed: 0.8 test charm no pickle <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/363> <Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½ ï½ï½ï½ï½ï½ï½ï½ï¼ <jam> morning Chipaca <Chipaca> jam: ð how's things? <jam> Chipaca, going pretty well. I still need your review on operator#364 <mup> PR #364: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <https://github.com/canonical/operator/pull/364> <jam> Chipaca, I'll probably miss the standup today, I have a conflicting meeting <Chipaca> ack <jam> Chipaca, how's it with you? <Chipaca> jam: needing more coffee :) * Chipaca has more coffee now <Chipaca> jam: instead of diving into preconditions, i've been tinkering with ops-lib-k8s <Chipaca> still haven't touched the tests though <mup> Issue operator#237 closed: Feature request: Harness helper function/flag to run initial hooks as juju would execute? <enhancement> <Created by Vultaire> <Closed by jameinel> <https://github.com/canonical/operator/issues/237> <mup> PR operator#364 closed: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/364> <jam> Chipaca, ah nice. I don't think I gave much feedback on that one, I should <Chipaca> jam: latest pr sets things up for them to work with opslib because design was wanting a real-world example of what a non-interface component looked like <gnuoy> Chipaca, I'm in the process of updating charmcraft issue 104. Would I be right in saying that for charms running in Juju <2.8 the operator framework needs to create the hook symlinks when the install hook runs ? <mup> Issue #104: Symlink for `hooks/upgrade-charm` is not created when missing <Created by evhan> <Closed by jameinel> <https://github.com/canonical/operator/issues/104> * gnuoy assumes it should and updates the bug <Chipaca> gnuoy: yes <gnuoy> kk, thanks <Chipaca> gnuoy: bah, whatever hook runs first <gnuoy> yep, understood <Chipaca> in <2.8 on k8s that was 'start', for ex <Chipaca> and it couldbe upgrade-charm? i think <Chipaca> iffen you're upgrading :) <gnuoy> so I think the bug is correct, if you use charmcraft then a legacy deployment is never detected and the symlinks never created. <gnuoy> I assumed it was deliberate hence the min-version thing. I'll update the title. <Chipaca> gnuoy: what's a 'legacy deployment'? <gnuoy> Chipaca, I'm stealing the phrase from the ops framework. I believe it to mean a non-dispatch aware version of Juju <gnuoy> https://github.com/canonical/operator/blob/master/ops/main.py#L173 <Chipaca> ah :) <Chipaca> gnuoy: this is with juju <2.8? <gnuoy> right <Chipaca> hmmâ¢ <gnuoy> I've put more detail in https://github.com/canonical/charmcraft/issues/104 <Chipaca> thanks <Chipaca> gnuoy: this is code i wrote, so it cannot _possibly_ have bugs <gnuoy> haha, must be feature. <Chipaca> gnuoy: https://youtu.be/qhXjcZdk5QQ?t=52 <gnuoy> exactly! <Chipaca> that's quite a pickle <facubatista> Â¡Muy buenos dÃ­as a todos! <Chipaca> facubatista: (null) <Chipaca> er * Chipaca checks his config <facubatista> je <Chipaca> facubatista: ðâ <Chipaca> much better <facubatista> https://imgflip.com/i/4adkoh <facubatista> :) <Chipaca> facubatista: https://www.bbc.com/future/article/20160325-the-names-that-break-computer-systems <bthomas> This one surely breaks a lot https://xkcd.com/327/ :-) <facubatista> Chipaca, my mother's last name is MuÃ±iz, and I remember the real life in the pre-unicode era, everything was Mu#iz for her <facubatista> Chipaca, jam, in charmcraft#104, shouldn't the OF create the rest of the hooks? <mup> Issue charmcraft#104: Hook symlinks not created for deployments to environments running Juju < 2.8 <Created by gnuoy> <https://github.com/canonical/charmcraft/issues/104> <Chipaca> facubatista: remember manuel de la peXa? <Chipaca> facubatista: yes the problem is that charmcraft is setting things up in such a way that ops thinks it's in post-2.7 <jam> Chipaca, facubatista : the code is still there: https://github.com/canonical/operator/blob/master/ops/main.py#L175 <jam> and it is even called: https://github.com/canonical/operator/blob/master/ops/main.py#L334 <Chipaca> jam: but the hooks are symlinks to dispatch <Chipaca> jam: and dispatch sets JUJU_DISPATCH_PATH <Chipaca> jam: and dispatch exists <Chipaca> and that's what ops uses to choose legacy or dispatch <facubatista> Chipaca, in current charmcraft, after zipping, remember hooks are not symlinks (but will be in future charmcrafts) <jam> Chipaca, but why is that a problem? <Chipaca> no difference, it's the fact that it sets JUJU_DISPATCH_PATH and exists that does it <gnuoy> self.is_dispatch_aware gets incorrectly set to True which causes an early exit from ensure_event_links <Chipaca> jam: because then no symlinks are created <jam> Chipaca, ah, dispatch is setting JUJU_DISPATCH_PATH, why would it do that? <jam> bad script no biscuit <jam> :) <Chipaca> jam: other bugs :) <Chipaca> need to dig <jam> Chipaca, ok. so it is a charmcraft bug (arguably), at the least, ops and charmcraft don't agree on signaling <Chipaca> yeup <facubatista> Chipaca, https://github.com/canonical/charmcraft/commit/a0bdc74c5b2b63eff9248ad8c192a2c9f8a0f5e1 <Chipaca> yup <jam> Chipaca, thinking about multipass and snapcraft/charmcraft. I find it interesting with snaps that it is so dangerous to depend on a executable in $PATH that the preferred route is to expose a service for anyone to poke via the network <jam> Is it because it has been easier to grant Network as a policy than granting "access to executable Foo" as a policy? <Chipaca> jam: it isn't about it being dangerous, it's a limitation of the security layers <Chipaca> jam: (there's also the policy issue of letting a confined thing execute an unconfined thing meaning you've just unconfined the confined) <jam> Chipaca, so find a way to execute the unconfined thing via an HTTP post instead of a CLI exec <Chipaca> jam: the thing is already exposing a grpc api over a socket to itself <jam> Chipaca, I just mean, a CLI is an API just like an HTTP API is.snapcraft is able to confine things to not find executable, but doesn't have fine grained control to say what services you could talk to <jam> but it means people break their confinement via HTTP requests instead of via CLI requests <Chipaca> gnuoy: we're going to be 5 minutes late <gnuoy> sure np <Chipaca> jam, facubatista, wrt charmcraft#104, not super clear to me what we can do <mup> Issue charmcraft#104: Hook symlinks not created for deployments to environments running Juju < 2.8 <Created by gnuoy> <https://github.com/canonical/charmcraft/issues/104> <facubatista> Chipaca, create all hooks symlinks everytime? <Chipaca> that's less than ideal for a couple of reasons <Chipaca> the issue is that calling charm.py drops the name of the hook <Chipaca> that is, we lose sys.argv[0] <jam> Chipaca, not set JUJU_DISPATCH_PATH in dispatch <jam> ah right <Chipaca> so it seems to me <jam> is there a magic in 'exec' ? <Chipaca> that what we should do is set our _own_ variable <Chipaca> with blackjack and â¦ <Chipaca> â¦ built-in help? <Chipaca> jam: i think bash exec does, sh exec does not <Chipaca> but i'd have to double-check <jam> Chipaca, 'exec --help' says 'exec -a NAME' <Chipaca> right, that's bash <facubatista> Chipaca, the builtin help is a good idea, there's a recurrent question when dealing with this new "dispatch thing" that is "so I'm in here with debug-hook, how I call my hook manually?" <jam> $ /bin/dash -c 'exec -a foo echo hello' <Chipaca> jam: ooh, undocumented? <jam> /bin/dash: 1: exec -a: not found <Chipaca> jam: b'doh <jam> nope, just copy&paste didn't work because IRC interpreted the opening '/' :) <jam> Chipaca, I'm not opposed to #!/bin/bash in dispatch <Chipaca> or we could make it a python script ]=) <facubatista> Chipaca, +1 <Chipaca> but bash sounds alright for a last-minute thing <jam> facubatista, Chipaca we could. I know that breaks on RedHat because python3 isn't in the default instal <Chipaca> drop JUJU_DISPATCH_PATH, and use -a <Chipaca> or <Chipaca> OR <Chipaca> use symlinks <Chipaca> :) <facubatista> Chipaca, symlinks how? <Chipaca> this all goes away if we stop flattening symlinks <Chipaca> doesn't it? <Chipaca> (maybe it doesn't) <jam> Chipaca, if you change hooks/install => ../src/charm.py it would go away, but you can't do that because we want to put the "use the venv" somewhere <Chipaca> right * Chipaca sets the venv on fire and sits back to watch <Chipaca> I'll write the "use bash w/exec -a" as the quickest way out <Chipaca> â¦ that doesnt work <Chipaca> python's fiddling with argv <facubatista> Chipaca, you that know Unix (?), is it ok to have a space rigth after the shebang in "#! /usr/bin/env python3" ? <Chipaca> facubatista: yep (and they've been documented as required at some point, although weren't) <facubatista> thanks <Chipaca> facubatista: also, env -S exists (as of when? no idea) <ballot> Hello ! <facubatista> hello ballot! <ballot> I'm looking for a way to retrieve the pod_spec using ops.testing. I see that self.harness.get_pod_spec is defined in 0.8 (https://github.com/canonical/operator/blame/master/ops/testing.py#L423). I guess I don't have a way to test this easily with 0.7 right ? :) <ballot> well, I don't really have a problem trying to use 0.8 for my charm tbh anyway, i'll give it a try <Chipaca> ballot: and 0.8 should be out this week :) <Chipaca> ballot: pre that, there wasn't an easy way of doing that, no <ballot> Chipaca: alright, just wanted to be sure I was not missing something. I have an issue with charmcraft build, I'll bring that to the right channel, thanks :) <Chipaca> ballot: 'charmcraft build' issues is also here :) <ballot> Ah ! <Chipaca> ballot: unless you're building something so secret you can't talk about it in public :-D <ballot> Well, I put "-e git+https://github.com/canonical/operator.git@master#egg=ops" in my requirement.txt and confirmed it works with "pip install -r requirements.txt" <ballot> When I do charmcraft build, in the full log I have <ballot> https://pastebin.ubuntu.com/p/jmyJh58WCT/ <ballot> (sorry bad habit of using the internal one) <Chipaca> whoa <facubatista> Chipaca, jam, where I can read about the order of first events sent by Juju? <ballot> It's fine, I can workaround it easily by manually pulling the wheel in the right location, but probably bug worthy. Just wanted to be sure it was not something obvious on my side <Chipaca> ballot: does that still happen if your requirements.txt has 'git+https://github.com/canonical/operator.git' instead of your more funky line? <ballot> Chipaca: let me try <jam> facubatista, https://discourse.juju.is/t/event-cycle/1117 <facubatista> jam, thanks <jam> https://discourse.juju.is/t/charm-hooks/1040 and https://discourse.juju.is/t/the-hook-environment-hook-tools-and-how-hooks-are-run/1047 are also relevant <ballot> Chipaca: 33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab ERROR: Could not detect requirement name for 'git+https://github.com/canonical/operator.git', please specify one with #egg=your_package_name <Chipaca> super strange, i've got that here and it works <ballot> Chipaca: also tried to remove the @master, but then, read-only filesystem again <Chipaca> ballot: this is with charmcraft 0.3 from the snap, yes? <ballot> Chipaca: yes <Chipaca> facubatista: ^ any ideas? <ballot> Chipaca: I think I know what happens, I just need to find in pip where is the default location for pulling the dependencies <ballot> Chipaca: ah, that's the "-e" <ballot> Chipaca: it works without the "-e" <Chipaca> augh <ballot> yeah right, makes sense <Chipaca> i totally ignored that :-) * Chipaca needs a better parser in his brain <facubatista> the -e tries to install it in your home or something? <Chipaca> it's the "develop" thing <facubatista> Chipaca, I though it was why you suggested to use a simpler line <ballot> It's to point toward the module you're working on so you don't have to update your env <ballot> facubatista: yes, I missread, and did remove the "-e" <Chipaca> yep, like 'python setup.py develop' <Chipaca> ballot: but if you did that for a charm, you'd end up with a .pth and not the actual code you need inside your charm, right? <ballot> anyway, I don't think using -e makes sense for a charm anyway <ballot> Chipaca: yeah, it was merely a bad habit on my side <Chipaca> sounds like an argument against charmcraft supporting 'full' requirement.txt <Chipaca> :-/ * Chipaca oh noes <ballot> sorry :/ <Chipaca> facubatista: maybe we should detect and fail early or with a clearer message <ballot> Chipaca: does charmcraft support constraints files ? <Chipaca> ballot: no <facubatista> Chipaca, let's use fades, that doesn't support "-e" :p <Chipaca> ballot: but not because of philosophical reasons, just nobody's asked us :-) <ballot> Chipaca: well, "priorities" :) <ballot> Chipaca: I'm not sure it's worth spending time on it right now. The only use case I see is if the application code and charm are hosted on the same repository, then to limit in one place some module version for the app, the charm and the tests, it's better to use constraints rather than repeating the limitation in all requirements.txt <Chipaca> k <Chipaca> i need to step out (physio! here's hoping for a better back) <ballot> Chipaca: np, thanks !: <ballot> My tests are running now :) <ballot> (well failing of course, as one would expect, but for good reasons now) <Chipaca> :-D * Chipaca disappears into the sunset * facubatista eods #smooth-operator 2020-08-05 <ballot> Hello ! I've pushed the last modifications of the charm and all the tests in https://code.launchpad.net/~ballot/charm-k8s-mm-pd-bot/+git/charm-k8s-mm-pd-bot/+merge/388497 if you want to review part of it. Since it's the initial push with a working charm, this is quite a huge one, sorry for that <Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ ï½ï½ï½ï½ï½ï½ï½ï¼ <bthomas> Morning <jam> morning Chipaca <bthomas> Hmmm got the following error on snap installing juju "Run hook connect-plug-peers of snap "juju" (run hook "connect-plug-peers": error: cannot communicate with server: timeout exceeded while waiting for response)" <bthomas> and looks like juju did not install as shown by snap list <bthomas> worked second time. Odd. <jam> bthomas, that sounds like something to share in #juju/as a Juju bug. <jam> I know there are some snap hooks that let Juju know about things like microk8s <bthomas> jam : got it. worked second time so I am not sure if I can reproduce it. If I can will report it. <jam> bthomas, it definitely sounds like a race condition that the script should be handling. <Chipaca> jam, bthomas, that looks like a snapd bug to me <jam> Chipaca, depends what "server" it is trying to talk to :) <Chipaca> unless juju has a concept of 'plugs' <Chipaca> that's a snappy thing :) <jam> Chipaca, so it is certainly part of snap installing, I thought it might be the script failing to talk to a Juju server during the plug hook execution. <jam> But if it is *snap* failing to talk to the server to ask it to run the hook, that would certainly be a snap issue <Chipaca> bthomas: you could enable debug logs in snapd so you have useful logs for the next time it happens for people to debug it, but it is rather chatty <bthomas> Chipaca: will do <Chipaca> bthomas: https://forum.snapcraft.io/t/4668/2?u=chipaca <Chipaca> easiest way to enable debug :) <bthomas> thanks * Chipaca has that bookmarked * Chipaca always forgets he has it bookmarked <Chipaca> anyway, i need to take a break <bthomas> I create notes of such tasty tips in org-mode <Chipaca> show-off <Chipaca> :Ã¾ <bthomas> :-) <Chipaca> just asked the following in #juju by mistake, so if you're in both, sorry for the noise :) <Chipaca> jam: I think the only sane way out of this dispatch mess we've dug ourselves into is to look at the juju version, like what we did with has_app_data <Chipaca> jam: which means main needs to parse the juju version, and so does model (for app data) <Chipaca> jam: DRY would mean doing that once in main and then passing it in to model <Chipaca> is that worth it <Chipaca> what I'm going to do is do it in both places for now, and we can think about refactoring once that's out <jam> Chipaca, in a meeting, will respond soon, but first cut sounds ok <jam> Chipaca, can we join a hangout to discuss the options? <jam> PYTHONEXECUTABLE <jam> If this environment variable is set, sys.argv[0] will be set to its value instead of the value got through the C runtime. <jam> Only works on Mac OS X. <jam> *so close* <jam> Chipaca, I'm stepping away for a bit. I think parsing it once and having it available as an attribute of model (probably private to start), would be nice, I do prefer not having Model interact with env vars <facubatista> Â¡Muy buenos dÃ­as a todos! <bthomas> facubatista: Buenos dias (but that is as far as my spanish goes :-) <facubatista> bthomas, hello! :) <Chipaca> facubatista: q'acÃ© caez'n! <facubatista> :) hola Chipaca <Chipaca> jam: d'oh, i didn't see your earlier request-for-hangout <Chipaca> because, coding <jam> morning facubatista <jam> Hi Chipaca I'm back if you'd like to chat <facubatista> hola jam <jam> its almost bug revue time anyway <Chipaca> jam: I'm 5 minutes from a pushable branch <jam> Chipaca, then finish it! * Chipaca looks up the konami code for emacs <jam> u u d d l r l r a b b a <Chipaca> not one M-x? <Chipaca> also, is ABBA part of a konami conspiracy <Chipaca> oh dang the symlinks won't work will they <Chipaca> jam: can you get a 2.7 juju, and a charmcraft-built charm, remove the 'dispatch' binary from the charm by hand, and push that to the 2.7 juju? <Chipaca> jam: and then fire config-changed or something not in the handful of initial events <jam> Chipaca, you mean 'snap install juju --channel 2.7/stable; juju bootstrap lxd lxd' ? <jam> yes I can, but you probably can, too :) <Chipaca> you make it sound so easy <Chipaca> jam: sorry, yes, i'll do it <Chipaca> jam: i forgot 2.7 isn't that old that i need you to build it for me :) <jam> Chipaca, I'm happy to help if it accelerates you, but give a man a fish and all that * Chipaca likes fish <Chipaca> oh dang i haven't had lunch <jam> is that a form of nerd sniping? <Chipaca> https://github.com/canonical/operator/compare/master...chipaca:argv0-woes?expand=1 <Chipaca> i haven't proposed it because AUGH <Chipaca> and i'm going to have lunch <jam> Best part: AUGH THE SYMLINKS WON'T WORK NEWS AT 11 <facubatista> Chipaca, meeting? <mup> Issue operator#362 opened: Create symlinks when Juju version doesn't support dispatch <Created by gnuoy> <https://github.com/canonical/operator/issues/362> <mup> Issue operator#365 opened: Make JujuVersion.from_environ return 0,0,0 if JUJU_VERSION isn't set <Created by chipaca> <https://github.com/canonical/operator/issues/365> <mup> Issue operator#358 closed: New configs added to a charm not available <Created by davigar15> <Closed by chipaca> <https://github.com/canonical/operator/issues/358> <facubatista> Chipaca, meeting? <Chipaca> whoops <facubatista> Chipaca, jam, https://obby.co.uk/schools/venturistable <facubatista> Chipaca, it was pizza: https://blog.taniquetil.com.ar/posts/0517/ <facubatista> Chipaca, indeed you were there https://www.dropbox.com/sh/0pw0yix8qmc3qgy/AADJFfwTzVo28bNt7qexvKjxa?dl=0&preview=IMG17916.JPG <facubatista> I remember there was an issue with the train, we had to walk quite a lot <Chipaca> man, we really need spread-like integration tests <Chipaca> facubatista: charmcraft-built charms on 2.7 don't work at all <Chipaca> bah, it's gnuoy's bug <Chipaca> hmm <mup> PR operator#366 opened: version-check to determine dispatch support <Created by chipaca> <https://github.com/canonical/operator/pull/366> * facubatista eods #smooth-operator 2020-08-06 <jam> morning all <gnuoy> Hi, I'd like charmcraft to include the charms readme in the built charm, which it doesn't seem to do at the moment. Is there anyway to do that ? <gnuoy> hmm, looking at the code that looks like a 'no' <jam> gnuoy, currently no, we are working on a patch that will change charmcraft to use '.jujuignore' to figure out what it will omit, and include everything else (matching the way 'juju deploy' does it today) <jam> gnuoy, so in the next release, that would change, but currently there isn't a way to tweak it <gnuoy> jam, ack, thanks. I raised https://github.com/canonical/charmcraft/issues/108 to track it <jam> morning Chipaca <Chipaca> jam: ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ ï½ï½ï½ï½ï½ï½ï½ï¼ <Chipaca> :) <jam> Chipaca, that's a very good morning <Chipaca> jam: you have been blessed by the gods of $RANDOM <jam> Chipaca, ahh <bthomas> morning all * bthomas wondering how Chipaca types all those unicode fonts <jam> bthomas, I'm sure its a script, but I like to think he has a second keyboard <bthomas> or a spare set of fingers <Chipaca> jam: indeed, https://github.com/chipaca/bin/blob/master/beuno <Chipaca> if it's the unicode side of that that you found interesting though, snap install unifonter <bthomas> ah <jam> Chipaca, 2-512, thats... aggressive <Chipaca> nah, $RANDOM only goes to 32767 <Chipaca> so it's to 63 <jam> Chipaca, just checking that you're aware of the meeting in 30min. It showed up on my calendar earlier today. <Chipaca> jam: ack <facubatista> Â¡Muy buenos dÃ­as a todos! <jam> hi facubatista <jam> I think one of the release changes are that test suites should probably start calling Harness.cleanup() <facubatista> hola jam <Chipaca> jam: standup? <Chipaca> bthomas: fixed unifonter, thanks for the report <bthomas> Awesome Chipaca, will redownload and flood this place with unicode goodness <jam> Chipaca, reviewde <Chipaca> bthomas: actually, that was a mistake. Now _really_ fixed :) <bthomas> :-) lucky I haven't checked it yet. <Chipaca> jam: thanks! <jam> Chipaca, I sent you some thoughts on how to have the docs for 0.8 changes. <jam> The examples are a bit weak, so if you feel it is better to omit them, feel free <Chipaca> weak > none, most of the time <Chipaca> bah; weak > none for strong values of weak <jam> :) <facubatista> Chipaca, meeting? <Chipaca> facubatista: nah <facubatista> :) * Chipaca pats ChanServ <mup> Issue operator#362 closed: Create symlinks when Juju version doesn't support dispatch <Created by gnuoy> <Closed by chipaca> <https://github.com/canonical/operator/issues/362> <mup> PR operator#366 closed: version-check to determine dispatch support <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/366> <mup> Issue operator#367 opened: Provide valid "series" in default template charm <Created by balbirthomas> <https://github.com/canonical/operator/issues/367> * ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.7.0 || charmcraft 0.3.1 <facubatista> charmcraft 0.3.1 released! <facubatista> jam, Chipaca, https://github.com/canonical/charmcraft/pull/110 <mup> PR charmcraft#110: Release 0.3.1, and improvements in the procedure <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/110> <mup> Issue operator#111 closed: Provide valid "series" in default template charm <Created by balbirthomas> <https://github.com/canonical/operator/issues/111> * ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.8.0 || charmcraft 0.3.1 <Chipaca> 0.8.0 is out :-) * facubatista eods <alejdg> Hey folks, is there a way to block relation-broken or relation-departed when a pod/unit is replaced? #smooth-operator 2020-08-07 <Chipaca> facubatista: ð <bthomas> ðºððð ððððððð¡ðð ððððððð <bthomas> <bthomas> <Chipaca> :-) <Chipaca> bthomas: ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ ï½ï½ï½ï½ï½ï½ï½ï¼ <bthomas> :-) <bthomas> Chipaca: I messed up and need some help. I created a ticket in the wrong repo <Chipaca> bthomas: ok :-) tell me more <bthomas> If it can be deleted I can recreate it. https://github.com/canonical/operator/issues/367 <bthomas> Alternatively if you have rights to do so you may choose to move it. <bthomas> This might be a good simple issue for me to fix when I finish with prometheus and grafana <bthomas> I have moved both prometheus and grafana to charmcraft 8 and removed gitmodules. The charms have been built I just need to learn how to test it and deepen my knowlege of charms too. <Chipaca> bthomas: ah, i transferred that one yesterday <bthomas> Thanks you. <bthomas> I have pushed my changes to my github branches at https://github.com/balbirthomas <Chipaca> bthomas: click that url <bthomas> :-) <Facu> Â¡Muy buenos dÃ­as a todos! <bthomas> Buenos dias <Chipaca> Facu: ð ! <Chipaca> also ðâ <Chipaca> Facu: today i found we have bugs in the tab completion thing, which i need to think about how to address <Chipaca> it only completes the first option <Chipaca> i need to look at what alternatives i have, because we can't be the first people doing this :) <Chipaca> subcommands with options i mean <Facu> hola bthomas, Chipaca <bthomas> At your service Facu <Facu> Chipaca, yeap, it's not that weird <bthomas> FWIW the new operator framework and charmcraft is/was very easy to use. I was able to pip install ops, actually even built a deb package (python3-operator) and tried it that way. It all worked. Even ran tests natively and that worked too. <bthomas> Facu: I also created source deb package for logassert <Facu> nice <Facu> the .deb should not be necessary <Facu> nice! <Facu> I just released logassert to be used as a pytest fixture, I plan to bring it to charmcraft <Chipaca> Facu: oa <Chipaca> Facu: oa? <Facu> Chipaca, o/ <Chipaca> Facu: your network is super happy <Facu> not <Facu> pff, bytes, who need them? <facundobatista> Chipaca, bthomas, standup? <bthomas> i was just there <bthomas> will login again <alejdg> Hi everyone, is there a way to block relation-broken or relation-departed when a pod/unit is replaced? * Facu is back <Chipaca> facubatista: you there? <facubatista> Chipaca, yes <Chipaca> facubatista: https://paste.ubuntu.com/p/YFWqJDPjsd/ <Chipaca> facubatista: eh, sillyly, s/update_info/instances/ to actually see something <Chipaca> or maybe even 'for i in x.instances: print(i.name, i.status)' <Chipaca> no, not status, instance_status <Chipaca> Â¯\_(ã)_/Â¯ <facubatista> Chipaca, ~/canonical/multipass/src/rpc/ ? <Chipaca> facubatista: git clone https://github.com/canonical/multipass <Chipaca> don't you have all git repositories ever in ~ ? <facubatista> ln -s https://github.com/ ~ <Chipaca> facubatista: 'cp -al' ftw <facubatista> Chipaca, the last part of line 5 in the pastebin is weird <facubatista> let's HO 5'? <Chipaca> hah, didn't notice <Chipaca> indeed that's wrong <Chipaca> sure, let me get my headset <facubatista> Chipaca, 1-1 <Chipaca> facubatista: 0 * Facu eods <Facu> and eows <Facu> will be back on Monday! <crodriguez_> is there something hidden in the framework that tells that only the leader can execute config_changed hook? <Chipaca> crodriguez_: nope * Chipaca isn't here #smooth-operator 2020-08-10 <ballot> Hello folks. I'm back after few days off, I'll work on a CI job today. If you have the time to quickly glanced at https://code.launchpad.net/~ballot/charm-k8s-mm-pd-bot/+git/charm-k8s-mm-pd-bot/+merge/388497 . Feel free to ping me if you want to make it a peer review or something to go over it quicker <Chipaca> ð <bthomas> ðð¸ð¸ð­ ðð¸ð»ð·ð²ð·ð° ððµðµ <bthomas> <bthomas> Chipaca: I am reading thourgh https://ops.readthedocs.io/en/latest/ . Is it ok if I make a list of all my questions and discuss with you and jam (when he is back), instead of asking them one by one on this channel. Alternatively I can create a mock pull request with questions, and notes within docs were they were not clear to me. <Chipaca> bthomas: actually the latter sounds the most appealing to me <bthomas> Ok will do <mup> PR operator#368 opened: Clarify ops.testing.Harness.update_config usage <Created by darkalia> <https://github.com/canonical/operator/pull/368> <facubatista> Â¡Muy buenos dÃ­as a todos! <Chipaca> facubatista: heyy <facubatista> hola Chipaca <Chipaca> I have an awesome idea <Chipaca> starts with L and rhymes with "hunch" * Chipaca hunts for food <Chipaca> Facu: fun network day again? <facundo__> Chipaca, :( <mup> PR operator#369 opened: use yaml instead of json for pod-spec-set call <Created by chipaca> <https://github.com/canonical/operator/pull/369> <ballot> Chipaca: thanks for the review. I've answered the comments and will fix what is needed <Chipaca> ballot: thank you! <Chipaca> ballot: i just pushed a pr to fix #293 but it needs IRL testing <mup> Issue #293: passing k8s_resources to pod.set_spec does not work <juju-workaround> <Created by jetpackdanger> <https://github.com/canonical/operator/issues/293> <ballot> Chipaca: if pjdc doesn't have the time to do it tonight I'll test it tomorrow if you wish <Chipaca> ballot: i'd appreciate that, thank you <bthomas> Chipaca: Work in progress (don't review) - will discuss in stand up : https://github.com/balbirthomas/operator/tree/improve-docs <Chipaca> bthomas: ack <Chipaca> heading in to the standup now <Chipaca> WOOO 10 minute standup for the win * Facu -> lunch * Facu is back <facubatista> for sure I have network micro-cuts, but I wonder why this is so affected by those <facubatista> all the rest are resilient to the microcuts, mattermost, even videocalls <facubatista> is it IRC? is it hexchat? is it freenode servers? <Chipaca> Facu: i bet snapd isn't particularly happy with the microcuts either <Chipaca> (try 'snap download 0ad' for example) <Facu> it all depends on the timeout, right? <Chipaca> on how stateful the connection is for the app, really <Chipaca> videocalls will be doing stuff with multiple connections, sending (and receiving?) more than they need to be able to patch over those things afaik <Chipaca> or at least it used to be that way :) <facubatista> theorically they worked remotely on the router, let's see if my networking improves <facubatista> it works it improved! * facubatista does a little dance * facubatista eods <mup> PR operator#370 opened: Update README.md <Created by alejdg> <https://github.com/canonical/operator/pull/370> #smooth-operator 2020-08-11 <jam> morning all * Chipaca struggles to find his voice * bthomas recommends some ginger tea <mup> PR operator#369 closed: use yaml instead of json for pod-spec-set call <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/pull/369> <Chipaca> oops <mup> PR operator#369 opened: use yaml instead of json for pod-spec-set call <Created by chipaca> <https://github.com/canonical/operator/pull/369> <facundo__> Â¡Muy buenos dÃ­as a todos! <bthomas> ðð¬ð¬ð¡ ðð¬ð¯ð«ð¦ð«ð¤ <bthomas> <facubatista> hola bthomas :) <bthomas> :) <mup> PR operator#370 closed: Update README.md <Created by alejdg> <Merged by chipaca> <https://github.com/canonical/operator/pull/370> <Chipaca> ballot: have you been able to set aside a bit of time for testing the fix to #293? <mup> Issue #293: passing k8s_resources to pod.set_spec does not work <juju-workaround> <Created by jetpackdanger> <https://github.com/canonical/operator/issues/293> <Chipaca> heh, i just realised why you said "if pjdc doesn't have the time" <ballot> Chipaca: hello ! Not yet, was planning to do this afternoon. Since I need to compile juju and I have only go 1.12 setup on my laptop, I might have to do some tweak. The fix is committed but not released so I guess I need that to test fully the code <Chipaca> ballot: why comile juju? <Chipaca> ohh.... no i meant just the fix on operator side, ie #369 <mup> PR #369: use yaml instead of json for pod-spec-set call <Created by chipaca> <https://github.com/canonical/operator/pull/369> <Chipaca> because after noticing the fix on juju side, i realised we'd still be broken on older jujus so we really should work around it ourselves as well <ballot> Chipaca: aaaah, ok, much easier then :) <ballot> I thought I needed the fix on both sides <mup> PR operator#368 closed: Clarify ops.testing.Harness.update_config usage <Created by darkalia> <Merged by chipaca> <https://github.com/canonical/operator/pull/368> <Chipaca> ballot: both fixes fix the issue independently :) <Chipaca> off to lunch, bbl <Chipaca> facubatista: #113 could use a re-review <mup> Issue #113: Automatically transform config into pod spec <Created by knkski> <Closed by niemeyer> <https://github.com/canonical/operator/issues/113> <Chipaca> er <Chipaca> charmcraft#113 <mup> PR charmcraft#113: init: include series in metadata.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/113> <Chipaca> narindergupta: ð <narindergupta> Chipaca, hey I am starting work on writing a new k8s charm from scratch for Cassandra on k8s just need to know how to start with the k8s component in framework? <Chipaca> narindergupta: so I pulled mark's work into https://github.com/chipaca/ops-lib-k8s <Chipaca> narindergupta: the way you use it, add that to your requirements.txt, and then 'k8s = ops.lib.use("k8s", 0, "djennings@example.org")' <Chipaca> narindergupta: the "that" is "git+https://github.com/chipaca/ops-lib-k8s.git", but it'll be in pip as soon as it's "done" (at which point the API will bump to 1) <Chipaca> narindergupta: am i making sense? <narindergupta> Chipaca, so start with charm craft init then make the change <Chipaca> yep! <narindergupta> Chipaca, ok I think I can see that <narindergupta> ops_lib_k8s-0.0.dev0+unknown.dist-info/ and ops-0.8.0.dist-info/ in c=venv <narindergupta> After charm build <Chipaca> 'charmcraft build' i hope :') <facubatista> narindergupta, you should not use the 'charm' tool <narindergupta> facubatista, I am using charmcraft <facubatista> great <facubatista> narindergupta, what is "c=venv"? <narindergupta> What I meant is in venv directory <narindergupta> Chipaca, yes I am able to start the work now and still has to go through the pod status to make sure I set the status in charm application as well. Do we still explicitly set the status? <Chipaca> narindergupta: sorry i didn't follow that <narindergupta> Chipaca, in my earlier charm I explicitly set the status of the application using activestatus call based on the pods status. Are we following the same as well? <narindergupta> Like _on_start(self) <narindergupta> if (self.model.pod.is_leader()): <narindergupta> self.model.app.status = ActiveStatus('ready') <narindergupta> Basically I wanted to set the application status as pod status if it is leader <facubatista> narindergupta, I'm lost if you attempted to do that and didn't work, if it worked but you're not sure if it's the best way of doing it <Chipaca> narindergupta: that is something the charm would do, yes <Chipaca> narindergupta: I'm not sure if that's your question though <narindergupta> Chipaca, yes that answers it and currently seeing to pass app data to k8s pod <narindergupta> Will let you know if come across any issues <Chipaca> narindergupta: also note you can write self.app.status (it's the same, just shorter) <narindergupta> Chipaca, gotchu you that is helpful <Chipaca> narindergupta: and AFAIK it's not pod.is_lader but unit.is_leader :) <Chipaca> so you can write self.unit.is_leader <narindergupta> Chipaca, thank you <Chipaca> ok, i'm out of here <Chipaca> ttfn! <drewn3ss> qq, I'm moving from using submodule to pull mod/operator for the ops module to using charmcraft to build my charm. What should be done with the dead symlink from $CHARM_ROOT/lib/ops that prior pointed to ../mod/operator/ops? charmcraft dies on looking for where this symlinks to. https://pastebin.ubuntu.com/p/GKmQy44jTm/ <drewn3ss> is there a specific path I should look for when doing import ops? <drewn3ss> or is it just available in my built venv? <drewn3ss> and I shouldn't worry about pathing <drewn3ss> ok, I did a build of my charm. the venv directory didn't get created....I see that requirements.txt at the top level is actually equivalent of wheelhouse for reactive. <drewn3ss> that seems really weird, but I'll roll with it <drewn3ss> I think long term it'll make more sense for people joinnig into charming, so I'm okay with the rename <drewn3ss> answer: use requirements.txt to get the modules you want installed from pip into the charm's venv. <drewn3ss> and remove symlinks and calls to lib paths for anything that was submoduled. <drewn3ss> because the import will work because it's part of the venv <narindergupta> Chipaca do you know why am I getting this error ERROR cannot repackage charm: symlink "config.yaml" is absolute: "/home/ubuntu/narinder/charm-k8s-cassandra/config.yaml" <narindergupta> I am trying to deploy the charm but getting this error <drewn3ss> how do I make charmcraft build include my CHARM_ROOT/files directory? <drewn3ss> or /templates, or any other path for that matter <drewn3ss> seems it pulls in /lib and /src and several .yaml/version files <drewn3ss> I'd expected it to pull everything not in .jujuignore <drewn3ss> facubatista: ^ <facubatista> drewn3ss, it will do that, I'm currently working on it: https://github.com/canonical/charmcraft/issues/39 <facubatista> narindergupta, how are you deploying the charm? <drewn3ss> I see https://github.com/canonical/charmcraft/blob/master/charmcraft/commands/build.py#L123 if your entrypoint dir for build is same as your whole charm dir, then it skips all files <facubatista> drewn3ss, the "entrypoint" is your main Python file, not a directory <drewn3ss> ack <facubatista> drewn3ss, to hack it until a proper solution is ready, you could include your files in the CHARM_OPTIONAL list <facubatista> drewn3ss, in that build.py, line ~38 <drewn3ss> is that environmental, arg-able or am I forking the code? <drewn3ss> forking the code...cool. <drewn3ss> that's...a non-starter <facubatista> drewn3ss, as I said, I'm working on the proper solution <drewn3ss> thank you :) <drewn3ss> I can also move my files dir to src <drewn3ss> as it seems all of src is included <drewn3ss> that's reasonable for now * facubatista eods #smooth-operator 2020-08-12 <narindergupta> facubatista, I am using juju deploy . <mup> Issue operator#371 opened: Use controller storage if no local storage exists <Created by stub42> <https://github.com/canonical/operator/issues/371> <Chipaca> moin moin moin <Chipaca> (my previous good morning went to the wrong channel) <jam> morning @Chipaca <Chipaca> heh, the mattermost effect <bthomas> ð Good Morning ð <Chipaca> ð <bthomas> :) only missing a rattle snake <Chipaca> I think I'm going to make the tests of a 'charmcraft init' charm fail <Chipaca> until the author does the XXXs :) <bthomas> How about a message saying what XXX is along with the failed message ? <Chipaca> yup <Chipaca> (that's already there) <Chipaca> you see the messages when you charmcraft init already <ballot> Hello ! <ballot> Chipaca: trying to test your code change, however, unlike pjdc, when I run a "juju run --unit mm-pd-bot/3 -- pod-spec-set --file /pod.json --k8s-resources /k8s.json", it hangs doing nothing <ballot> same goes for any juju run really ... <ballot> I realize I never tried a juju run on a k8s charm <Chipaca> jam: that works, right? <jam> Chipaca, I had just been trying to say good morning in mattermost, and immediately decided to say hello here instead <jam> ballot, Chipaca IIRC in 2.8 you can't juju run on K8s because it uses 'juju ssh' under the hood and K8s containers don't run ssh <jam> I think they are working on that for 2.9, though I would be surprised that it just hangs. <Chipaca> ballot: ^ :-/ <ballot> interesting <ballot> As a workaround, what would be the right move to use pod-spec-set with the right context then ? <ballot> (lacking juju knowledge) <jam> ballot, hack it into your charm and test that way? <jam> kubectl exec ? <jam> but kubectl wouldn't have the context <ballot> i've created the file on the operator pod right now, but if I run it directly from there I have : ERROR JUJU_CONTEXT_ID not set <ballot> yeah, that's the issue, I'm trying to see if Chipaca's branch fixes https://bugs.launchpad.net/juju/+bug/1880637 <ballot> what is strange is that pjdc could do it ... <ballot> oh well I can try a more recent juju <Chipaca> ballot: maybe he wasn't using a k8s charm <ballot> nevermind I'll just hack through my charm and separate kubernetesResources from the pod_spec and test this way <ballot> Chipaca: I doubt it, but I'll make it work somehow :). But after lunch. Never stand between a frenchman and his lunch ! * Chipaca would never <Chipaca> reminds me i need to go to the shops to set fire to some baguettes * Chipaca runs <Chipaca> jk i need to buy some hydration â¦ pills? the fizzy kind * Chipaca bbiab <facubatista> Â¡Muy buenos dÃ­as a todos! <bthomas> Morning <facubatista> hola bthomas <bthomas> yep <bthomas> how can I be for service facubatista <bthomas> just watched the testing.Harness video by Paul Goins you gave me last week <facubatista> awesome <ballot> Chipaca: I confirm your fix works <Chipaca> ballot: \\\\\oooo///// <ballot> Chipaca: I have a WIP branch waiting for your change to land then :) : https://code.launchpad.net/~ballot/charm-k8s-mm-pd-bot/+git/charm-k8s-mm-pd-bot/+merge/389156 <ballot> The pastebin showing the fix : https://pastebin.ubuntu.com/p/VPpRGpr9D8/ <ballot> Updating the github PR <mup> Issue operator#293 closed: passing k8s_resources to pod.set_spec does not work <juju-workaround> <Created by jetpackdanger> <Closed by chipaca> <https://github.com/canonical/operator/issues/293> <mup> PR operator#369 closed: use yaml instead of json for pod-spec-set call <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/369> <Chipaca> ballot: ^^^ :) <ballot> ah ! too fast for me :) <ballot> Just updated the PR with my findings <ballot> well, all good, I'll check for secrets and configmaps later on to have a real "k8s friendly" configuration pattern then, thanks for the help Chipaca <Chipaca> thanks for testing! <bthomas> I thought the standard for naming Python unittest tests was test_* . The prometheus charm has "tese" as a suffix. Also it is lacking a package initializer (__init__.py) so if I use a script such as "run_tests" it does not run any tests. <Chipaca> bthomas: "tese"? <bthomas> oops test_ <bthomas> test files are named charm_test.py instead of test_charm.py * bthomas goes to get coffee before standup <Chipaca> jam: facubatista: what's a good value of foo in juju_version.has_foo() to know if the juju has state-set/state-get? <Chipaca> has_state()? has_state_get()? has_controller_state()? <facubatista> has_state_setting_capability() <Chipaca> has_embalmed_ones() <Chipaca> has_trained_ones() <Chipaca> has_suckling_pigs() <facubatista> can_set_state() <Chipaca> has_mermaids() <Chipaca> facubatista: can_haz_state() <jam> Chipaca, supports_controller_storage is the one I like <Chipaca> has_controller_storage? :) <jam> Chipaca, if you want your has you can have it * Chipaca can has it <Chipaca> jam: facubatista: poke <facubatista> oops <jam> sorry, just finishing standup <Chipaca> facubatista: https://grammarist.com/idiom/lay-of-the-land-or-lie-of-the-land/ <crodriguez> good day everyone! I'm hitting this issue with a subordinate charm deployed on a ubuntu VM. I'm not sure what is causing it, any idea? https://paste.ubuntu.com/p/pMmg365QR8/ <Chipaca> crodriguez: hi! at what point do you get that? doing what, i mean <crodriguez> Chipaca, simply by deploying the charm. I don't think it has time to go through any events really, from what I can see in the logs. I didn't run into this before and I have been editing the charm, so maybe something I changed triggered this <crodriguez> I'll go back a few commits and compare if I'm hitting that still <Chipaca> crodriguez: 0.8 looks at JUJU_VERSION for some things, more than 0.7 <Chipaca> so it might be us <Chipaca> but it's supposed to always be set, jam checked all the way back to 2.6 or sth <crodriguez> I'm using juju 2.8.1 <crodriguez> it's just checking for the JUJU_VERSION environment variable, right? <Chipaca> yep <facubatista> crodriguez, good day! <crodriguez> https://paste.ubuntu.com/p/V75wy85pq7/ humm maybe something changed in juju ? <Chipaca> there's no JUJU env vars <jam> crodriguez, "juju run --unit ubuntu/0 env" <jam> That should create a hook environment, where env vars like JUJU_VERSION would be set. <jam> they *aren't* set inside of an SSH session. <narindergupta> Chipaca, I am still getting this error ERROR cannot repackage charm: symlink "config.yaml" is absolute: "/home/ubuntu/narinder/charm-k8s-cassandra/config.yaml" <Chipaca> narindergupta: what are you trying to do? <jam> narindergupta, Chipaca : If you are using charmcraft to build the charm, you need to do "charmcraft build; juju deploy ./CHARMNAME.charm" <narindergupta> Chipaca, I build the charms using charmcraft and now trying to deploy <jam> you can't deploy from the directory itself. <narindergupta> jam, oh ok let me try tht <crodriguez> ah thanks jam. So doing this, https://paste.ubuntu.com/p/rk8337KpJf/ , looks like the env is set correctly <jam> crodriguez, for your initial pastebin, do you have a bit more context? <jam> I wonder if we are failing to set JUJU_VERSION for something like "during collect-metrics hook" <narindergupta> jam, ok I can confirm that your method is orking <jam> narindergupta, great <jam> narindergupta, I saw that when you were talking last night, but you weren't around for me to mention it :) <crodriguez> jam I can get you a complete pastebin of the charm execution <narindergupta> jam, no worries and thanks; <jam> JUJU_VERSION in hook environments hasn't been around forever, but the line existed in 2017-09 <jam> so it definitely should be in ~2.4+ <narindergupta> jam, Chipaca I got an install hook error just wondering why we need install in k8s? <jam> narindergupta, you don't have to implement it, but it is a point the framework itself uses to unpack/setup the python environment that the charm executes in. <crodriguez> jam: https://paste.ubuntu.com/p/WZfMRkvgyn/ that's all there is in /var/log/juju/unit-iscsi-connector-0 <narindergupta> jam, in that case should I remove the install hook? As I am getting application-charm-k8s-cassandra: 14:03:28 ERROR juju.worker.uniter.operation hook "install" (via hook dispatching script: dispatch) failed: exit status 1 <jam> crodriguez, 2020-08-12 13:39:05 ERROR juju.worker.meterstatus runner.go:77 error running "meter-status-changed": exit status 1 <jam> so it is one of the metrics hooks <narindergupta> And I am not aware about the dispatch script <jam> narindergupta, it sounds more like you have a typo/etc in your Charm code, and during 'install' is the first time we try to load your code. <jam> so its less about 'install' and more just we had a problem executing your charm <jam> if you remove 'install' then we'll hit the same thing in whatever other hook we call. <narindergupta> jam, ok let me read my code once more time then <jam> crodriguez, the reason we don't normally hit that (I believe) is because if you don't have a metrics.yaml file, then Juju doesn't fire the metrics hooks. <crodriguez> mmh.. what is the metrics.yaml file for ? :) <bthomas> Thank you for your suggestions in standup. That was a very useful discussion. Here is a start on the google docs (I will keep adding more questions iteratively as discussed) https://docs.google.com/document/d/14EKsjHtzXnOvY6vaI47VwFzl6MEQ6OxaSBHsN7bcG9Q/edit <jam> crodriguez, hm. I don't see a metrics.yaml in your code, so I could be off base. <jam> Chipaca, ^^ it looks like JUJU_VERSION isn't set in the metrics hooks, one more reason they should be normalized. <crodriguez> narindergupta, jam, there is a way
{'channel': 'smooth-operator', 'month': 8}