[10:12] Morning Chipac. After purging juju, rebooting system, snap installing and then bootstrapping, I have juju running again. Oddly enough despite this juju refuses to create a controller with the same name as that before the purge . Even though juju and charms now work. I still see no logging. I am going to bring this to the attention of jam when he is back. There are two issues 1) logging not working 2) juju snap persisting inform [10:12] despite remove with --purge option. [10:12] PR #1: Fix stop event attribute [10:15] bthomas: did you try also removing microk8s? because AIUI it's something 'stuck' on the k8s side [10:17] Chipaca: thanks will try removing k8s too [10:20] bthomas: don't forget the --purge otherwise it'll take ages to remove as it makes a backup of the data [10:20] thanks [10:34] ¡Muy buenos días a todos! [10:34] facubatista: la pucha que madrugás che [10:34] Chipaca, :) [11:12] Hi everyone, [11:12] I have a few questions: [11:12] Alan21: hi! [11:12] 1. Is the operator framework ready to use in production ? Beside Canonical, are there organizations already using it ? [11:12] Alan21: 1. yes [11:13] 2. The documentation is becoming confusing between the hook framework, the reactive framework and the operator framework, where's the source of truth for the operator framework and its best practices in terms of implementation ? I would like to start developing charms but I'm not confident at where to start [11:14] 2. sorry for any confusion. Perhaps the easiest way to start is using 'charmcraft init', and following along one of the operator day presentations? [11:15] there's also ops.rtfd.io if that helps but it'snot very introductory [11:15] I guess the missing bit was the operator day presentations, I'm going to check that ! Thank you for that indication [11:15] Alan21: also https://charmhub.io/docs but it's not published yet because it's not quite ready [11:16] Well, it helps already much more than what I found so it's all good ! :D [11:16] cool [11:17] 3. Have you seen anybody using the operator framework to deploy on Nomad and/or with Terraform ? [11:17] I have not, but I seem to recall Dmitrii-Sh mentioning them at one point, maybe he knows more [11:23] * Chipaca takes a break [11:27] Ah ok ok, I really appeciate your response time, so thank you for that ! I'm wondering, as a DevOps lead, I would like to invest effort into Juju, charms through operator framework but three things are still making me doubt: The documentation, the security and the support. When do you think more precise documentation will be released ? Are there [11:27] ways to limit the charms available to developers and provide Juju as a "safe interaction layer" between devs and infrastructure (devs would only deploy available charms and run associated actions) ? I've seen you're really helpful here, how much support do you provide for Juju charms developers (considering we would then open source the charms of [11:27] course) ? [12:13] Alan21: hmm, the question about limiting charms is interesting, I think it's one for somebody on the store side though, not sure how advanced the plans for that are [12:14] Alan21: about support, have you checked out the discourse? [12:14] that, and this, are where community support happens 🙂 [12:14] there's also commercial support but I understand that's not what you're asking about [12:17] bthomas, why are we switching from google convention to pep257 convention? this is for better results in RTD? [12:17] Good morning! [12:21] facubatista: that is the PR I wanted to bring to your attention. The pep257 convention is a bit stricter. Take your pick. I am not hung about it. [12:22] hola JoseMasson [12:23] bthomas, this is something Chipaca defined, after checking how the outputs were rendered [12:23] bthomas, I would not change it unless we have a reason [12:23] facubatista: note there are two things [12:24] "a" and "b" [12:24] :p [12:24] facubatista: one is google convention for docstrings as in https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html [12:25] you're all part of the juju dev team here ? [12:25] facubatista: the other is google convention for docstrings as in pydocstyle [12:25] Alan21: not at all [12:25] me, i know very little juju 🙂 just enough to use it [12:26] and use it for my use cases [12:26] which are very volatile [12:27] facubatista: its not clear to me which of the changes in #461 are actually PEP257 violations, some seem arbitrary but I havent checked [12:27] PR #461: Enable PEP257 Convention Checking [12:27] also my ' key is wonky? or maybe my fingers [12:27] Chipaca: facubatista as mentioned I am not hung about it. If that is two thumbs down I will remove the PR. Couple of reasons I made that PR 1) to start the discussion :-) 2) test is called test_pep257 but uses google convention 3) pep257 convention is supported on more version of pydocstyle and google requires a recent version 4) pep257 is a bit stricter and confirms to PEP257 strictly afaik [12:27] PR #1: Fix stop event attribute [12:27] Ah ok ok :D How has been the experience so far ? [12:28] bthomas, I think the PR is valuable for all the "text changes", do not retire it [12:28] Also it required very little work and was an easy change [12:28] Alan21: from knowing next to nothing (never had it installed) in ~february, to now, it's been quite a trip. Interesting! Also learning k8s at the same time 🙂 so you probably know more about this than i do [12:29] bthomas: facubatista: i'm not thumbsdowning it either, just that i'd like to know what pep257 requires, and what are your editor being precious [12:29] bthomas, that said, I would not change current convention checking unless you're also testing that all renderings are fine [12:30] regarding pep257 requiring it, I don't think that the extra line before the closing triple quotes is needed [12:30] I'm wondering, how much is the juju team pushing DevOps leading companies (Hashicorp, Red Hat, Grafana labs, Amazon, Microsoft, ...) to develop charms ? [12:30] Chipaca: facubatista fair points. How do I check renderings ? Note most of the changes were missing blank lines. The other changes were using imperatives in summary lines. That sums up 95% of the PR [12:31] bthomas: ./build_docs [12:31] ack [12:31] bthomas, regarding missing lines, I don't think that the extra line before the closing triple quotes is needed [12:32] Chipaca That's amazing ! Wonderful time to be an ops ;) [12:32] facubatista: not having those lines triggers a violation error for pep257 convention. [12:32] bthomas, but PEP 257 does not require those, or at least I'm not finding that [12:34] facubatista: i am perplexed now. Do you not get any violations if you remove the blank lanks but keep it as pep257 convention ? If so it may be a verions issue. [12:34] bthomas, I'm talking about the *real* PEP 257, https://www.python.org/dev/peps/pep-0257/ [12:37] facubatista: that may be a good spot. I would report it as a bug in pydocstyle . [12:40] bthomas, ok! and for this PR, I'm my +0 to keeping current convention [12:42] +0 :-) So Chipaca's call . Also I can split the blank lines in a separate commit from the text changes. So you can cherry pick what you like. Let me know. [12:43] bthomas, I don't want to cherry pick what "I like", I would revert the convention change, and not add any blank lines [12:45] facubatista: Above you mentioned you may want the text changes. That is what I ment by cherry pick. [12:45] facubatista: all all the changes are in spearate commits. [12:47] bthomas, what I mean is: rollback the convention change and all blank lines added, keep all the *text* changes [12:48] "text changes" as changes in the words, not in docstrings in general [12:50] facubatista: NP. Note there are two cases when blank lines were added 1) Missing blank line after class docstring 2) Missing blank line after last section in docstring. Both of these changes are in separate commits. Do you want both those commits removed ? [12:52] each commit messages states the pep257 convention that was violated in case you want further information about it [12:54] I'll remove (2), (1) is your call [12:56] ack. As I am inclined to pep257 convetion i will leave 1. This was one of the reasons I liked this convention since it is more stringent about these finer details. anyhoo. will make changes later today or tomorrow. [12:56] thanks [13:17] bthomas: In mongodb charm, how do you specify the number of nodes to deploy? Or it's something mongodb does "automagically"? [13:18] JoseMasson: you add units using juju [13:18] JoseMasson: you can also pass it as an argument to the juju deploy command [13:19] bthomas: yes yes, I was wondering if you do not pass an argument, you only deploy one, rigth? [13:20] I thought that by default the charms deploys 3 [13:21] JoseMasson: If you do not pass any argument it only deploys one [13:22] thanks bthomas [14:17] I'm going out for a bit, bbl [14:23] Chipaca, Alan21: I haven't seen charm code interacting with Nomad or Terrraform. Rather, I've seen people use Terraform with Juju-deployed clouds [14:27] Dmitrii-Sh: ah [14:28] Dmitrii-Sh: thank you 🙂 [14:28] np :^) [14:29] Or, Terraform could be used to provision some VMs which would then be used by Juju/manual provider. [15:37] What are the series available for a charm ? Where can I find the documentation of that ? [15:49] Alan21: each charm decides what series it is available for [15:50] Yes I've just understood that series is the type of machine to launch the operator on :D but I was writing linux instead of bionic [15:50] Alan21: https://juju.is/docs/charm-metadata#heading--series [15:51] Alan21: BTW, while you were away: [15:51]

Chipaca, Alan21: I haven't seen charm code interacting with Nomad or Terrraform. Rather, I've seen people use Terraform with Juju-deployed clouds [15:52]

Or, Terraform could be used to provision some VMs which would then be used by Juju/manual provider. [15:52] HTH [15:52] Ow, thanks for the link, next time I'll be more thorough in my research as it was actually documented [15:54] what I want to build are charms that manage deployments through Terraform. Especially now that there is the CDK for Terraform you can leverage the dynamic aspect of Juju to re-provision on-demand the environment, while still benefiting from the quality of terraform providers [15:54] this would give the responsibility of cloud API interactions to Terraform and make the Charm an easy to use interface with the cloud [15:55] jam: ^ [15:55] jam is on the juju side, he might be interested / have something to add here :) [16:02] I want my team to be able to reuse domain specific knowledge by having experts create an operator on it. Most of the deployments are running either locally in LXD, in Libvirt or in AWS, so the charms should be made so that it adapts to the deployment target (not series, the operator will always run in an Ubuntu environment, but the workload) [16:04] something like: juju deploy --config workload_environment=aws nomad --num-unit 3 [17:55] * bthomas heads off looking for a cabbage to slaughter [19:05] * facubatista bbl