[01:17] Hello, any work in progress to integrate the new lxd cluster features in the juju orchestration system? for example deploy charms to the cluster lxd 3.0 with abstraction on the host target and autoscale? thanks [01:23] aperez900907: yes work is in progress [01:23] not autoscale though [01:25] cool, any detail if will be support on xenial release o the 18.04 ? [01:25] there will be a two phase support... [01:26] phase one, which we are hoping to get into 2.4 of Juju, is using existing lxd provider, but if you are on a machine that is part of the cluster, it just uses the cluster [01:26] phase two is supporting remote clusters and dealing with machines as "zones" [01:26] cool [01:28] any chance to support autoscale in the future given limits metrics? [01:29] xenial will be support in the new phases?? === mwhudson is now known as Guest60520 === Guest60520 is now known as mwhudson_ [01:57] yes xenial will be supported [01:57] unlikely that juju itself will autoscale, but that doesn't mean someone won't write something on top [02:32] veebers: is out citest running on py3 or py2? [02:33] kelvinli_: py2, p3 should pretty much be supported but I don't think that's been verified yet [02:34] i saw py3 in makefile for testing jujupy, but seems assess*.py are all py2? [02:34] kelvinli_: aye, all assess are py2, there is some new stuff that is py3, but I can't recall off the top of my head. [02:35] kelvinli_: from memory jujupy/* is all py compatable. There was a test that was py3 that required that, but at this stage the assess scripts are assumed to be py2 [02:35] that being said I don't believe that would be a big job to get it over the line to all be py3 compat (not that that helps you right now :-)) [02:38] veebers: acceptancetests/jujupy/workloads.py breaks on py3. [02:39] veebers: ic, thx. I will test it more to see how it goes. [02:39] kelvinli_ d'oh, that'll be my fault. That's a recent addition (well, code move around) that I didn't make py3 compat [02:40] veebers: i found an import error at `wait_condition.py` [02:43] kelvinli_: as in it's broken regardless of py2/py3? [02:45] veebers: no, it's an incorrect import path [02:45] kelvinli_: oh, that's not good. I imagine that's my fault too with a recent change :-\ [02:45] veebers: would you mind to have quick hangout? [02:46] kelvinli_: sure thing, lets use the standup one [02:46] yup cool [03:18] admcleod_: That would be https://bugs.launchpad.net/juju-core/+bug/1557769 and https://github.com/juju/docs/issues/1409 , which will never be fixed with the old API. The new Juju 2 network stuff will always give you IP addresses (network-get, egress and ingress addresses on relation data, etc.) [03:18] Bug #1557769: private-address returns name, not ip

Collection):Fix Released by stub> [03:19] Well, it could be fixed in charm helpers (FSVO fixed) if someone approved that old MP and landed it in the git repo. But all charms need to be updated with newer networking anyway, to support cross model relations. [03:20] I think the only valid use of using the private-address now is in a peer relation, and that is probably lazyness on my part. [03:23] cory_fu, wallyworld : I found pulling the necessary addresses from the relation easier in practice than using network-get, especially converting an old RelationBase implementation to an Endpoint (which was really easy, and much nicer) [03:25] stub: fair enough. ostensibly, network-get info should be the same as what's put into the relation data bag [03:27] (which is charmhelpers.core.hookenv.ingress_address(...) and charmhelpers.core.hookenv.egress_subnets(...) ) [03:28] Yeah, just when writing charms relation-get gives you what you need, while network-get requires a bit more digging to get the bits you need out of the document. [03:31] stub: that i agree with from what little i've been directly exposed to in that area. i guess network-get is sometimes needed outside of a relation context [03:36] yeah, I'll need it when updating Cassandra (what IPs it binds too is quite complex for customer related reasons, but will be much much better with network spaces and network-get) === mwhudson is now known as Guest18633 === Guest18633 is now known as mwhudson_ === mwhudson is now known as Guest42456 === Guest42456 is now known as mwhudson_ === frankban|afk is now known as frankban [07:20] manadart: any chance you could have a look at https://github.com/juju/juju/pull/8625 ? [07:25] Good Morning [07:46] morning [07:54] jam: Looking now. [08:13] there is also https://github.com/juju/juju/pull/8627 if you're interested in a slightly orthogonal but very related [08:18] jam: Doesn't look like there are any new OCI provider changes. Want to jump on that call for a quick chat about this? [08:18] manadart: sure [08:50] stub: hey - I've pushed vault 0.9.6 up to the candidate channel in the snapstore; 0.10.0 is in edge as well [08:52] stub: that's testing ok on a pure bionic deployment including pgsql 10 [09:17] jam: here's a small PR to update catacomb to use tomb.v2. part of the work to get our deps all uptodate and consistent across all out repos https://github.com/juju/juju/pull/8628 [09:20] wallyworld: shouldn't we be passing the func() into tomb.Go() rather than creating a goroutine that only exists until done is closed? [09:22] wallyworld: specifically, we are closing "done" when our loop exits, but that's exactly the same time that we would be having the loop exit [09:22] is it just that func() wasn't returning an error? [09:22] eg, func() error vs func() ? [09:33] jamespage: Cool. Releasing 0.9.6 to stable should be fine. What were you thinking about 0.10.0 ? I'm leaning towards stable too, rather than juggling channels with zero-dot versions [09:34] stub: I think so - there is not a huge diff to 0.10.0 [09:34] * stub investigates running the mojo charm tests with an alternative snapstore channel [09:36] stub: ok so.... the changes we've been landing into the vault charm are appearing under cs:~openstack-charmers-next/vault [09:36] stub: that will include at some time today support for a 'channel' configuration option [09:36] which superceedes the hardcoding of 'stable' in layer options [09:37] hi jamespage :P [09:37] hey cnf [09:37] oh, ta. That will be enough for me or tom to tweak our bionic CI tests [09:37] how are things? [09:38] cnf: busy as always [09:38] hehe, that's not bad, is it? [09:38] stub: if you can give me a +1 on the 0.9.6 I'll shove that to stable, and then promote 0.10.0 to candidate [09:38] cnf: nope! [09:39] I haven't come up with a good solution for alternative channels with the snap layer. Maybe a snapchannel config option added standard, and a layer.yaml option to hardcode which snaps that applies to. [09:47] jamespage: It is working fine for me in devmode [09:49] jamespage: It looks like there are going to be cli incompatibilities with 0.10. I'm still leaning towards a single stable channel though. [10:15] (0.9.6 is working fine I mean) [10:30] Cynerva, ryebot, cory_fu: https://github.com/juju-solutions/interface-etcd/pull/12 if you have cycles - modelled on something similar in the rabbitmq interface [10:30] stub: ta - promoting to stable [10:41] stub: if you're interested - https://review.openstack.org/#/q/project:openstack/charm-vault is the queue of landed and inflight changes [11:26] manadart: something I just ran into, bug #1765342. I'm not sure how I feel about it yet. [11:26] Bug #1765342: 2.4 enable-ha complains about no address w/ unstarted machines [11:26] but "juju enable-ha && juju enable-ha" complains about not having IP addresses for the machines that are just starting [11:27] note that would also happen for "juju enable-ha -n3 && juju enable-ha -n5", and I'm a little concerned if they have controllers that are broken during startup. [11:30] manadart: also, when you get a chance, https://github.com/juju/juju/pull/8627 [11:31] jam: Ah, yes. It knows the controller is there, but it has no addresses yet. Hmm. Doosie. [11:57] jam: thanks for review, your idea is much better, my brain just didn't see the simple way. PR updated [12:08] wallyworld: lgtm with a small caveat, would we want to return the error rather than always returning nil? but either way I think its correct. I think the difference is that we probably wouldn't ahve to call .Kill() if we returned the error from runSafely [12:08] but I'm happy landing as is, as well. [12:08] jam: thanks ok, i'll take a look and see if that change works [12:14] jam: yeah, we do need the Kill() as we need to pass that through to the embedded tomb (otherwise tests hang/timeout). I think I did try a variant of that in my testing and concluded I needed the Kill() [12:14] wallyworld: are we doing a beta2 or an RC1? I'd like to create a milestone in LP for bugs [12:15] wallyworld: the calling tomb isn't the embedded tomb, and they aren't linked? k [12:15] jam: *I* think we'll need another beta [12:15] we can always rename the milestone? [12:15] wallyworld: probably [12:15] worst case we rename the targets and delete one we never released. [12:16] i'm hopeful we won't need beta2 but we always seem to [12:17] the calling tomb is the embedded tomb, but the tests fail, i can dig in a bit to see why [12:19] it may be to do with that the catacomb's tomb is not embedded but an attribute of the catacomb struct [12:19] and so the outer Kill() is needed [12:51] Hi! I have simple question I guess - how can I get using reactive current IP of the machine on which I'm deploying - I need to pass it as variable to some command [12:56] elmaciej_: I don't know the reactive function offhand, the juju command would be "network-get". to get the address to advertise for other applications to use. grepping that from reactive may point you in the right direction. [12:56] https://github.com/juju/juju/pulls/8631 for a fairly straightforward logic fix [12:56] manadart: externalreality_ ^^ [12:57] balloons: want to give a go/no-go on https://github.com/juju/juju/pulls/8607 (stripping built binaries) [12:57] jam: Thanks, I'm looking how to use this from reactive as I'm using docker layer [12:57] elmaciej_: I'm pretty sure they wrap the function, I just don't know the name of it. [12:59] jam, sure [13:18] jam: looks like there is from charmhelpers.contrib.openstack.utils import get_host_ip [13:22] Is there a .deb of charm-tools for bionic tucked away in a PPA somewhere? [13:22] hml: it looks like in the container you can do "apt install eatmydata && sudo echo "/usr/lib/*/libeatmydata.so > /etc/ld.so.preload" [13:22] hml: you can do web searches for 'libeatmydata' and/or 'eatmydata' to see if it helps. [13:22] jam: ty [13:35] jam, thanks. hml, is worth just tacking that on and kicking off a run to see if it helps without us doing more work. If so, :-) [13:38] manadart: thanks for catching the %2 thing. It was the *whole point* of that patch, and I just hadn't finished turning the test into its final form and seeing it actually pass. [13:39] jam: Cool. [13:44] manadart: 8627 has the updated test and update math. [13:48] jam: Approved it. [13:48] manadart: thanks [13:59] hml, so can your ci-test PR land? [14:01] balloons: if i can get an approval ;-) - i do want to squash the commits if folks are finished with the viewing [14:01] hml, my approval still stands :-) If you've addressed Chris's bugs, I'm still +1 [14:01] s/bugs/comments [14:01] balloons: it’s not showing as approved in github - yes, i’ve addressed all comments etc [14:02] ohh, maybe I didn't +1. In which case, I'll fix [14:07] hml, feel free to merge once you are happy with commits [14:07] balloons: thx [14:07] hml, also feel free to add to functional tests and push once it lands. Thanks! [14:07] balloons: will do [14:21] stub: so what if i dont have a relation? [14:39] wallyworld: When you're around, can you please take a look at and test https://github.com/johnsca/juju-relation-mysql/pull/4 [14:40] wallyworld: It should resolve that issue you were hitting. [16:17] balloons: manadart: https://github.com/juju/juju/pull/8632 removes all the 'enable-ha to demote a machine' code. [16:18] balloons: your email client did the strange formatting again [16:18] jam I know.. I feel stupid for not using the web client. I forgot until just after I sent [16:18] 2.4 notes are especially terrible. I'm sorry [16:19] I think it's the conversion from gdoc to plain text formatting I enforce in my client [16:19] The message looks fine in draft.. === frankban is now known as frankban|afk [19:30] Hi! It's actually stupid question - does anyone installed charm-tools package on windows on pycharm [20:12] elmaciej: One of the folks from CloudBase might have, but I don't know any of their IRC handles. Is there a specific issue you're hitting? [20:12] cory_fu: yes, I cant do pip install charm-tools, it's failing [20:13] elmaciej: Can you pastebin me the error? [20:14] cory_fu: I have vm with all setup done on ubuntu but just checking , here is the error https://pastebin.com/swxWvFV9 [20:15] cory_fu: same thing worked on ubuntu well. and also under ubuntu on windows it's working fine [20:18] cory_fu: I'm demoing something tomorrow and just want to "sell" idea that you can develop and build charm on any platform [20:19] offcourse juju works on windows so you can deploy , but just checking if "you can develop" too statement is tru [20:24] elmaciej: To be honest, I'm not sure that pip installing charm-tools would be enough to develop anyway. You would also want https://github.com/juju/charmstore-client [20:25] I really don't understand that error from pip, though. I wish it gave some indication on where the invalid character came from [20:25] yea, but funny thing is I can do charm-build on my windows using built-in ubuntu subsystem. Just stupid IDE don't wont work as it requires to import packages to compile [20:26] cory_fu: anyway thanks for you time, if I'll find solution I'll paste it here [20:32] elmaciej: Thanks! [20:49] thumper, can I get a quick look at https://github.com/juju/juju/pull/8633. I'd like to land it with the failing tests to unblock CI runs (I believe) [21:02] veebers, ^^ 1.25 enablement [21:06] balloons: LGTM, looks to be largely bringing the 1.25 makefile up to speed with recent changes. [22:44] wallyworld: Did you see my request to review https://github.com/johnsca/juju-relation-mysql/pull/4 ? I tested it with the Ghost charm and it seems ok, but I wanted to make sure it resolves the issue you were hitting without introducing any others [23:02] cory_fu: hey, sorry i didn't yet, looking [23:02] thanks so much for fixing [23:02] we'll test today asap [23:07] wallyworld: Thanks. Unfortunately, I'm well past EOD but if it tests ok, I'll merge it first thing tomorrow. [23:07] cory_fu: no worries at all. timeones suck. enjoy your evening, will leave a comment in the PR