[05:36] babbageclunk: a thought. Another possibility is to have leader epochs. So when unit A becomes leader it gets 10, and then when B supersedes it, it gets 11, etc. And then in the DB we store what epoc we think of the leader. Sort of equiv to the raft log entry, but less specifically tied to raft [05:40] jam: yeah - that makes sense - I'll use that. === frankban|afk is now known as frankban [08:21] manadart: I don't see an update on 2/7, shall we punt again today? [08:22] jam: Fine with me. [09:02] hi, can we install juju controller on the same MAAS node which hosts the Rack controller+region controller ? [09:13] srihas: Yes, if you setup some KVM VM's on the region/controller and add it to MAAS as nodes (see https://docs.maas.io/2.3/en/nodes-add#kvm-guest-nodes). Then you can use those VM's when you bootstrap your juju controller using constraints [09:15] zeestrat: I have MAAS controller running on a Physical node, in UCS cluster [09:27] srihas: Right. I'm not so familiar with UCS, but if you install KVM on that host and create some VM's on there according to the link above then you get some MAAS nodes for your juju controllers. [09:29] I have a MAAS region+rack controller already, won't it work? [09:37] srihas: Not out of the box unfortunately. Juju needs a ready MAAS node to bootstrap a controller on. In order to do that you can use physical nodes or some VM's. Easiest is probably to colocate KVM VM's on the MAAS controller or use VMWare VM's if you have that infrastructure. [09:38] zeestrat: ok, what do you mean by a "ready MAAS node" ? [09:40] srihas: Just a machine/node that is managed by MAAS and commissioned and ready to go: https://maas.io/how-it-works [09:43] zeestrat: ok, thank you :) I have deployed ubuntu on all commissioned nodes [09:44] so the process is like step1: add nodes; step2: commission; step3: Juju controller; and then deploy ubuntu? or its fine eventhough I have the deployed nodes to provision OpenStack ? [09:56] srihas: Aha, I see. You can skip the last step deploy ubuntu unless you really want blank ubuntu machines. If you want to use them with juju you'll need to leave them as ready. [09:56] Is the end goal to deploy OpenStack with Juju on MAAS? [09:57] zeestrat: yes thats the goal. aha, only ready :( [09:57] Have you checked out https://docs.openstack.org/charm-deployment-guide/latest/? [09:58] zeestrat: yrah, I am at this https://docs.openstack.org/charm-deployment-guide/latest/install-juju.html#testing-the-environment step and doubts raised [09:59] srihas: Cool. Do you end up with a functioning juju controller? [10:00] zeestrat: I think no, because I haven't bootstrapped yet [10:04] srihas: Ok. So as the guide mentions with `juju bootstrap --constraints tags=juju maas maas-controller` it expects a MAAS node tagged with `juju`. If you add the `juju` tag to a machine in MAAS then you can try to bootstrap to tat machine. [10:05] zeestrat: and I cannot use that machine in future for swift for example ? [10:06] Nope, that machine will be occupied by Juju then. That's why it's recommended to create some VM's on the MAAS controller so you don't lose more physical nodes. [10:07] Then you can add the `juju` tag to those VM's in MAAS so it uses those instead of physical nodes. [10:08] zeestrat: nice, thank you :) what's the purpose of this juju node ? [10:08] to act as controller for juju ops? [10:09] srihas: No problemo. Yes, the bootstrapped juju controller is the master controller which controls juju deployments [10:09] So your juju client talks to the juju controller which again talks to deployments [10:10] nice :) [10:35] manadart: since you've been in the area, I have a RFC pr: https://github.com/juju/juju/pulls/8624 [10:35] I'd appreciate your feedback if you feel it is clearer/cleaner. Or whether you prefer the old styel. [10:36] jam: Looking. [10:49] manadart: thoughts/comments ? [10:50] jam: I like it. Just adding some comments. [10:56] I have a problem using bindings with the openstack-charms. For example if I try to deploy keystone I get an error "machine-0: 12:39:55 WARNING juju.provisioner failed to start machine 0/lxd/0 (unable to setup network: no obvious space for container "0/lxd/0", host machine has spaces: "admin-space", "default", "internal-space"), retrying in 10s (10 more attempts)". Using MAAS 2.3.0 and Juju 2.3.5. Anyone else having these problems? [10:58] part of yaml: https://pastebin.com/54isF2sJ [10:59] jam: Done. [10:59] jam: BTW, wouldn't mind a 2 minute chat if youv'e the time. [11:03] Hello all, just a couple of questions regarding Apache Drill/Zookeeper. 1) How do I check the IP address of nodes with Amulet? and 2) How do I look up files on a node with Amulet? magicaltrout reckons there should be a way to do it with the deployment object... Thanks for the help! [11:15] thim: I believe you need to bind to the correct space. Something like: juju deploy --bind --to lxd:0 [11:16] Yeah, done that - `juju deploy --bind "public=default admin=admin-space internal=internal-space shared-db=internal-space" cs:keystone -n 1 --to lxd:0` [11:20] Same problem as using the yaml-file. [11:29] manadart: I can join a HO if you like [11:29] * manadart heads to standup. [11:30] thim: if you're deploying from a bundle to a substrate that has multiple spaces, then you need to edit the bundle to map your spaces for the various applications [11:30] thim: easiest is to set all bindings for an application to a given space with a stanza: [11:30] bindings: [11:30] "": internal-space [11:30] but if you're doing openstack and you want internal vs admin vs etc, then you probably need to set multiple values [11:32] @jam I've done that see - https://pastebin.com/54isF2sJ [11:33] jam: also tried without the "": default [11:33] thim: are you putting keystone into a container? [11:34] jam: yeah, but I tried a couple of other charms as well - the error is still the same. [11:35] thim: Just to confirm, have you setup those spaces in maas and are they available for the nodes you're deploying on? [11:36] kjackal: et al, got any pattern for checking files on a unit within amulet for my minions rmcd [11:37] magicaltrout: what do you mean by checking? [11:37] ah [11:37] amulet sentry directory_listing [11:37] or soemthing [11:37] I want to check a config file is actually set correctly [11:38] file_contents [11:38] I believe [11:38] I cannot think of anything fancy other than getting the file and looking at its content [11:38] https://github.com/juju/amulet/blob/master/amulet/sentry.py#L153 that? [11:38] zeestrat: Correct - https://pastebin.com/GtFzCLfL [11:39] zeestrat: `juju spaces` is populated from MAAS [11:40] sure magicaltrout, looks ok. Although you would better start using libjuju ;) [11:40] don't make me sad kjackal [11:40] whats the deal with testing these days [11:40] amulet? or libjuju? or a munge of both? [11:41] https://github.com/juju/python-libjuju forget about amulet [11:42] ya'll make me so sad [11:42] https://github.com/juju/python-libjuju/blob/37a7500245ae61fc2c103d1728a65b99485a9ef4/tests/integration/test_machine.py#L67 [11:47] thanks kjackal [11:47] we're all very sad [11:48] can confirm ^ [11:49] thim: so the values you have there look correct to me in passing, with the caveat that you probably need to do it for all applications. also, what specific version of Juju are you running. IIRC we fixed a particular bug where space constraints weren't being set early enough for containers [11:49] so if the host machine launches fast enough and you're deploying a bundle, the container could try to start before the spaces were set. [11:49] I *think* that is fixed in 2.3.5 but I'd have to look through changelogs to know for sure [11:50] in the very short term, you can add a "constraints: spaces=X,Y,Z" to get around it. [11:51] Yeah, I'm using 2.3.5 with MAAS 2.3.0. I'm currently just deploying Keystone because of time saving when destroying the machines. Already using constraints as well. `constraints: "tags=controller spaces=admin-space,internal-space,public-space"` [11:51] *public-space = default [11:52] just pasted from the wrong file. [11:55] magicaltrout: rmcd: how can we cheer you up? [11:57] jam: are you talking about constraints on the charm or the machine btw? [12:02] kjackal: Is it actually possible with python-libjuju to deploy charms from within a charm in the same model? :/ Haven't used it so far [12:03] TheAbsentOne: that charm should be able to talk to the controller, right? [12:03] Havent tried it either [12:05] TheAbsentOne: Yeah, but it's a bit clunky. You'll need to create a juju service user in the model then talk to that. I asked about that on the last juju show and it's something that the team would like allow for inside the charms in the future [12:06] kjackal: euhm yes, I suppose. I'm on a heavy theorycrafting trip and I kinda want a charm to decide what service should be deployed. I'll give an example. Imagine a charm that represents a mysql OR a postgres service. The charm then should deploy one of the 2 services itself all automatically. [12:06] Ahn so it's a kinda a request zeestrat ? [12:11] So as a summary: I want to create a charm that that listens on an incomming relation, it takes the requirements, chooses a good service and deploys the chosen service all in one kjackal zeestrat. As I see it now, it seems pretty impossible with juju [12:12] TheAbsentOne: Yeah. You can check out the latest episode for a bit more eloquent details. I asked about better interfacing charms and juju in order to scale and deploy things and it's on their list. [12:13] Good to know! [12:15] TheAbsentOne: I know of one charm that talks to the juju controller: https://jujucharms.com/charmscaler/2 [12:15] TheAbsentOne: Regarding your summary, if you use an juju service account then you should be able to talk to juju with libjuju just fine and use any logic you want inside your charm. It's a bit greenfield at the moment but not impossible. [12:16] TheAbsentOne: Yeah, the charm above uses that approach (although a bit old). [12:19] Thanks for the insight, big help guys! [12:25] thim: so bug #1737565 was where we ran into this in the past, and that says it was fixed in 2.3.2 so it should be in 2.3.5 [12:25] Bug #1737565: no obvious space for container

[12:26] a proper "bindings" section should be sufficient, so if it isn't working, we'd like to get logs of the controller preferably with: juju model-config logging-config="=DEBUG;juju.rpc=INFO;juju.apiserver=INFO" [12:26] jam: Yeah, I previously ran 2.3.2 and didn't work there either - so I upgraded to 2.3.5. [12:31] Just one small question zeestrat what exactly do you mean with a "juju service account". Could you point me to some documentation? [12:32] TheAbsentOne: so the model credential work that's follow up to the current trust (cloud credentials access) isn't there atm [12:33] TheAbsentOne the way it's been done so far is to create a juju account with model access and set via model config [12:33] err, not model config, but the charm config [12:33] TheAbsentOne: so that the charm can behave as a juju user with access to the model to make changes over the API (libjuju) like deploy thihngs [12:34] I see, thanks for that clarificiation rick_h_ ! [12:34] np, morning party people [12:34] jam: Hmm.. I think i found the problem. It's the Juju GUI that probably parses the yaml file incorrectly. [12:35] `juju add-machine -n 1 --constraints 0=t 1=a 2=g 3=s 4== 5=c 6=o 7=n 8=t 9=r 10=o 11=l 12=l 13=e 14=r 15= 16=s 17=p 18=a 19=c 20=e 21=s 22== 23=a 24=d 25=m 26=i 27=n 28=- 29=s 30=p 31=a 32=c 33=e 34=, 35=i 36=n 37=t 38=e 39=r 40=n 41=a 42=l 43=- 44=s 45=p 46=a 47=c 48=e 49=, 50=d 51=e 52=f 53=a 54=u 55=l 56=t --series xenial` [12:35] TheAbsentOne: what's this? [12:38] I think you wanted to tag thim rick_h_ ? Or am I missing something? x) [12:38] jam: When using juju cli it seem to work, but the state on the LXD is pending, but container is started and I can ssh to the machine. [12:38] TheAbsentOne: oh sorry, tab complete fail [12:41] hehe no problemo [14:07] thim: if you haven't yet noticed, you were giving incorrect space names above [14:07] why you space bindings were failing [14:08] "host machine has spaces: "admin-space", "default", "internal-space"" [14:10] or, excuse me, the way you were specifying them looks incorrect [14:10] `juju deploy --constraints "spaces=admin-space,internal-space,public-space"` [14:10] should be [14:11] libjuju why does unit object only have a public address? [14:11] am I missing something obvious? [14:13] thim: `juju deploy keysone --constraints "spaces=admin-space,internal-space,public-space" --bind default,public=default,admin=admin-space,internal=internal-space,shared-db=internal-space` [14:17] magicaltrout: to be fair it feels I'm missing sanity and knowledge, when it comes to understanding libjuju x) I too was wondering before what unit really represented [14:42] TheAbsentOne: https://jujucharms.com/docs/2.3/charms-working-with-units [14:43] it just represents a unit of an applications [14:43] application [14:44] yeah bdx exactly but it was as a remark on what magicaltrout said. A unit in libjuju doesn't seem to know anything about the application [14:45] I see, is there an "application" object? [14:46] TheAbsentOne: possibly what you are looking for is https://github.com/juju/python-libjuju/blob/master/juju/application.py#L26 [14:49] hrm, anyone have any ideas why unit-get private-address is returning a hostname instead of an ip? [14:49] cory_fu: ^ ? :) [14:50] admcleod_: Unfortunately, it depends on the cloud. There are some new fields in there that might be of help, but I'm not sure if any are guaranteed to be an IP [14:51] cory_fu: curious, cos its manual provider and im sure it was working until recently. new fields such as? [14:52] admcleod_: Fields related to the networking primitives: https://jujucharms.com/docs/stable/developer-network-primitives [14:52] ahn thx bdx that might help [14:53] admcleod_: But like I said, I don't know if any of those will end up being helpful, but I think you are supposed to use them instead of private-address [14:54] ah ok [14:54] thanks [14:57] cory_fu: erm. do you know how i can list the bindings? [14:59] admcleod_: It's not integrated into reactive yet, unfortunately, but there are charmhelpers for it. I have to admit, though, I haven't really used it. I know stub understands it, but I'm sure he's asleep now. [15:00] ... [15:00] good lord [15:01] admcleod_: I *think* those fields might also be present in the relation data. It's worth doing a raw dump of the relation data [15:01] all i want to do is get the private address of the machine. really shouldnt be that hard should it :} [15:02] admcleod_: Try seeing if there are other auto-keys in the relation data [15:02] what if i only have one unit of one app deployed? [15:02] cory_fu: not trying to meddle in the conversation but now that you are talking about it. What is the best way to dump all relation data actually, according to you? [15:03] TheAbsentOne: One-off / by hand for debugging? I usually use: juju run --unit -- relation-get -r - [15:04] TheAbsentOne: You can get the with: juju run --unit -- relation-list [15:05] TheAbsentOne: You could also always use debug-hooks and put a breakpoint in your charm code. [15:05] Right cool, and could you access a list or something inside hooks or is a breakpoint the way to go [15:05] ohn you answered already, thx cory_fu [15:06] cory_fu: ill go back to trying network-get (ill let you know what happens) [15:12] admcleod_: Thanks. [15:34] balloons: bug #1765096 looks like our "updated" jujud-versions.yaml holds the wrong data [15:34] Bug #1765096: 2.3.6 bootstrap fails [15:34] yea, I was just noticing [15:34] balloons: the code seems to expect a version.Binary which includes series and architecture, but it only contains the version # [15:34] yea, I'm certain I broke it in the new snapcraft build; not the one that was penidng [15:35] I'll push the right revision, trying to find it now [15:37] jam, ohh, nvm. hmm. it's just reading version=$(jujud version) [15:38] so that's odd [15:41] jam, yea it was the experimental snapcraft changes in the end, but I'm no longer sure why :-) [15:42] ahh, diff reveals all [15:47] cory_fu: i cant list the spaces, cos its maas. so i cant specify a binding... [15:54] balloons: manadart: thumper: for whoever would like "juju remove-machine 0" now works on controllers for Mongo: https://github.com/juju/juju/pull/8625 [15:54] with caveats, but step along the path [15:55] cory_fu: sorry that shouldve been 'not maas' [15:56] admcleod_: My understanding was that the ingress-address should fall back to private-address when spaces aren't being used. [15:56] admcleod_: Also, I don't think maas / not maas is relevant, I think it depends on whether your charm defines network spaces. [15:57] admcleod_: But the ingress-address stuff is also relevant for cross-model relations, irrespective of network spaces. wallyworld is also on the other hemisphere, though, unfortunately [16:03] cory_fu: well if i cant list spaces, i cant specify a binding, and i am told 'spaces not supported' when trying to list them with manual provider. i dont think i should have to change the charm to get the private ip address. === hml_ is now known as hml [16:26] admcleod_: Did you check the relation data? [16:26] nope [16:28] cory_fu: if thers 1 unit and no relations, will that still work? [16:29] admcleod_: Oh, I was confused. I thought you were trying to get the private address for a relation, but you want the local unit. [16:29] right, thats why unit-get originally [16:32] admcleod_: So, if you really need an IP, you have to do something like this: https://github.com/juju-solutions/jujubigdata/blob/master/jujubigdata/utils.py#L427-L441 [16:32] admcleod_: But if you recall, that was a source of errors for us with the big data charms [16:32] cory_fu: lol [16:32] cory_fu: i thought i remembered something like that [16:33] Yeah [16:33] cory_fu: fwiw... wtf. === frankban is now known as frankban|afk [16:54] cory_fu: meanwhile. i seem to be having a pip3 issue with charm build. 'no such option: -d' [16:56] admcleod_: Are you using the snap? [16:56] cory_fu: yeah - i just refreshed it, then i refreshed with --beta [16:56] cory_fu: i would paste the error but my laptop is going crazy [17:00] cory_fu: oh of course i also have the apt version installed. [17:01] admcleod_: Ah yeah, I can only see that error coming from the apt version, since the snap is strictly confined and bundles its deps [17:01] been a while since i used this === mwhudson is now known as Guest20250 === Guest20250 is now known as mwhudson_ [21:31] cory_fu: admcleod_ : ingress-address will just be "private address" normally. with cmr, it may instead be set to "public address". network-get now talks generically in terms of ingress-address, bind-address, egress-subnets instead of private/public address which have little semantic meaning [21:33] cory_fu: did you see the mysql interface bug? it seems relation-broken hook is, well, broken [21:35] wallyworld: Yeah, the -broken hook handling with RelationBase-based interface layers is known to be broken in general. The easiest fix would be to update that interface layer to use Endpoints [21:36] cory_fu: is that on the todo list for anyone? i'd not be very productive trying to do it at my end [21:37] wallyworld: Not really, but it should be a fairly easy conversion. [21:38] wallyworld: With network-get, does it only work if a network space has been created? How do you know what bind name to use? [21:39] cory_fu: network-get works with or without. from memory there's a --binding arg [21:42] wallyworld: Not according to https://jujucharms.com/docs/2.3/developer-network-primitives#network-get and admcleod_'s comment from earlier (he's EOD now) [21:43] wallyworld: The charmhelpers wrapper also require the binding name [21:43] cory_fu: just looked at code, network-get takes a positional arg for bindingname [21:44] wallyworld: So, I'm unclear on what one would pass to that? [21:45] cory_fu: i think you pass the endpoint name for which you want the address info [21:45] https://pastebin.ubuntu.com/p/YPTTYzFMbM/ [21:48] cory_fu: if there's questions, best to send an email to #juju-dev since john will be able to give a much better answer. i didn't write the original code (just added the new args) so am not totally familiar with the finer detail [21:48] wallyworld: I guess the "what address I should listen on" really depends on who is going to be connecting to you, i.e. a relation (at least, an endpoint), and that's the bit that's confusing for me [21:49] But I think that calling it a "binding name" is confusing if it's in fact the endpoint name [21:49] cory_fu: right. juju knows if you are in a relation context or not, so it will vary what it gives to be the thing that is needed to listen on [21:50] wallyworld: About the mysql interface; are you hitting that? [21:50] cory_fu: generally, what you bind to will be independent of relation. what you advertise to the other side to send to (ingress address), will be relation dependent [21:50] I've just been called to dinner [21:51] cory_fu: i am not sure why it's called binding instead of endpoint, i didn;t write the code :-( [21:51] cory_fu: yeeah, am hitting the bug [21:51] in the interface layer [21:51] in my caas charm [21:51] wallyworld: I'll take a look at the mysql interface tomorrow [21:51] yay, ty [21:51] enjoy dinner [21:51] o/