#smooth-operator 2020-07-13
<Chipaca> good morning all!
<jam> morning Chipaca
<Chipaca> jam: how's things?
<stub> jam: controller state dropped in with no changes, looks happy: https://pastebin.ubuntu.com/p/p6nx4wz8vm/
<facubatista> :helo:
<facubatista> Â¡Muy buenos dÃ­as a todos!
<facubatista> Chipaca, please remember my https://github.com/canonical/charmcraft/pull/75
<mup> PR charmcraft#75: Support for pushing bytes to the Storage <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/75>
<facubatista> Chipaca, do we plan to have "docs on the web" for charmcraft the tool? like a RTD or even a category in Juju's Discourse? Something to point to from the command line help
 * facubatista brb
 * facubatista is back
<Chipaca> facubatista: saying we _plan_ to have that is a bit much, but I'm not opposed to the idea
<facubatista> Chipaca, ack
<Chipaca> jam: you didn't _actually_ review #352 btw, you just pretended to
<mup> PR #352: make ops.lib.use support relative submodules <Created by chipaca> <https://github.com/canonical/operator/pull/352>
<jam> fine... :)
 * Chipaca reads that in beuno's voice
<mup> Issue operator#351 closed: ops.lib.use does not support submodules <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/351>
<mup> PR operator#352 closed: make ops.lib.use support relative submodules <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/352>
 * Chipaca lands ALL the things
<Chipaca> now i just need to do the same thing with all the issues
<mup> PR operator#355 closed: readme tweaks (including link to the api docs) <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/355>
<jam> all the... small things...
<Chipaca> it
<Chipaca> it's not the size of the pr that matters
<Chipaca> or something
<Chipaca> brb fiddling with the hardware again
<facubatista> jam, oops, sorry, you were saying something
<jam> facubatista, I just said bye
<facubatista> :)
 * Chipaca zzz
 * Chipaca goes to get some tea
<Chipaca> facubatista: meeting?
<Chipaca> facubatista: ah there you are :-)
<Chipaca> I suddenly realised why I've been feeling "bleh" all day, when i noticed my face wasn't red because of a weird camera effect
<Chipaca> it's actually that red in the mirror too
<Chipaca> i guess i got a bit toasted running yesterday :-)
<Chipaca> oh dang the dev summary
<Chipaca> the sprint threw me off :-|
<facubatista> je
<Chipaca> i guess i'll write it up today and have you two check it as available
<Chipaca> but not now, now i need a break, and maybe a meal
<Chipaca> so ttfn, ttyl, etc ;-)
<facubatista> :)
<facubatista> Chipaca, jam, this is ready for review, now: https://github.com/canonical/charmcraft/pull/76
<mup> PR charmcraft#76: Store upload <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/76>
<crodriguez> hi facubatista . I'm trying to import charmcraft instead of having the submodule in my charm. I added it to my dev-requirements.in, ran make build, and deployed mycharm.charm . However, my charm fails on install because it does not find the ops module
<crodriguez> I'm unsure of what I'm doing wrong here
<facubatista> hola crodriguez
<crodriguez> (all of this inside a virtualenv)
<facubatista> crodriguez, import charmcraft or import ops?
<facubatista> crodriguez, charmcraft is a command line tool, you should not import it
<crodriguez> yeah that's what I meant. import ops.charm
<facubatista> crodriguez, are you using charmcraft to build the charm?
<facubatista> crodriguez, would you remind me the url of your project?
<crodriguez> I mentioned charmcraft because that's the package to install. Maybe I got confused by Maglana's new template. He's using make, not charmcraft build
<crodriguez> let me try to build it once more
 * facubatista checks it
<crodriguez> it's a new project facubatista https://github.com/camille-rodriguez/charm-iscsi-connector
<facubatista> it should be easier
<facubatista> it looks that Makefile is using charmcraft to build
<facubatista> but at the same time hiding it
<facubatista> @(python -m charmcraft build 2>&1 || echo "charmcraft build error") | tee .last-build
<facubatista> this template is doing so many things I fail to understand it
<facubatista> crodriguez, I see your requirements.txt is fine
<crodriguez> hah, he showed it to us this morning in a presentation. He wrote it a few days ago, so it's still fresh. But it's an attempt at automating build, adding tests, and providing a way to deal with pip dependencies by adding pip-compile
<facubatista> you don't need to deal with pip dependencies
<facubatista> charmcraft does
<facubatista> `charmcraft` shouldn't be used as a dependency ideally, but from the snap
<crodriguez> well charmcraft build or make build both are failing me rn so it's not the template lol
<facubatista> crodriguez, 1'
<crodriguez> this is a subordinate charm. Could it not be installing its dependencies correctly upon deployment?
<facubatista> this template is not good
<facubatista> it's super mixing old and new stuff
<facubatista> crodriguez, let's start to clean it a little to make your charm work
<crodriguez> alright I can revert to my previous commit, when I didnt have the template and still had the submodule
<facubatista> crodriguez, that would be better
<facubatista> crodriguez, and we work from there
<facubatista> crodriguez, let me know when you did that so I re-clone
<crodriguez> ok ! yeah I'll ping you whenever I'm ready
<facubatista> crodriguez, I'm close to EOD, but I can wait for you
<facubatista> crodriguez, or we can do this first time tomorrow... I just don't want to block you
<crodriguez> oh same here, so don't wait on me. I'll update you tomorrow, thanks :)
<crodriguez> I'm doing a bit of extra coding in the sprint after-hours, nothing urgent :)
<facubatista> crodriguez, let's work on this together tomorrow, I'm super interested in enabling an easy path in these cases
<facubatista> we can HO or whatever
 * facubatista needs to reboot, brb
#smooth-operator 2020-07-14
 * Chipaca goes for coffee
<Chipaca> actually, let's make that a whole breakfast
<jam> morning Chipaca, enjoy your breakfast
<facubatista> Â¡Muy buenos dÃ­as a todos!
<jam> morning facubatista
<facubatista> hola jam
 * Chipaca harrumphs some more
<facubatista> jam, please remember my https://github.com/canonical/charmcraft/pull/76
<mup> PR charmcraft#76: Store upload <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/76>
<facubatista> crodriguez, hola! please let's work on your charm when you have some minutes, thanks!
<jam> facubatista, indeed, I have it open, just ran into some issues so didn't get a review completed
<facubatista> jam, no rush, thanks!
<crodriguez> morning facubatista ! I sent you an invite for a meeting later today. I'm in the field/sales sprint all day before that
<facubatista> crodriguez, ah, oh, wonderful, thanks!
<crodriguez> :)
<crodriguez> facubatista: did you lose connection?
 * facubatista totally lost internet for ~30s
<crodriguez> haha
<crodriguez> is charmcraft build taking templates into consideration? I added a template folder under my charm root, but it is not copied over when I deploy the charm
<crodriguez> also, it creates only the 3 mandatory hook names. It is not creating config-changed, etc.
<facubatista> crodriguez, we're not including "templates", we need to fix that
<crodriguez> yeah, I opened https://github.com/canonical/charmcraft/issues/80
<facubatista> I wonder if we should provide a "--include" option to let devs include whatever they want
<crodriguez> I wonder why it wouldn't just include every folder you include in your charm, maybe only excluding what is excluded by .gitignore
<facubatista> (which could be annotated in the charmcraft.yaml file, so no need to specify it always)
<facubatista> crodriguez, but there's stuff one would want to avoid: the tests, for example, which may have fixture files that may make the zip large
<crodriguez> ah we can configure the build with a charmcraft.yaml file ? interesting
<facubatista> crodriguez, we WILL be able to :)
<facubatista> sorry, we're yeat too young :p
<crodriguez> haha until today I just deployed directly the charm without building and it was working fine. I guess charm build is necessary for dependency packages though
<facubatista> crodriguez, regarding the hook names, it's included what's needed for the pre-dispatch jujus (and the operator framework will take care of the rest)
<crodriguez> well if config-changed fails, I run debug-hooks, go into my unit, and want to re-run the hook. But the hook doesn't exist so it is really confusing
<facubatista> mmm... maybe the operator framework is not creating them because all works through the dispatch mechanism? (not really using hooks)
<facubatista> crodriguez, which juju do you have?
 * facubatista brb
<crodriguez> 2.8.1-bionic-amd64
<facubatista> right, it's using dispatch
<facubatista> jam, Chipaca, how do you trigger a "hook" using dispatch?
<facubatista> crodriguez, I *think* it's by doing: JUJU_DISPATCH_PATH=hooks/config-changed ./dispatch
<crodriguez> why is it not just existing in the /hooks folder like for all the reactive charms? this changes completely the troubleshooting experience
<crodriguez> re:templates , could we just add templates in CHARM_OPTIONAL ? https://github.com/canonical/charmcraft/blob/master/charmcraft/commands/build.py#L38 Does this handle folders or only files?
<facubatista> crodriguez, yes, if you add templates in CHARM_OPTIONAL it will work
<facubatista> the question is what we *really* need... "templates" for sure, but what else?
<crodriguez> hum that could be decided by reviewing existing charms
<crodriguez> like reactive charms
<facubatista> crodriguez, FWIW, we have https://github.com/canonical/charmcraft/issues/39
<crodriguez> ok yeah, my bug might be a duplicate then. It would be nice if a decision was taken soon though, because this pretty much prevents me from using charmcraft build rn. I might just do a PR for templates only until that broader question is resolved
<facubatista> Chipaca, let's talk about this â in tomorrow's standup, please :)
 * facubatista eods
#smooth-operator 2020-07-15
<Chipaca> moin moin
<jam> morning Chipaca, how's it going?
<Chipaca> jam: better today i think, thank you. You?
<jam> Things are going well here.
 * Chipaca takes a break
 * Chipaca sets things on fire to see if they break
<facubatista> Â¡Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð !
<facubatista> oh, I thought we had a meeting right now
<Chipaca> facubatista: we did, but it was canceled because the main party was off partying, mainly
<facubatista> oh
<mup> Issue operator#357 closed: Add support for startupProbe checks <Created by jayk-canonical> <Closed by jameinel> <https://github.com/canonical/operator/issues/357>
<mup> PR operator#359 opened: ops/testing.py: Harness.add_resource <Created by jameinel> <https://github.com/canonical/operator/pull/359>
 * facubatista -> lunch
<facubatista> jam, Chipaca: a very simple branch in preparation for the real one (so it's not that big) https://github.com/canonical/charmcraft/pull/82
<mup> PR charmcraft#82: Work in preparation for the list-revisions branch <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/82>
<facubatista> thanks!
<facubatista> jam, Chipaca, Renamed 'list' command to 'names' in sync with latest UX decisions https://github.com/canonical/charmcraft/pull/84
<mup> PR charmcraft#84: Renamed 'list' command to 'names' in sync with latest UX decisions <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/84>
<Chipaca> i think this is what EOD feels like
#smooth-operator 2020-07-16
<Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
<jam> morning Chipaca
<Chipaca> taking a page from pytest, would 'pip install ops-k8s' feel like a reasonable way to install the k8s ops component?
<jam> Chipaca, ops-k8s or component-k8s both feel good to me
<jam> ops-lib-k8s
<jam> just to brainstorm some things
<Chipaca> ops-lib-k8s sgtm :)
<jam> Chipaca, yeah, I think I like it the most so far
<jam> and it fits the 'opslib' ops.lib stuff
<Chipaca> it's not ready yet but https://github.com/chipaca/ops-lib-k8s exists :)
<jam> oooh, shiny
<jam> Chipaca, do we want people to typically put everything into __init__ or just import it into there?
<jam> It feels odd to have a package that only has an __init__.py
<Chipaca> jam: tbh in this case it could just be a k8s.py :)
<jam> Chipaca, indeed, but does our ops lib support that?
<Chipaca> i'm torn on which one is better
<jam> Also where is LIBNAME, etc
<Chipaca> this doesn't have opslib support yet
<jam> Chipaca, I like that you can grow into having multiple files
<Chipaca> i'll get to that :)
<Chipaca> me too
<Chipaca> but python doesn't care really, k8s.py and k8s/__init__.py are used in the same way
<Chipaca> anyway, right now i'm getting it to work on 3.5
<Chipaca> python 3.5 doesn't support TLS newer than 1.2
<jam> Chipaca, *sigh*. given Firefox now needs you to explicitly enable support for older TLS
<jam> Chipaca, out of curiousity, why "k8s_test.py" and not "test_k8s.py" I know we use the latter in ops, but was trying to figure out if there is a standard
<facubatista> Â¡Muy buenos dÃ­as a todos!
<jam> morning facubatista
<facubatista> hola jam
<Chipaca> jam: just because i renamed it
<Chipaca> i mean
<Chipaca> i did not rename it
<Chipaca> :)
<Chipaca> jam: i suspect unittest wouldn't find the former, fwiw
<facubatista> Chipaca, jam, When building replace current hooks that are links to the charm https://github.com/canonical/charmcraft/pull/85
<mup> PR charmcraft#85: When building replace current hooks that are links to the charm <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/85>
<facubatista> Chipaca, jam: The "list revisions from the Store" command - https://github.com/canonical/charmcraft/pull/86
<mup> PR charmcraft#86: The "list revisions from the Store" command <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/86>
<facubatista> AttributeError: type object 'datetime.datetime' has no attribute 'fromisoformat'
<facubatista> py3.5 hates me
<Chipaca> facubatista: with all its being
<facubatista> I need to stop this crazy dance of pathlib2 being used in py35, which is 99% the same than pathlib
 * facubatista will propose a branch
<Chipaca> facubatista: standup?
<facubatista> Chipaca, jam, in my charmcraft#86 branch, we keep "finding the information" from the context, which so far looks nice... if you're in the project, it finds the "charm name" from there... if not, you can use '--charm-name' and its fine
<mup> PR charmcraft#86: The "list revisions from the Store" command <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/86>
<Chipaca> mhmm
<facubatista> as it's an "option", it would be "charmcraft revisions --name=myblog", not "charmcraft revisions myblog"
<facubatista> so far, maybe so good
<facubatista> however, in the "release" command it gets ugly
<facubatista> we can still guess the charm name, however the channel and revision are mandatories
<facubatista> "charmcraft release 5 stable" looks weird
<facubatista> "charmcraft release 5 stable --name=myblog" looks ugly
<Chipaca> facubatista: 1 sec
<Chipaca> charmcraft release --channel=stable --release=5 --name=myblog
<facubatista> "charmcraft release --name=myblog --revision=5 --channel=stable" looks like those are options, but not
<Chipaca> with --channel defaulting to edge and --release defaulting to 'last'
<Chipaca> wouldn't that work?
<facubatista> Chipaca, I don't know "last"
<Chipaca> you can
<Chipaca> by asking
<facubatista> Chipaca, unless I go and do an extra hit to the store
<Chipaca> why wouldn't you?
<facubatista> Chipaca, however, isn't this a little dangerous, like releasing stuff to somewhere without the user specifying where?
<Chipaca> that's why i suggested 'edge' be the default for channel
<Chipaca> and not 'stable' :)
<facubatista> yeah, sure
<Chipaca> facubatista: OTOH you could leave channel as an argument
<Chipaca> and make just revision an option
<Chipaca> but then
<facubatista> "charmcraft release edge" makes much more sense
<Chipaca> ok :)
<facubatista> as "last" is the revision that you want to release in the 99% of the cases
<Chipaca> i was about to argue how it was a bit weird, but i'd be just arguing against myself :-P
<Chipaca> facubatista: also as an aside, tab completion for --revision= would be very nice :-)
<Chipaca> and for --name
<Chipaca> but we can talk about that tomorrow (or next week (or...))
<facubatista> oh, I forgot about that
<facubatista> Chipaca, also, channel can be multiple without getting the extra weirdness when it's not alone
<facubatista> I mean, "snapcraft myblog 4 edge" is ok, but "snapcraft myblog 4 edge beta 3.0/edge" is weird
<facubatista> "charmcraft edge" is ok, "charmcraft edge beta 3.0/edge" is still ok
<facubatista> sorry
<facubatista> I mean, "snapcraft release myblog 4 edge" is ok, but "snapcraft release myblog 4 edge beta 3.0/edge" is weird
<facubatista> "charmcraft relase edge" is ok, "charmcraft release edge beta 3.0/edge" is still ok
<Chipaca> ok
<Chipaca> facubatista: and --revision=4,5,6 also works
<Chipaca> or --revision=4 --revision=5
<Chipaca> i prefer the comma-separated one but thats just me :-)
<facubatista> Chipaca, does it make sense to release multiple revisions at the same time?
<facubatista> I think it may be easy to confuse
<Chipaca> facubatista: when doing multi-arch, yes
<facubatista> charmcraft release --revision=3 edge --revision=7 beta
<facubatista> Chipaca, I think its way more normal to release one revision to multiple channels, than releasing several revisions at the same time
<Chipaca> facubatista: again, when doing multi-arch, you release all the revisions that correspond to one point-in-time build at the same time, usually
<Chipaca> facubatista: but it's not important tbh
<Chipaca> we can nail it down later :)
<facubatista> ok
 * facubatista eods and eows, will be back on Monday!
<Chipaca> facubatista: have a good one!
<Chipaca> i'm off for today too
#smooth-operator 2020-07-17
<mup> Issue operator#356 closed: Support extra service names <Created by knkski> <Closed by knkski> <https://github.com/canonical/operator/issues/356>
