#smooth-operator 2020-06-01 <MarkMaglana> jam: if you're still looking for a way to review code outside of a PR (i.e. code that's already been merged), I created a sample issue here: https://github.com/relaxdiego/charm-k8s-alertmanager/issues/1 <MarkMaglana> oh and good morning! <MarkMaglana> :-) <jam> morning MarkMaglana <jam> thanks for the suggestion <MarkMaglana> jam: no worries! hope you and the rest of the crew had a great weekend. <stub> Might want to revisit the use of storing pickles in the db rather than json or yaml. I'm seeing devs hand around one liners for debug like: root@mattermost-operator-0:/var/lib/juju# python3 -c 'import pickle, pprint, sqlite3, sys ; show_none = False ; print("\n".join(["=== {} ===\n{}\n".format(t[0], pprint.pformat(t[1])) for t in [(row[0], pickle.loads(row[1])) for row in sqlite3.connect(sys.argv[1]).execute("SELECT handle, data from snapsho <stub> t")] if show_none or t[1] is not None]))' ./agents/unit-mattermost-1/charm/.unit-state.db <stub> Which is not the sort of friendly debugging tip we want on the forums, when you could be using the sqllite cli as intended and it not being an operator framework problem. <jam> stub, I agree that is pretty ugly. With the caveats that we are looking to stop having an SQLite database locally anyway, since Juju 2.8 will allow us to store the state in the juju controller. <jam> stub, I'd be pretty curious why they want to read raw snapshot data rather than use the objects in memory <jam> especially given things like "juju debug-code" to let you drop into a debugger during your hook execution <stub> True, so we might want a CLI tool available to dump things <stub> People like to drop to lower levels sometimes, when they don't understand why the higher levels are giving them the answers they are giving them <stub> Say, objects existing in RAM but not being persisted to the DB would point to unexpected termination before commit <stub> (whoops, maybe that 'kill -1' wasn't what I meant to do) <mup> Issue operator#265 closed: Auto determining handlers is actually not recommended <Created by jameinel> <Closed by jameinel> <https://github.com/canonical/operator/issues/265> <mup> Issue operator#302 closed: AttributeError: 'MattermostCharmEvents' object has no attribute 'db_relation_joined' <Created by jetpackdanger> <Closed by jameinel> <https://github.com/canonical/operator/issues/302> <Chipaca> morning all <jam> morning Chipaca <jam> Chipaca, https://github.com/relaxdiego/charm-k8s-alertmanager/issues/1 fyi <facubatista> Muy buenos dÃ­as a todos! <vgrevtsev> hi jam - so re: https://github.com/canonical/operator/issues/307 did I understand correctly that the only way to fix this issue is to re-write ALL of my unit tests with harness? <jam> vgrevtsev, so Harness has the functionality to work around the problem with registering a class with multiple frameworks. <jam> You can do that work yourself <jam> or you can use Harness which does it for you <mup> Issue operator#310 opened: hooks/install ran, but other hooks not expanded <Created by stub42> <https://github.com/canonical/operator/issues/310> <vgrevtsev> jam: ok, and https://github.com/canonical/operator/issues/309 - you think it has the same root cause as 307? <vgrevtsev> (re model name env var) <jam> vgrevtsev, no. 309 is that your Adapter code is doing "os.environ['JUJU_MODEL_NAME']" and you don't set the environ variable <vgrevtsev> But why it's not failing 100% of the time? <vgrevtsev> I mean, at some point this env var is configured by someone else <jam> vgrevtsev, so the 307 failure is because if Harness test runs first, then the other test runs successfully (order of tests run) <jam> JUJU_MODEL_NAME failed 100% of the time for me. <jam> vgrevtsev, are *you* setting JUJU_MODEL_NAME in your shell and running the test suite? <jam> so it works in that shell, but not in the other shell? <vgrevtsev> Of course no. `tox -epy37` that's what I'm doing. <vgrevtsev> jam: https://paste.ubuntu.com/p/qB6XhXfHQH/ <vgrevtsev> same code, same command <vgrevtsev> but different failure points - when it raises the KeyError, it fails on `config_changed.emit()` but it was failing on `harness.begin()` before <jam> vgrevtsev, look carefully at the line: test/charm_test.py F.. <jam> when it is ".F." or "..F" it fails with "cannot register" <jam> because it is running your other test first <jam> when it is "F.." it fails with JUJU_MODEL_NAME because it is running Harness test first <jam> vgrevtsev, if you comment out/patch the non-Harness test, then it will always fail with JUJU_MODEL_NAME <vgrevtsev> jam: I see what you mean... true, it's failing 100% of the time <jam> Chipaca, when Juju returns json output, it doesn't pretty format it, but that leads to ugly strings in tests. <jam> Should I create a nice string for the test, or should I make it exactly like the Juju output? <Chipaca> jam: nice strings are fine <Chipaca> jam: the assumption that the python json parser won't care seems reasonable <jam> Chipaca, so it also appears that the format of "status-get --application=true" is very different than --application=False, which also wasn't accounted for <Chipaca> as long as it's valid json mind you; one problem with pretty-printing it is that you might end with , at the end of an object, which json hates <Chipaca> (yaml is fine with it though :) ) <Chipaca> jam: ooh <Chipaca> jam: rock on <Chipaca> where's the documentation for juju's relation-created ? <jam> Chipaca, since it is new in 2.8 maybe nonexistant ? <Chipaca> :'( ok <jam> Chipaca, this looks like the one that should be updated: https://discourse.juju.is/t/charm-hooks/1040 <Chipaca> facubatista: wrt the tutorial gist, ok if i link it from the dev summary? (with a note that when done we'll put it on discourse) <facubatista> Chipaca, +1, shouldn't we improve it at some point? <Chipaca> facubatista: totally :) i thought you were doing that :D <Chipaca> facubatista: actually, do you have the url for that? * Chipaca doesn't know where he put it <facubatista> Chipaca, https://gist.github.com/facundobatista/d3b7de7a624915227de051cba079e3d6 <Chipaca> i'm going to grab lunch <mup> PR operator#311 opened: ops/model.py: Proper support for status-get <Created by jameinel> <https://github.com/canonical/operator/pull/311> <facubatista> Chipaca, taking in consideration that this meeting was short, why not have the standup at usual time (in 17' from now) so it doesn't get superlate to jam? <jam> Chipaca, looking at https://github.com/canonical/operator/issues/310 I see it triggering "run_any_legacy_hook" and seeing that dispatch is just a symlink to itself. <jam> that would seem to say it thinks that it "is_dispatch_aware" <jam> Chipaca, sounds like you broke it by just detecting JUJU_DISPATCH_PATH in os.environ and didn't check that it wasn't called as 'dispatch <jam> "we" broke it when we landed your patch since I certainly was looking at the same code and thought it was correct <Chipaca> hmmm <Chipaca> jam: but it's not necessarily called as dispatch (in the shim case for ex) <Chipaca> which was why we changed that behaviour :-/ <jam> Chipaca, so the issue is that JUJU_DISPATCH_PATH is set, which is the only check we are currently using, but we aren't being called from dispatch, yes <jam> Chipaca, I think it was to support the case where 'dispatch' isn't a symlink but is just a shell script <jam> but we need a way to know how we were first invoked <jam> (for example, if sys.argv[0] has 'hooks/*' then we do need to create the links, or if 'dispatch' doesn't exist, etc.) <jam> Chipaca, I posted to the bug, maybe it clearer there? * jam heads to dinner for a bit, will be back for standup * Chipaca takes a break <mup> PR operator#312 opened: ops.main: only do _init_dispatch() if dispatch exists <bug> <Created by chipaca> <https://github.com/canonical/operator/pull/312> <Chipaca> facubatista, jam, fix for #310 ^ <mup> Issue #310: hooks/install ran, but other hooks not expanded <Created by stub42> <https://github.com/canonical/operator/issues/310> <jam> Chipaca, and the test properly failed without the patch ? <Chipaca> jam: oh yes <jam> lgtm <Chipaca> jam: i was just commenting as much on the bug :) <Chipaca> I could also write a TestMainWithNoDispatchButJujuIsDispatchAwareAndScriptsAreCopies for extra fun <Chipaca> but didn't feel it added anything * Chipaca is a firm believer in separable coordinates <mup> Issue operator#313 opened: If ops is installed, the test run picks up the wrong one <Created by chipaca> <https://github.com/canonical/operator/issues/313> <mup> PR operator#314 opened: test_main: set up PYTHONPATH so the sub-process picks up this ops <Created by chipaca> <https://github.com/canonical/operator/pull/314> <Chipaca> jam: are you around, or have you stepped away? <jam> Chipaca, I'm back now <Chipaca> jam: hi again :) <Chipaca> jam: should I push the change to use a decorator on #311 ? <mup> PR #311: ops/model.py: Proper support for status-get <Created by jameinel> <https://github.com/canonical/operator/pull/311> <Chipaca> jam: also, should it be 'register', or '_register'? :) <Chipaca> jam: if _register, should it also be _from_name? <jam> Chipaca, I originally had "_register" but then my editor complained that I was using a private method of another class <Chipaca> aw <Chipaca> single _ is protected, not private :) <jam> and "name = None" gives us the value that auto-complete of things annotated StatusBase have a .name attribute <jam> which all of the actual implementations have <Chipaca> jam: we could make it name='' so it's always a str, also <Chipaca> sorry i'm bikeshedding <jam> Chipaca, I'm happy enough with that <Chipaca> jam: why would it complain about _register when you're calling it on the class itself though? or was that in the tests <jam> Chipaca, so I think it is because it isn't inside the class itself, it was at the top level of the module <Chipaca> ah ok * Chipaca changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.6.0 (pip install ops) || charmcraft 0.1.0 (pip install charmcraft) <jam> Chipaca, did you already do the work for decorator, or shall I work on it? <jam> Chipaca, it seems we have general agreement to do it that way <Chipaca> jam: i've already done it, but it's not a lot of work so as you wish <jam> Chipaca, if you have it, I'm happy for you to land it <Chipaca> jam: pushed, waiting for tests * facubatista -> lunch <jam> Chipaca, cheers <Chipaca> I'll take off now, go for my run and dinner and etc, and will come back after that to land this and push out 0.6.1 <Chipaca> should we have a changelog in tree? <jam> Chipaca, some people like it, I can take it or leave it. <Chipaca> I'll go without until somebody complains :) <Chipaca> 'git log' works for me <Chipaca> (and gives us the ability to build the changelog retroactively as long as we're good with the tags <Chipaca> ) <Chipaca> anyway. I'm off. <Chipaca> jam: have a great evening! * facubatista is back <Chipaca> facubatista: i can haz review of #311 ? <mup> PR #311: ops/model.py: Proper support for status-get <Created by jameinel> <https://github.com/canonical/operator/pull/311> <facubatista> Chipaca, sure <Chipaca> tks * Chipaca disappears in a puff of dinner-making <facubatista> Chipaca, done <facubatista> (I already reviewed it in the morning, the only thing missing was the "how to register" thing <facubatista> ) <facubatista> Chipaca, the "-e" that you put in operator's requirements.txt file, theorically is the "--editable" option of "pip install", right? how that is translated to "get dependencies from setup.py"? <Chipaca> facundo__: it translates to 'python setup.py develop' i think <mup> Issue operator#288 closed: StatusBase are registered on instantiation not definition <Created by jameinel> <Closed by chipaca> <https://github.com/canonical/operator/issues/288> <mup> PR operator#311 closed: ops/model.py: Proper support for status-get <Created by jameinel> <Merged by chipaca> <https://github.com/canonical/operator/pull/311> <mup> Issue operator#310 closed: hooks/install ran, but other hooks not expanded <Created by stub42> <Closed by chipaca> <https://github.com/canonical/operator/issues/310> <mup> PR operator#312 closed: ops.main: only do _init_dispatch() if dispatch exists <bug> <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/312> <mup> PR operator#315 opened: bumping ops.__version__ for release 0.6.1 <Created by chipaca> <https://github.com/canonical/operator/pull/315> <Chipaca> facundo__: ping <Chipaca> ok, i'm landing the release bump <mup> PR operator#315 closed: bumping ops.__version__ for release 0.6.1 <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/315> * Chipaca changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.6.1 (pip install ops) || charmcraft 0.1.0 (pip install charmcraft) <Chipaca> stub: 0.6.1 just released for the fix to your #310 (thanks!) <mup> Issue #310: hooks/install ran, but other hooks not expanded <Created by stub42> <Closed by chipaca> <https://github.com/canonical/operator/issues/310> <Chipaca> and now bed <mup> Issue operator#316 opened: unit state lost following upgrade-charm <Created by jetpackdanger> <https://github.com/canonical/operator/issues/316> #smooth-operator 2020-06-02 <mup> Issue operator#317 opened: use charm state for Juju 2.8 <Created by jetpackdanger> <https://github.com/canonical/operator/issues/317> <Chipaca> morning all <jam> morning Chipaca <facubatista> Muy buenos dÃ­as a todos! <Chipaca> a wild facundo appears! * facubatista puts some clothes on <Chipaca> better <Chipaca> facubatista: hola :) <facubatista> hola :) <Chipaca> i've just realised i spent all morning messing around with versioning :-( <facubatista> Chipaca, and this is the 3.1.2nd time it happes to you! <facubatista> *happens <Chipaca> well, i did do a bit of reviewing and such before diving down this rabbithole <facubatista> Chipaca, but at least you have a conclusion? <Chipaca> facubatista: I have something I like, I just need to check one more thing <Chipaca> hm, the files github gives us at https://github.com/canonical/operator/releases is already reasonably useless :-/ do we care about them? <facubatista> Chipaca, for `fades`, the person doing the debian packaging takes those <facubatista> Chipaca, anyway, I don't care about them, not even to take the action of removing them or something <Chipaca> heh <facubatista> Chipaca, re MANIFEST.in... "LICENSE": don't we need to package it? why do we have it in the first place? shall we remove it from the project? <Chipaca> facubatista: in the wheel, it's already there <Chipaca> facubatista: in the source dist, we reference it by name, isn't that enough? <Chipaca> i'm asking :) <facubatista> Chipaca, who put it in the wheel? <Chipaca> facubatista: wheel :) <Chipaca> facubatista: FWIW I don't object to it being there <facubatista> Chipaca, even if we don't specify to put it in the tarball? <Chipaca> facubatista: correct <facubatista> wow <Chipaca> facubatista: you can try it yourself :) <facubatista> nah, I trust you <Chipaca> facubatista: 'python setup.py bdist_wheel' <Chipaca> shaaame <Chipaca> oh dang lunch * Chipaca rushes <Chipaca> so, it *looks* like github doesn't auto-add assets if you add them manually, so that might be a good way out <facubatista> Chipaca, what we do about LICENSE file, then? <Chipaca> facubatista: give me a bit <Chipaca> just digging into that :) <Chipaca> bah. i should probably shelve the version stuff first :-D <facubatista> ack, no rush <Chipaca> facubatista: so one approach is to add a setup.cfg with [metadata] license_file = LICENSE.txt <Chipaca> license_files* <facubatista> Chipaca, jam, now I pushed the files to where they belong, so I won't confuse again my directories: https://github.com/facundobatista/blog/tree/master/charm <Chipaca> i don't have a stick big enough to shake at how much i dislike the under-documentedness of setup.py and .cfg <jam> Chipaca, simple enough :) <Chipaca> grmbl <Chipaca> (tm) <facubatista> Chipaca, see, I created a clean venv, then `pip install -r requirements-dev.txt`, and I get: <facubatista> Installing collected packages: pycodestyle, toml, autopep8, mccabe, zipp, importlib-metadata, pyflakes, flake8, PyYAML, ops <facubatista> I don't like that "ops" at the end <facubatista> oh, mmm <facubatista> $ cat env/lib/python3.6/site-packages/ops.egg-link <facubatista> /home/facundo/canonical/operator <facubatista> probably not harmful, though <Chipaca> yep, it's done a 'develop' * Chipaca links to https://xkcd.com/1987/ on the README.md <jam> Chipaca, :) <jam> danger of using 'sudo' to install python packages, indeed <mup> PR operator#318 opened: Simplified the CharmBase init signature <Created by facundobatista> <https://github.com/canonical/operator/pull/318> <facubatista> never ever do "sudo pip" <jam> facubatista, do "curl | sudo bash" right? <facubatista> ja <facubatista> oh, Trello is down :/ <Chipaca> facubatista: if trello is down, are you even working <facubatista> Chipaca, I'm not doing anything but pressing F5 every couple of minutes, staring at the empty browser page <Chipaca> facubatista: let's have our 1:1 now then :) <facubatista> je <facubatista> Chipaca, bah, I'm ok for the 1:1 now if you prefer it <Chipaca> facubatista: let's do it <facubatista> ok, 1' <facubatista> Chipaca, omw <Chipaca> soft EOD from me. brain = ded <Chipaca> migt bbl if it reactivates <facubatista> Chipaca, should we distribute ops docs inside its package? * facundo__ eods * Chipaca eods #smooth-operator 2020-06-03 <jam> morning all <mup> PR operator#319 opened: ops: get version from git <Created by chipaca> <https://github.com/canonical/operator/pull/319> <mup> Issue operator#313 closed: If ops is installed, the test run picks up the wrong one <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/313> <mup> PR operator#314 closed: test_main: set up PYTHONPATH so the sub-process picks up this ops <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/314> <jam> morning Chipaca <Chipaca> jam: moin moin :) <jam> Chipaca, I'd like to chat a bit about serialization of StoredState, we can start on IRC and move from there if you feel it is too involved <Chipaca> jam: sure <jam> Chipaca, so I'm pretty sure you're aware that we currently use a pickle into a sqlite database for all StoredState content <Chipaca> yep <jam> Juju will accept key=value pairs for 'state-set/get' and can take that 'state-set' as 'key=value' on the CLI or as YAML key:value from --file (which can be '-' for stdin) <jam> The current spike was done by putting the pickle bytes into base64 and then writing that as the value <Chipaca> mhmm <jam> it is a pretty obtuse way to understand what your state is, if you ever wanted to do "juju run --unit u/0 state-get" <jam> foo: gANLCi4= <jam> I have some concerns about pickle support, though AIUI since we force it to be simple types with a pass by Marshal <jam> there shouldn't be too much trouble if you wrote a pickle with python 3.7 and read it with python 3.8 <jam> (say you did a do-release-upgrade on the machine that was running the charm, and it is now running a different version of python) <Chipaca> pickle's fine with that, yes <jam> Chipaca, it doesn't *feel* like a 'stable format to keep your state in over time" <Chipaca> eh, it's stable enough (you can use 3.8 to load a pickle from 2.2 for example) <Chipaca> but <Chipaca> it's not very approachable <Chipaca> and that might be a bigger issue :) <Chipaca> jam: given that they're simple types, wouldn't yaml also work for us? <jam> Chipaca, so the one caveat is that yaml or json as the actual payload loses the type for set vs list <jam> Also, JSON keys are strictly strings IIRC, so you can't have {0: 'foo'} <jam> I think YAML supports non-string keys <Chipaca> are yaml keys also -- ah <Chipaca> hmm <Chipaca> jam: and python? <jam> Python has the nice behavior that json.dumps({0: 'foo'}) => '{"0": "foo"}' <jam> iow, it silently casts your numeric keys into string keys <Chipaca> no i mean, make it a python literal <Chipaca> and use ast.literal_eval to bring it back <jam> $ python3 -c "import json; print(json.dumps({'0': 'foo', 0: 'bar'}))" <jam> {"0": "foo", "0": "bar"} <jam> Chipaca, what is the cleanest way to turn a nested dict into a literal? just repr() ? <Chipaca> yep <Chipaca> bah, dicts you can str because repr is str there :) but yes, repr <jam> Chipaca, and... there isn't much in the way of versioning, so we have a way to change our mind about how we want to store the content. <Chipaca> s/have/don't have/ ? <Chipaca> we could add that ourselves, make the first byte of the value be the version? <Chipaca> does juju care at all what we dump in there? what further processing does it do on it? <jam> >>> repr({'0': [1,2,3], 0: set(['a', 'b', 'c'])}) <jam> "{'0': [1, 2, 3], 0: {'b', 'c', 'a'}}" <jam> >>> ast.literal_eval("{'0': [1, 2, 3], 0: {'b', 'c', 'a'}}") <jam> {'0': [1, 2, 3], 0: {'b', 'c', 'a'}} <jam> Chipaca, so Juju *should* just round trip the content we give it. <Chipaca> yeah, sets have literals too ;) <jam> Chipaca, yeah, I always use set() because the empty set doesn't have another literal <Chipaca> ah, yeah <jam> since {} would be ambiguous. I'm also not a huge fan of "did you notice there were no :" <Chipaca> and it might fail here :-/ <Chipaca> because 'set()' isn't a literal <jam> >>> ast.literal_eval(repr({'0': [1,2,3], 0: set()})) <jam> Traceback (most recent call last): <jam> File "<stdin>", line 1, in <module> <jam> File "/usr/lib/python3.6/ast.py", line 85, in literal_eval <jam> return _convert(node_or_string) <jam> File "/usr/lib/python3.6/ast.py", line 66, in _convert <jam> in zip(node.keys, node.values)) <jam> File "/usr/lib/python3.6/ast.py", line 65, in <genexpr> <jam> return dict((_convert(k), _convert(v)) for k, v <jam> File "/usr/lib/python3.6/ast.py", line 84, in _convert <jam> raise ValueError('malformed node or string: ' + repr(node)) <jam> ValueError: malformed node or string: <_ast.Call object at 0x7f2b34d35160> <jam> Chipaca, indeed, it does fail :9 <jam> :( <Chipaca> so close <jam> it is also true that we are running pickle.loads() on unknown data <jam> yes we write it from things that are 'safe', but we are still running the engine on data that we're reading back from 'outside' <jam> Chipaca, code layering wise, it is also quite hard to not use pickle, because Framework is the part that decides pickle, while Storage decides to write it to the DB <Chipaca> yeah <jam> (Framework.save_snapshot is where the marshal.dumps check and pickle.dumps is done) <Chipaca> i think that could use a refactor, but separately <jam> Chipaca, though again, we can just move that down into the SQLiteSnapshot layer <jam> SQLiteStorage <jam> Chipaca, indeed. snapshot() from the actual objects that people implement is still defined as a dict so we're ok there <Chipaca> jam: do we care about the spike being forwards-compatible? <Chipaca> i guess we do but just checking :) <jam> Chipaca, as in that the current version of the code can read the content written by future versions? <Chipaca> as in the state written by the spike be readable by future versions <jam> or if it can't read it, fail gracefully <jam> Chipaca, we don't care about the current spike, because it was just to show proof-of-concept. no charms that I'm aware of are using it. <Chipaca> jam: ah so the spike isn't what we'd put in 0.7 <jam> Chipaca, correct. I'm using it as a starting point, but taking the time to carefully structure things and make sure it is the serialization that we're happy with. <Chipaca> ok <jam> I'd really rather use something like json/yaml and have it be inspectable by humans. <Chipaca> so for the initial spike, pickle is fine then :) <jam> I think you missed a comment by Stub that people are writing sqlite3 hacks to unpickle the snapshot fields to try to figure out what is going on. <Chipaca> i've seen that in bugs and etc, yes <Chipaca> which seems obvious to me -- if i were trying to figure out what was going wrong, i'd want to look at anything i could too <jam> Chipaca, and we can write a common helper to make it easier to inspect that state <jam> Chipaca, but ideally it would be less opaque to start with. <jam> Could we make the statement "sets aren't allowed" and just go with JSON ? <Chipaca> json also mangles numbers <jam> ah right <jam> yeah, I hate that part. <Chipaca> so it's my least favourite for this :) <jam> if it *failed* I might be ok with it. <jam> the fact that it silently corrupts makes it out <jam> see my above comment where you can json.dumps() and get the integer and string keys colliding with no error. <Chipaca> we can come up with special handling for empty sets and work with that, also <stub> I'd actually assumed sets were not allowed by 'simple types only', like json and yaml and toml and everything else people are used to now days. <davigar15> Hello! <davigar15> ERROR juju.worker.uniter.operation hook "start" (via explicit, bespoke hook script) failed: exit status 1 <stub> Recommend feeding the CLI tool using the --yaml argument to avoid CLI command length limitations and encoding and locale issues <davigar15> I'm getting that error in k8s charms in 2.8.1 <davigar15> Chipaca: any ideas? <Chipaca> davigar15: what operator version? <davigar15> latest <Chipaca> davigar15: can we see the debug logs? <davigar15> yes <jam> stub, yeah, --file is currently the way that I'm interacting with state-set. <jam> davi <jam> davigar15, I'd start with "juju model-config logging-config=DEBUG" and "juju debug-log" to get more information about what is going wrong. <stub> jam: Maybe this time we can use = and . in our keys :) <Chipaca> we _could_ restrict what you can put in state even further, for this feature <Chipaca> or, we could special-handle empty sets :) <Chipaca> (or sets in general!) <davigar15> oooh, good trick. Need to debug it :-) <Chipaca> jam: yaml.safe_load(yaml.dump(set())) <Chipaca> jam: â set() <Chipaca> yaml.safe_load(yaml.dump({'0': [1,2,3], 0: set(['a', 'b', 'c'])})) â {0: {'a', 'b', 'c'}, '0': [1, 2, 3]} <Chipaca> we'd have to check if the !!set annotations require a particular pyyaml version <davigar15> application-zookeeper-k8s: 10:52:25 DEBUG unit.zookeeper-k8s/2.start raise TypeError( <davigar15> application-zookeeper-k8s: 10:52:25 DEBUG unit.zookeeper-k8s/2.start TypeError: observer methods must now be explicitly provided; please replace observe(self.on.config_changed, self) with e.g. observe(self.on.config_changed, self._on_config_changed) <davigar15> There is it <davigar15> It has to be explicit. I have self instead <davigar15> :-) <davigar15> thanks <Chipaca> jam: but it works in 3.11 (xenial) and 3.12 (bionic) at least <jam> Chipaca, ^^ that looks like the "catch exceptions and log at higher than DEBUG" :) <Chipaca> davigar15: :) sorry we broke your charm, glad we were trying to tell you about it at least :) <Chipaca> jam: yep <Chipaca> did we have an issue for that? i should do that one next <jam> we do <davigar15> It's okay! nothing in production yet hahaha <jam> Chipaca, #289 <mup> Issue #289: hook exception logged at DEBUG <Created by jetpackdanger> <https://github.com/canonical/operator/issues/289> <Chipaca> perfect <Chipaca> jam: any reason not to go the yaml route (after the refactor to move sqlite decision out of framework) ? <jam> Chipaca, so I've been told historically that YAML is good if a human is going to edit it, but it has enough edge cases it doesn't make a great machine<=>machine format. <stub> I think you will need to keep sqlite if you want Juju 2.7 compatibility <jam> (things like base 60 numbers) <jam> stub, yes, it isn't removing sqlite <jam> it is adding an alternative when it is available <Chipaca> yeah i bungled and meant 'pickle' there <jam> but what do we want *that* to look like <Chipaca> framework is pickoing, storage is sqliting <Chipaca> pickling * Chipaca used to be able to type <jam> Chipaca, I think I'll want to keep the marshal() check, but move the pickling into Storage and out of JujuStorage and try using YAML there. <jam> Chipaca, it kind of has to happen at the same time, since the interface to the Storage changes from taking a bytes to taking a dict <jam> but it shouldn't be very invasive. <Chipaca> jam: so what _is_ a good machine â machine format? <stub> With the marshal check, the yaml should always be bog simple except for sets (and maybe other builtin Python types I can't think of right now), and seems fine to me as machine <-> machine <jam> well, the recommendation was JSON, but for obvious reasons that is out. I don't think pickle/python ast fall into that category. XML is overbroad <jam> stub, Chipaca certainly YAML is my top pick right now <Chipaca> base64 of a pickled xml ast dump \o/ * Chipaca hides <stub> eval(repr(blob)) <Chipaca> exec* <Chipaca> ]:-) <Chipaca> wait is exec eval now * Chipaca checks <Chipaca> nope exec is still the right one for maximum pawnage <Chipaca> anyway, sorry for the silliness :) * Chipaca is only a little bit sorry <Chipaca> hush you <jam> Chipaca, if only there was some way to get "sudo" in there <Chipaca> jam: charms run as root Â¯\_(ã)_/Â¯ <jam> Chipaca, so one nice property is that refactoring is actually quite localized <jam> Chipaca, what is the type annotation for "snapshot". Currently we only really ever use 'dict' or None, but it has so far been anything that python can pickle <jam> is that just "object" ? <Chipaca> jam: Any ? <Chipaca> it's not strictly Any, but I don't think there's something better <Chipaca> OTOH maybe we should enforce it being dict-or-None <Chipaca> anything else isn't going to be extensible enough for long-term <davigar15> Chipaca: Why could my charm be in wating for container, without giving any errors? <Chipaca> 'waiting for container' sounds like a juju thing to me :) <Chipaca> ie not yet the charm <Chipaca> jam: OTOH you *could* spell it all out <Chipaca> as in, Union[int, float, â¦ ] <jam> Chipaca, so we do have tests that snapshot() -> str and 'def snapshot(self): return self.value' where value was passed in to .emit(value) <jam> (where in the test value is only ever a string) <Chipaca> and it's probably overly opinionated for a framework :) <Chipaca> i mean the 'always use a dict' thing <jam> Chipaca, well, dict or None would be acceptable IMO, and we are little if not opinionated :) <jam> Chipaca, if our review of people's code would always be "you really should use a dict" then we should push that a bit harder, I think. <mup> PR operator#320 opened: ops/framework.py: Move pickle into Storage <Created by jameinel> <https://github.com/canonical/operator/pull/320> <davigar15> Chipaca: happening with juju stable version... I'm going to check my charm. <davigar15> Can't see anything wrong... https://pastebin.canonical.com/p/BMqcdkT6fN/ <Chipaca> davigar15: what does the debug log say <davigar15> juju model-config logging-config=DEBUG <davigar15> ERROR config value expected '=', found "DEBUG" <davigar15> haha <jam> that exact line worked here <jam> you could also do: juju model-config "logging-config=<root>=DEBUG" <jam> which is the more explicit version <jam> (that allows you to specify each module separately) <jam> davigar15, though your particular statement "waiting for container", I believe, is created by Juju <jam> (if a charm sets a pod spec, and otherwise goes into Active, Juju sets the state to 'waiting for container' until the pod has started) <jam> davigar15, https://discourse.juju.is/t/how-to-avoid-the-waiting-for-container-message/1369/3 might help? <jam> specifically https://discourse.juju.is/t/how-to-avoid-the-waiting-for-container-message/1369/6 <davigar15> https://pastebin.canonical.com/p/CxPhPygZb4/ <davigar15> $ microk8s.kubectl -n zk get pods <davigar15> NAME READY STATUS RESTARTS AGE <davigar15> modeloperator-658686f765-cfsr6 1/1 Running 0 2m59s <davigar15> zookeeper-k8s-operator-0 1/1 Running 0 2m11s <davigar15> But the application pods are not even created <jam> davigar15, so offhand your charm seems to be missing a self.state.set_default(spec=None) as on_config_changed introspects self.state.spec directly <davigar15> create Pod zookeeper-k8s-0 in StatefulSet zookeeper-k8s failed error: Pod "zookeeper-k8s-0" is invalid: spec.containers[0].ports[2].name: Invalid value: "leader-election-port": must be no more than 15 characters <davigar15> found <davigar15> haha <jam> (I don't think this the problem here, as it means hitting config_changed without start, which will happen with 2.8) <jam> davigar15, where did you find that? I don't see it in your pastebin <Chipaca> it's one of those no-rest-for-the-wicked days <Chipaca> taking a breka now and getting the lunch sorted because then i'll be eating in meetings <facubatista> Muy buenos dÃ­as a todos! <davigar15> Chipaca: how can I get the number of ensured units with the op framework <jam> davigar15, is that len(self.get_relation(PEER_RELATION).units) <jam> or do you need the count before they are actually started? <davigar15> good question <davigar15> I think I need it before <jam> https://github.com/canonical/operator/issues/165 is about possibly having the framework expose the count (reading it from goal-state), but that hasn't been implemented, so understanding your use case/adding it to that issue is useful <jam> davigar15, ^^ <Chipaca> facubatista: https://github.com/canonical/operator/releases/tag/0.6.0 <facubatista> Chipaca, wonderful <Chipaca> facundo__: note #294 is gtg <mup> PR #294: Log when a served breakpoint is not really activated because of name mismatch <Created by facundobatista> <https://github.com/canonical/operator/pull/294> <facundo__> Chipaca, ack * facundo__ will restart the router to see if all these disconnections stop <jam> Chipaca, and for issue #21, if it is a script, and we set JUJU_DISPATCH_PATH it will try to reinvoke hooks/install but that will notice the OPERATOR_DISPATCH env and exit early, right? <mup> PR #21: Persist stored state before framework commit <Created by dshcherb> <Merged by niemeyer> <https://github.com/canonical/operator/pull/21> <Chipaca> jam: indeed <Chipaca> charmcraft#21, mup m'dear <mup> Issue charmcraft#21: Event charm.py not defined <Created by knkski> <https://github.com/canonical/charmcraft/issues/21> <Chipaca> facundo__: want me to fix this ^? i can do that right now <facundo__> Chipaca, be my guest <jam> Chipaca, btw, if you want easier ways to get to source code from a git submodule you can open the '.gitmodules' file which contains the URL that git will use to find the revision <jam> https://git.launchpad.net/charm-k8s-mattermost/tree/.gitmodules <Chipaca> jam: ð <jam> github does that for you, eg if you look at this: https://github.com/jameinel/ubuntu-lite/pull/2/files#diff-b1d90847e9ac9d08a6205ad8f09fd5a9L14 it has a direct link to the Operator code <mup> PR jameinel/ubuntu-lite#2: Operator <Created by jameinel> <https://github.com/jameinel/ubuntu-lite/pull/2> <jam> or https://github.com/jameinel/ubuntu-lite/tree/operator/mod if you are browsing the Tree rather than the PR <jam> Chipaca, while sending the mattermost email, I realized we also really need to review https://github.com/johnsca/resource-oci-image/blob/master/oci_image.py <jam> since that is as common to be reused as k8s.py <Chipaca> ah <Chipaca> jam: ok <Chipaca> closed charmcraft#18, charmcraft#19 and charmcraft#20. I hope I was able to explain why clearly enough for the reporter not to hate us too much :-| <mup> Issue charmcraft#18: Poetry integration <Created by knkski> <Closed by chipaca> <https://github.com/canonical/charmcraft/issues/18> <mup> Issue charmcraft#19: Pep 518 support for charm metadata <Created by knkski> <Closed by chipaca> <https://github.com/canonical/charmcraft/issues/19> <mup> Issue charmcraft#20: Support pep 517 for building charms <Created by knkski> <Closed by chipaca> <https://github.com/canonical/charmcraft/issues/20> <mup> PR operator#321 opened: have a Code of Conduct <Created by chipaca> <https://github.com/canonical/operator/pull/321> <Chipaca> facubatista, jam, reviews on #23 would mean we could ship it today <mup> PR #23: Add leadership to model <Created by johnsca> <Closed by johnsca> <https://github.com/canonical/operator/pull/23> <Chipaca> charmcraft#23 <mup> PR charmcraft#23: build: set JUJU_DISPATCH_PATH so we get the right hook <Created by chipaca> <https://github.com/canonical/charmcraft/pull/23> <facubatista> Chipaca, ack <mup> Issue operator#220 closed: Log in WARNING when a breakpoint is not served in debug mode <Created by facundobatista> <Closed by chipaca> <https://github.com/canonical/operator/issues/220> <mup> PR operator#294 closed: Log when a served breakpoint is not really activated because of name mismatch <Created by facundobatista> <Merged by chipaca> <https://github.com/canonical/operator/pull/294> <mup> Issue operator#262 closed: Harness should support resource-get <Created by jameinel> <Closed by chipaca> <https://github.com/canonical/operator/issues/262> <mup> PR operator#296 closed: Oci resources <Created by chris-sanders> <Merged by chipaca> <https://github.com/canonical/operator/pull/296> <facubatista> Chipaca, would you mind to explain what magic are you doing in charmcraft#23? <mup> PR charmcraft#23: build: set JUJU_DISPATCH_PATH so we get the right hook <Created by chipaca> <https://github.com/canonical/charmcraft/pull/23> <Chipaca> facubatista: i see no magic :-/ <Chipaca> facubatista: the {{}} is because I need actual {s in the output <Chipaca> facubatista: WRT ${parameter:-word} Use Default Values. If parameter is unset or null, the expansion of word is substituted; otherwise, the value of parameter is substituted. <Chipaca> so ${JUJU_DISPATCH_PATH:-$0} is "either JUJU_DISPATCH_PATH or, if that is unset or null, $0" <facubatista> Chipaca, fantastic, thanks!!! <facubatista> Chipaca, mind to put a comment saying something like "if Juju don't support the dispatch mechanism, it will execute the hook, and we need sys.argv[0] to be the name of the hook, so we fake JUJU_DISPATCH_PATH to be that value"? <facubatista> Chipaca, thanks! <Chipaca> will do <facubatista> Chipaca, approved * facubatista -> lunch <Chipaca> hmmmmmm * facubatista is back * Chipaca hmms <Chipaca> dunno if my lxd is stuck, or just my juju <Chipaca> facubatista: do you have a working thing you could juju ssh into to try something with juju-log? <facubatista> Chipaca, yes, but on a meeting right now <Chipaca> ah <Chipaca> k * facubatista brb <Chipaca> ok i think i'm off * Chipaca EODs * facubatista is back * facubatista eods #smooth-operator 2020-06-04 <jam> morning all <MarkMaglana> jam: wazaaaaaaap <MarkMaglana> we're in the middle of the WTF part of the week! hang in there! <MarkMaglana> Well, technically the WThF part of the week but every keystroke counts. <jam> :) <Chipaca> moin moin <Chipaca> jam: any chance of a review of charmcraft#23 so we can put out a fix? <mup> PR charmcraft#23: build: set JUJU_DISPATCH_PATH so we get the right hook <Created by chipaca> <https://github.com/canonical/charmcraft/pull/23> <jam> Chipaca, to make sure I understand the bash magic, "JUJU_DISPATH_PATH=${{JUJU_DISPATCH_PATH:-$0}}" sets the env var to argv[0] if it isn't set, and then double {{ is because it is in a python format template, right? <jam> Chipaca, Approve as long as I understand that correctly <Chipaca> jam: yep, that's all correct * Chipaca resurrecting a borked juju <Chipaca> jam: charmcraft#25 could use a rubber stamp <mup> PR charmcraft#25: bump version for 0.1.1 <Created by chipaca> <https://github.com/canonical/charmcraft/pull/25> <jam> stamped <Chipaca> thanks <Chipaca> i'll land that with just that +1 and release it into the wild <Chipaca> siiiigh <Chipaca> 0.1.1 bites me again <Chipaca> jam: same for charmcraft#26 :-( <mup> PR charmcraft#26: bump version for 0.1.2 <Created by chipaca> <https://github.com/canonical/charmcraft/pull/26> <jam> Chipaca, I refuse. too much stamping... :) <Chipaca> fair <jam> done <Chipaca> thanks * ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.6.1 || charmcraft 0.1.2 <mup> PR operator#322 opened: log: set up sys.excepthook to log exceptions <Created by chipaca> <https://github.com/canonical/operator/pull/322> <jam> Chipaca, do you have a preference for new dates at the start/end of the doc? I actually prefer the newest to be the beginning of the doc, but I know you found it confusing w Tom <Chipaca> jam: I prefer if we choose one and stick to it. I don't mind which :) <Chipaca> inserting it from the top works for me (it's what we do in the standup doc for ex) <Chipaca> jam: i'm not sure why i got confused yesterday <Chipaca> i've got my suspicions though :) <jam> Chipaca, one thing that I find helps a lot is to put a Page Break between sections, as it makes it less 'run on' <Chipaca> sgtm <Facu> Muy buenos dÃ­as a todos! <jam> morning Facu <jam> Chipaca, so i've run into something interesting with YAML. <jam> namely "yaml.dump({'a': (1,2)})" writes the document as "a: !!python/tuple [1,2]" <jam> which round-trips if you then call 'yaml.load' <jam> but *not* if you call yaml.safe_load <jam> and, in fact, it fails with: <jam> yaml.constructor.ConstructorError: could not determine a constructor for the tag 'tag:yaml.org,2002:python/tuple' <jam> in "<byte string>", line 5, column 6: <jam> six: !!python/tuple [a, b] <Chipaca> hmm <Facu> weird <Chipaca> now i wonder what 'safe' brings to the party in this context <Facu> Chipaca, not running any code? <Chipaca> 'The function yaml.safe_load limits this ability to simple Python objects like integers or lists.' <Chipaca> â¦ but not tuples? <Chipaca> jam: so apparently the recommendation is to subclass the safe loader and add constructors for the non-standard bits we want <jam> Chipaca, yeah, that is what I was looking at doing <Chipaca> ok <jam> I think anything that is "!!python/" it doesn't allow by default, which is why I'll add it. <jam> I'm just a bit surprised that tuple isn't considered safe but "set" was <Chipaca> jam: apparently !!set is a standard yaml thing <Chipaca> which i didn't know :) <Chipaca> i mean, that's what https://pyyaml.org/wiki/PyYAMLDocumentation says <Chipaca> afaict the only thing there we need is tuple, and arguably complex <Chipaca> ah i guess none also <Chipaca> but that probable goes to null * Chipaca tries <Chipaca> yeah <jam> None => null by default, yeah. <jam> Chipaca, where do you see the bit about inheriting? The thing I see is "your types can add a property yaml_loader to SafeLoader" <jam> which I don't think I can do to tuple() <jam> oddly, they mention using safe_dump() to ensure you don't dump classes, etc. But 'safe_dump' still puts !!python/tuple which safe_load doesn't support <jam> ah, it actually doesn't. nm <jam> Chipaca, https://stackoverflow.com/questions/9169025/how-can-i-add-a-python-tuple-to-a-yaml-file-using-pyyaml <jam> PrettySafeLoader <Chipaca> jam: or https://stackoverflow.com/questions/33048540/pyyaml-safe-load-how-to-ignore-local-tags :) <Chipaca> sorry was afk directing lunch prep here <Chipaca> hehe <Chipaca> yaml.CSafeLoader.yaml_constructors['tag:yaml.org,2002:python/tuple'] = yaml.Loader.yaml_constructors['tag:yaml.org,2002:python/tuple'] <Chipaca> probably not the right thing :-D <Chipaca> but otoh can't see why not <Chipaca> also note set(yaml.Dumper.yaml_representers) - set(yaml.SafeDumper.yaml_representers) <Chipaca> but, yaml.SafeDumper.yaml_representers[tuple] is represent_list <Facu> Chipaca, jam, where are we yaml-dumping tuples? <Chipaca> Facu: looking at replacing base64+pickle with something more human-friendly <Chipaca> Facu: for the fix to #317 <mup> Issue #317: use charm state for Juju 2.8 <Created by jetpackdanger> <https://github.com/canonical/operator/issues/317> <Facu> Chipaca, WAT, you can not read pickle? :p <Chipaca> Facu: obvs i can, but we have human users also <Facu> Chipaca, humans! always complicating stuff <Chipaca> ikr <jam> Chipaca, Facu also if we're happy with pickle we could just 'load()' but I'd like to be safer than raw pickle <Chipaca> jam: it's fine, the brine keeps things safe <Facu> TOML? * Facu hides * Chipaca writes a CHIPACAL spec <Chipaca> CHIPACL? <Chipaca> CHIPL <Chipaca> CHIL' * Chipaca stops <Facu> Chipaca, jam, what is a good message for the signature deprecation? <Chipaca> Facu: "LOL look at you, passing in 'key'! That's *so* last release!" * Chipaca suspects that would actually work <Facu> "CharmBase signature's second argument is deprecated, will be removed in 0.3.0, just use 'framework'" <jam> Facu, "key argument has been deprecated and will no longer be supplied in future versions" <Chipaca> 0.8 <Chipaca> not 0.3 <Chipaca> :) <Facu> I like the "future versions" and not be explicit, in case we want to delay the removal later <Chipaca> hm <Facu> jam, "key...", not "the key..."? <Chipaca> ok, 'after 0.7' <Facu> "the 'key' argument has been deprecated and will be removed after 0.7 version"? <jam> Facu, I like your "second argument" <Chipaca> might be a minute late, somebody's at the door <Facu> "the 'key' second argument has been deprecated and will be removed after 0.7 version"? <Chipaca> Facu: "the second argument, 'key', has been deprecated and will be removed after the 0.7 release" <jam> Chipaca, today's xkcd is pretty good: https://xkcd.com/2315/ <jam> heat-death of the universe guarantee's my database's eventual consistency * Facu brb * Chipaca pokes at the network again <mup> PR operator#323 opened: 317 state get <Created by jameinel> <https://github.com/canonical/operator/pull/323> * facubatista -> errands * facubatista is back <Chipaca> fiuuuuuu <Chipaca> talking with people <Chipaca> why do we even <Chipaca> jam, facubatista, both of you have +1'ed one, but not both, of the CoC PRs :-) <jam> Chipaca, we like to keep you guessing <Chipaca> jam: ooh, ooh, is it bigger than a breadbox? <Chipaca> is this breadbox container-sized? <Chipaca> or is it a breadbox as in the thing used for playing around with electronics <facubatista> Chipaca, will get to it in ~20' <mup> Issue operator#308 closed: have a code of conduct <Created by chipaca> <Closed by facundobatista> <https://github.com/canonical/operator/issues/308> <mup> PR operator#321 closed: have a Code of Conduct <Created by chipaca> <Merged by facundobatista> <https://github.com/canonical/operator/pull/321> <Chipaca> facubatista: suddenly feeling the urge to make 'python3 -m ops src/charm.py MyCharm' work, for some reason <facubatista> Chipaca, what for? ops is a lib, not an utility <facubatista> making it "half utility" will bring a lot of little rough corners <Chipaca> facubatista: because if all 'if __name__ == "__main__"' bits of charms look the same, why have them? <Chipaca> facubatista: I'm not going to be acting on this urge FWIW :) at least not this time <facubatista> Chipaca, oh, which reminds me! I wanted to talk about CharmBase init, let's talk on Monday about that <Chipaca> facubatista: is that the same as charmcraft init * Chipaca hids * Chipaca hides, also <facubatista> no, no * facubatista laves suspense grow <facubatista> *lets * Chipaca makes 'charmcraft innit' be an alias * Chipaca EODs <Chipaca> well, mostly <davigar15> https://pastebin.canonical.com/p/nzmgGT7bMS/ <davigar15> I'm getting that error in a relation <davigar15> Any ideas? <davigar15> That's the function is falling in: https://pastebin.canonical.com/p/Q6RCDf4pcK/ <davigar15> In the relation-set hook, I suppose <davigar15> app_data = self._relation.data[self.model.app] <davigar15> app_data['port'] = str(port) <davigar15> But I think that's correct ^ <facubatista> davigar15, let me see <facubatista> uh, juju is crashing <facubatista> davigar15, please print (with repr()) the values for port, rest_port and host <davigar15> application-zk3: 20:00:19 INFO unit.zk3/0.juju-log zookeeper:7: IPv4Address('(864)930-0890') <davigar15> There you go. IPv4Address <davigar15> maybe str(host) right? <Facu> ah, you're doing a str() of it <davigar15> nope, not in the host <Facu> davigar15, that IPv4Address is "host"? <davigar15> only in the ports <davigar15> yes <Facu> right, that will not travel through the relation <davigar15> Juju was telling me that values must be strings, not integers <Facu> jam, Chipaca, I wonder if we should detect this ^ *before reaching Juju* <davigar15> so I put str in ports <davigar15> If I put a number it tells you exactly what's the problem <Facu> jam, please when you're back check if you find why juju is crashing on davigar15, thanks! <jam> davigar15, I don't know the immediate reason why, can you give the Juju version you're running? <jam> nil-pointer panic is definitely a Juju bug <jam> there may be other things that could go wrong, but we should never panic <jam> davigar15, please add details to: https://bugs.launchpad.net/juju/+bug/1882127 <Facu> jam, I told him to run the commands by hand (after the proper `juju debug-hooks`) but it looks he can't because of k8s <Facu> jam, thanks for the help! <davigar15> 2.7.6 juju version <davigar15> Iâll give the details tomorrow <davigar15> Jam: you were fast!! I see you already updated the bug <Facu> jam, do we have a simple example on how to start with the Harness? <Facu> Chipaca, ^ <Chipaca> Facu: in the README? #smooth-operator 2020-06-05 <t0mb0> Hi, do operator pod resources support annotations? <t0mb0> I'm creating a custom ingress and I need to adjust request body size and send duration <t0mb0> this is how I expect it to work https://pastebin.canonical.com/p/48h4287TKn/ <jam> t0mb0, that is more of a #juju question. the operator framework just passes through the request to Juju. <jam> I know there are some discussions in the past like: https://discourse.juju.is/t/k8s-charms-annotations-charm-config-use-case/1489 <jam> I don't know the current state of it * Chipaca afk for a bit <facundo__> Muy buenos dÃ­as a todos! <Chipaca> facubatista: ð <facubatista> hola Chipaca <Chipaca> facubatista: how're you doing? <facubatista> Chipaca, tired, but not so demoralized with quarantine and all <Chipaca> facubatista: *hugs* <Chipaca> facubatista: take it easy today maybe? <Chipaca> facubatista: i was just reading you're getting another 21 days apparently :-( <facubatista> Chipaca, yeap <Chipaca> facubatista: no going outside for exercise even? <facubatista> Chipaca, I will write a lot today, which for me is quite interrupted by itself <Chipaca> facubatista: quite interrupted? <facubatista> Chipaca, I NEED go back to tennis, and I don't even want to start thinking when that could be possible <Chipaca> tennis is like socially-distancing ping pong <Chipaca> as long as it's outdoor tennis, it should be back sooner than, say, rugby? <facubatista> Chipaca, I don't write texts in a steady constant mode, I tend to it by chunks of time <Chipaca> ah gotcha <facubatista> Chipaca, yes, tennis should be one of the firsts sports... but they depend of sports clubs to be open, so... <MarkMaglana> Chipaca: now what if you played against a tennis ball machine? Would that be like social-distancing ping pong: boss level? <Chipaca> just the one machine? psh. that's for amateurs <MarkMaglana> oh, like two ball machine's against each other???! <Chipaca> i meant two or three against you, but, sure <MarkMaglana> which oddly reminds me of those dueling useless machines <Chipaca> heh <MarkMaglana> https://youtu.be/UkgoSOSGrx4 <MarkMaglana> wimbledon fans will have to settle for that in the meantime <Chipaca> MarkMaglana: i've seen that but with lego <Chipaca> now i'll need to find it <MarkMaglana> Chipaca: OK here I go down the YouTube rabbit hole... <Chipaca> MarkMaglana: https://www.youtube.com/watch?v=g5y1pdPVDx8 <MarkMaglana> hang on. still working on the first one: https://youtu.be/6xCd55oSgO4 <Chipaca> :) <MarkMaglana> "Daaaaaaaaaaaaaaaaaaamn" (at his Lego pieces organizer) * Chipaca â luncheon <Chipaca> the eon of lunch * Chipaca approves <vgrevtsev> hi everyeone - a quick question, is there any docs re: dependency management in the framework (I heard it'll be called `ops.lib`, but not sure, pls correct me if I'm wrong) ? <Chipaca> vgrevtsev: what're you trying to do? <Chipaca> there is ops.lib but it does not do dependency management :) <vgrevtsev> Chipaca: I'm thinking about how can I share some parts of the charm code across the charms (like interfaces, for example) <Chipaca> vgrevtsev: then yes, you want to use ops.lib, probably <vgrevtsev> and I got an impression that ops.lib is for that <Chipaca> vgrevtsev: but, ops.lib does not get you the bits on disk, it doesn't manage the dependencies <vgrevtsev> ok, so what it does? <Chipaca> vgrevtsev: it's like a namespace package, but with API and author constraints <Chipaca> ie you can say "use the mysql interface version 1 from joe" <vgrevtsev> but, this interface has to be installed before I can tell the charm to use it <Chipaca> yes <vgrevtsev> so what's the difference then? e.g without ops.lib I can just do a submodule and pin the commit hash to get the exact version of the interface, for example <Chipaca> vgrevtsev: but you could have two versions of the same interface, a stable and a devel say, side by side and it'd do the right thing <Chipaca> vgrevtsev: for sure you could, and that would work <Chipaca> vgrevtsev: and in fact, if you start doing it like that, and then want to switch to ops.lib.use, it would be a one-line diff <Chipaca> (assuming the interface is opslib-enabled :) ) <vgrevtsev> Chipaca: alright... but how does the ops.lib know where should it look for the code/version it was asked for? <vgrevtsev> Chipaca: and what does "opslib-enabled" means? I'm going to write a few interfaces during the next week <vgrevtsev> will be good to know as much as possible before, not after :-P <Chipaca> vgrevtsev: i was hoping to work with MarkMaglana to opslib-enable his k8s interface <Chipaca> vgrevtsev: as the first one <Chipaca> vgrevtsev: but the code is in 0.6 already so you can use it if you want <MarkMaglana> Chipaca: let's git 'er done! <Chipaca> there's a doc, 1 sec <vgrevtsev> so we're back to my original question: is there any docs? :)) <vgrevtsev> Chipaca: ah I see, cool <Chipaca> vgrevtsev: not enough docs yet, no <vgrevtsev> :; <Chipaca> vgrevtsev: there's https://docs.google.com/document/d/1D-DA3vJRRaauNc2bAJqLTKtAMTTP6tdj5HmOz-rasJI/edit <Chipaca> which hopefully is enough :-) <Chipaca> MarkMaglana: yes let's :) <Chipaca> MarkMaglana: what's the most recent k8s.py you know of? <vgrevtsev> Chipaca: oh, it's useful, thanks <vgrevtsev> probably that is something I was looking for <MarkMaglana> Chipaca:
{'channel': 'smooth-operator', 'month': 6}