| === max__ is now known as Guest26373 | ||
| === narindergupta is now known as narinderguptamac | ||
| jam | morning all | 05:53 |
|---|---|---|
| niemeyer | Hello charmers | 07:54 |
| Chipaca | goood morning! | 08:04 |
| niemeyer | Chipaca: Hiya! | 08:12 |
| Chipaca | my laptop is back at being stuck at 800MHz :-( | 08:15 |
| Chipaca | might have to spend some time talking with tech support | 08:15 |
| niemeyer | Might be a safety mechanism so you're not going too fast | 08:15 |
| niemeyer | stub: Good question about the place to put the "lib".. once they go out, the idea is to have a module directory under ops.lib | 09:48 |
| niemeyer | stub: My original idea when we discussed was to have it under the charm itself, so that there would be a local "lib" namespace.. but there's an issue with that plan | 09:49 |
| niemeyer | We need to be able to have multiple charms of the same author using that same library, precisely so that it becomes easier to reuse and to move into ops.lib once it evolves enough | 09:49 |
| stub | And 'from lib import pgsql' would be importing lib/lib/pgsql/__init__.py ? | 09:54 |
| stub | I'm mostly interested in getting the namespace right at my end. | 09:54 |
| niemeyer | stub: Right, it was a good question.. my original idea was src/lib/pgsql, but that's not good enough | 09:57 |
| niemeyer | stub: lib/lib isn't great either | 09:57 |
| niemeyer | stub: Not naming spacing pgsql isn't good either, as the top-level namespace is busy and we'll often be implementing libraries to integrate existing things in charms | 09:58 |
| niemeyer | *namespacing | 09:58 |
| stub | Ideally without turning hooks/install into a mess of PYTHONPATH manipulation hacks | 10:01 |
| niemeyer | Yeah, we shouldn't need any further manipulation.. | 10:02 |
| niemeyer | We already have src for local, and lib for external, so we should be good | 10:02 |
| Chipaca | jam: you froze | 10:32 |
| Chipaca | or my network died | 10:32 |
| jam | Chipaca, its probably me | 10:33 |
| niemeyer | Lunch, biab | 11:05 |
| facubatista | Muy buenos días a todos! | 11:07 |
| jam | morning facubatista | 11:16 |
| facubatista | hola jam | 11:16 |
| Chipaca | whoops, laptop lost power while i was having lunch | 11:27 |
| jam | Chipaca, I was wondering where you went :) | 11:28 |
| * Chipaca heads for the hills | 11:28 | |
| facubatista | Chipaca, jam, we need to decide *how* we will support a dispatch entrypoint; this doc talks about it as "a new thing" but does not describes any migration: https://docs.google.com/document/d/1RHrOMbqsXz9qwk_3sHJ7AJOdlh-Mb-TkFUAtbXb37Og/edit#heading=h.df280vskamcl | 11:28 |
| facubatista | Chipaca, jam, so, what happens if both dispatch and classic hooks coexist? | 11:29 |
| jam | facubatista, yeah, I'm planning on adding a bit to that doc. I think it evolved and covers what Juju needed to do, but part of why that plan was ok was because of the plan for the framework. I'm working on that now. | 11:29 |
| jam | I think we had a good plan, just need to get it written down. | 11:29 |
| facubatista | jam, ack | 11:29 |
| facubatista | jam, please let me know when that's done, then, thanks! | 11:30 |
| facubatista | Chipaca, we need this ^ before continuing with #221, right? | 11:32 |
| mup_ | PR #221: osp, test: support dispatch <Created by chipaca> <https://github.com/canonical/operator/pull/221> | 11:32 |
| Chipaca | facubatista: yep | 11:33 |
| Chipaca | well, more or less :) | 11:33 |
| Chipaca | i already know the gist of it so i can move forward | 11:33 |
| Chipaca | but i've got plenty other things on my plate so i'll leave it be for now | 11:33 |
| jam | facubatista, is it worth talking about all the ways and why we chose not to do the alternatives, or just focus on the expected path? | 11:34 |
| facubatista | jam, it totally worths it, otherwise you may keep answering that to everybody who read the docs -- better to write it just once | 11:34 |
| jam | Chipaca, I just remembered one of the other concerns we should keep in mind. | 11:35 |
| jam | namely, hooks/install => src/charm.py for compatibility, but also dispatch => src/charm.py. We don't want dispatch getting called to cause install to get called and double-handle every event (or worse, infinitely recurse. :) | 11:36 |
| facubatista | jam, we can see that hooks/install is present *and not* a symlink to ourselves | 11:38 |
| facubatista | s/see/check/ | 11:38 |
| jam | facubatista, indeed. just something we need to remember to do | 11:38 |
| facubatista | jam, don't trust our memory! that's the kind of detail that should be written down | 11:39 |
| jam | yeah, I'll be adding it to the doc. | 11:39 |
| === mup__ is now known as mup_ | ||
| facubatista | juju deploys my charm in an unit; which directory should I work with, from the charm, to put "local files"? /var/lib? | 11:51 |
| facubatista | where is the best way to ask these questions? ^ | 11:51 |
| facubatista | s/way/place/ | 11:51 |
| jam | facubatista, local to the charm, local to the app? many people reuse $PWD (which is /var/lib/juju/agents/<unit-name>/charm) but that is usually considered non-ideal (it leads to dirty charm directories and upgrades/etc also touch that dire) | 11:52 |
| facubatista | jam, local to the app | 11:53 |
| facubatista | jam, I want to put a file there that will be served later | 11:53 |
| * facubatista tries to os.mkdir("/var/lib/mything") | 11:54 | |
| jam | facubatista, local to the app depends on the app itself, right? eg Apache likes '/www' | 11:54 |
| facubatista | jam, but my charm doesn't run in the same unit than apache, right? | 11:54 |
| facubatista | jam, I'm *exactly* blocked in that point | 11:54 |
| jam | facubatista, it depends how you deploy it. | 11:54 |
| facubatista | jam, do you know how to do it? | 11:55 |
| facubatista | this needs to be a subordinate charm somehow? | 11:55 |
| jam | facubatista, if you need to be on every unit of another app, the usual recommended way is to be a 'subordinate' | 11:55 |
| jam | exactly | 11:55 |
| jam | you can always have a bundle that colocates 2 different applications on the same machines, but if you're saying "I want to populate data for Apache to serve", that sounds like a subordinate. | 11:56 |
| jam | subordinates explicitly don't have their own 'number of units', they are strictly a 'place a unit of this everywhere you place a unit of that' | 11:56 |
| facubatista | mmmm... actually... let me see something else first | 11:56 |
| facubatista | jam, thanks! | 11:57 |
| facubatista | jam, Chipaca, niemeyer, meeting, https://meet.google.com/fqw-mdqc-dsf | 12:00 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | ok, need to reboot | 14:41 |
| niemeyer | Me too.. that is, *I* need to reboot, not the laptop | 14:54 |
| * facubatista -> lunch | 15:23 | |
| Chipaca | sneaking in for a bit while writing yet another usb image :-/ | 15:42 |
| * facubatista is back | 15:59 | |
| * Chipaca booted into windows, was terrified, and ran away | 15:59 | |
| facubatista | Chipaca, are you ok for the meeting, or shall we pospone it? | 15:59 |
| Chipaca | facubatista: i'll be there in 15 seconds | 16:00 |
| Chipaca | came back for it | 16:00 |
| niemeyer | Module namespaces are not my friends | 16:01 |
| niemeyer | At least not as I was trying it out | 16:01 |
| niemeyer | Can't get ops.beta to be a namespace while we have content in ops | 16:02 |
| Chipaca | ok, off to do the Lesser Scary Thing | 16:27 |
| niemeyer | # XXX Is this the right thing for subpackages like zope.app? | 16:44 |
| niemeyer | Not a great comment to find in the implementation of namespaces.. :) | 16:44 |
| facubatista | jejeje | 17:11 |
| niemeyer | Okay, got something that starts to look promising... | 17:35 |
| mup_ | Issue # closed: operator#98, operator#113, operator#122, operator#123, operator#156, operator#158, operator#161, operator#165, operator#166, operator#169, operator#171, operator#172, operator#174, operator#175, operator#178, operator#179, operator#180, operator#185, operator#186, operator#187, | 17:36 |
| mup_ | operator#188, operator#189, operator#198, operator#205, operator#206, operator#208, operator#211, operator#214, operator#215, operator#219, operator#220, operator#222, operator#223 | 17:36 |
| mup_ | PR # closed: operator#190, operator#196, operator#203, operator#212, operator#218, operator#221 | 17:36 |
| mup_ | Issue # opened: operator#98, operator#113, operator#122, operator#123, operator#156, operator#158, operator#161, operator#165, operator#166, operator#169, operator#171, operator#172, operator#174, operator#175, operator#178, operator#179, operator#180, operator#185, operator#186, operator#187, | 17:37 |
| mup_ | operator#188, operator#189, operator#198, operator#205, operator#206, operator#208, operator#211, operator#214, operator#215, operator#219, operator#220, operator#222, operator#223 | 17:37 |
| mup_ | PR # opened: operator#190, operator#196, operator#203, operator#212, operator#218, operator#221 | 17:37 |
| niemeyer | Hmm.. mup seems to be taking a network error as a valid document | 17:37 |
| niemeyer | Need to look into it | 17:37 |
| niemeyer | facubatista: When you have a moment, would like to have a quick chat about this: | 17:38 |
| niemeyer | https://paste.ubuntu.com/p/cHP2gq5MkK/ | 17:38 |
| facubatista | niemeyer, I was about to get a cup of tea; let's do it in 10'? | 17:39 |
| niemeyer | +1 | 17:39 |
| niemeyer | I mean.. yes, 10' :) | 17:39 |
| facubatista | ok, in 11' :p | 17:39 |
| facubatista | yes, jajaaj | 17:39 |
| facubatista | niemeyer, https://meet.google.com/veq-yfqm-kdk ? | 17:46 |
| niemeyer | facubatista: omw | 17:48 |
| * facubatista eods | 20:48 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!