[00:02] <rick_h> bdx: sorry, was at the boy's soccer game. you get setup?
[00:30] <bdx> rick_h: yeah, g2g
[00:31] <bdx> rick_h: so am I right to think that the way an interface sets host ip info (as many do), say on the provides side of the relation
[00:31] <rick_h> bdx: cool, I'm testing out the CMR version of prometheus right now. /me just made the relation and hopes this works out
[00:32] <rick_h> bdx: sorry, I didn't parse that with a question in it?
[00:32] <bdx> should now be done differently then the now legacy way
[00:32] <rick_h> bdx: yes, I think so
[00:32] <rick_h> bdx: a lot of charms I think will need updating to work in a CMR world
[00:32] <rick_h> bdx: so once I prove this works I want to get a couple of solid examples and start making a LOT of noise to charmers
[00:33] <bdx> yeah,
[00:33] <bdx> so
[00:34] <rick_h> and damn it didn't work.../me goes debug-log chasing
[00:34] <bdx> this is my mod of the http interface https://github.com/jamesbeedy/interface-http/blob/network_get/provides.py#L20
[00:34] <bdx> such that it only allows the providing layer to set those values
[00:34] <rick_h> oh, dammit I didn't deploy my forked charm whoops
[00:35] <bdx> instead of https://github.com/jamesbeedy/interface-http/blob/master/provides.py#L22
[00:35] <bdx> ^ the old way
[00:35] <bdx> where the ip address is obtained and set in the interface code
[00:35] <bdx> vs my new way
[00:35] <bdx> or
[00:35] <bdx> the* new way
[00:36] <bdx> where we use network_get()
[00:40] <rick_h> bdx: hmm, yea I'm not sure on that part. I've found that confusing in my work as well the line between work done in the layer vs the reactive bits of the charm itself
[00:41] <bdx> so
[00:41] <bdx> rick_h: https://github.com/jamesbeedy/newcharm/blob/master/reactive/newcharm.py#L22
[00:41] <bdx> ^that worked for me
[00:42] <bdx> with the network-get branch of the interface-http from above^
[00:42] <bdx> but I'm not sure if that the way we *want* to be doing it
[00:44] <bdx> I could have passed the interface name into the relation data, then used network_get() in the interface code to parse there
[00:44] <bdx> but that just doesn't seem right
[00:46] <bdx> possibly the interface name is already available in the conversation
[00:46] <rick_h> bdx: hmmm, but is the interface name defined by the layer?
[00:46] <bdx> yeah
[00:46] <rick_h> bdx: I mean if you've got the mysql layer you know you're speaking db already
[00:47] <bdx> oh
[00:47] <bdx> I see
[00:48] <bdx> so the provides side of the interface can have a static defined interface name, because we know what it is in the providing layer
[00:48] <bdx> and then the provides.py can just define that
[00:48] <bdx> and use it in network_get()
[00:48] <bdx> that sounds a bit nicer
[00:53] <bdx> rick_h: like this https://github.com/jamesbeedy/interface-http/blob/network_get/provides.py#L20
[00:53] <bdx> ?
[00:53] <bdx> rick_h: ^ doesn't work
[00:53] <bdx> because we don't know that the layer will name the interface http
[00:54] <bdx> the name that the layer gives interface-http is defined in layer.yaml
[00:54] <bdx> so I just don't see a legitimate way of hardcoding it in the interface code
[00:55] <bdx> the only case where ^ works is if you name the http interface http in your layer
[00:55] <rick_h> bdx: hmmm...yea
[00:55] <bdx> see what I'm saying
[00:55] <rick_h> bdx: and the relation id is going to be needed in cases where you relate more than once as well. This seems messy
[00:55] <bdx> right
[00:56] <rick_h> lol...damn this is cursed
[00:56] <rick_h> so I have this updated prometheus charm
[00:56] <bdx> rick_h: yeah, I read through your changes
[00:56] <rick_h> and it's target endpoint is offered...but now because it's offered prometheus auto adds itself as a target.
[00:56] <rick_h> so it's loading itself using the public addresss since it's offered as a CMR endpoint
[00:57] <rick_h> which then fails because prometheus isn't exposed (even to itself over the public IP)
[00:57] <rick_h> so "working as intended" ... but broken
[00:57]  * rick_h beats head on the wall for inspiration
[00:59] <bdx> I see
[00:59] <bdx> rick_h: what is ever done with "address" in write_prometheus_config_yml()
[01:00] <bdx> I see its set, but never used
[01:00] <bdx> a bit confusing for sure
[01:01] <rick_h> bdx: so it's used to write out the prometheus.yml file later in that function
[01:02] <bdx> oh
[01:02] <bdx> I don't see the var "address" used again ... bad eyes
[01:02] <rick_h> bdx: it's not part of that diff, it's used with private_address key in options later in that function
[01:03] <rick_h> bdx: oh lol, I didn't update that
[01:03] <bdx> ok
[01:03]  * rick_h must have done some bad copy/paste/etc
[01:03] <bdx> lol,
[01:03] <rick_h> 'private_address': hookenv.unit_get('private-address'),
[01:03] <rick_h> that's supposed to be the address bit
[01:03] <bdx> yeah
[01:03] <bdx> thats what I thought
[01:04] <rick_h> somehow missed that. I started with a charm pull (no git bits) and made changes/etc and then tried to merge them to a git clone from LP and must have missed it somehow
[01:04]  * rick_h is stumbling around charming like a noob still
[01:04] <bdx> so I think (for the case of http interface) it seems most sane to use network_get() in the providing layer, and set the ip info on the relation from the provides
[01:07] <bdx> me 2
[02:30] <bdx> {'ingress-addresses': ['107.22.129.65'], 'bind-addresses': [{'addresses': [{'cidr': '172.31.48.0/20', 'address': '172.31.51.59'}, {'cidr': '172.31.48.0/20', 'address': '172.31.51.59'}], 'interfacename': 'eth0', 'macaddress': '12:ba:53:58:9c:52'}, {'addresses': [{'cidr': '252.48.0.0/12', 'address': '252.51.59.1'}], 'interfacename': 'fan-252', 'macad
[02:30] <bdx> dress': '1e:a2:1e:96:ec:a2'}]}
[02:31] <bdx> rick_h: we should work on coming up with a strategy for parsing ^ depending on what you want
[02:31] <bdx> for example, I want the private network interface ip for the instance
[02:32] <bdx> theres no clear way to distinguish which of ^ addresses it is ....
[02:32] <bdx> I know
[02:32] <bdx> you could check for interface names in the dict
[02:32] <bdx> and then decide to do based on what interfaces you find
[02:33] <bdx> but ^ so hacky
[02:40] <rick_h> bdx: yea, the key thing is I need to better understand what could possibly come out of that dict
[02:40] <rick_h> bdx: atm it's not 100% clear and what's useful vs not as useful. I assume later updates to the code can do things like add additional kwargs to the network_get to be more useful
[02:40] <rick_h> bdx: so that's why I've started out just dumping all the data back to start
[02:41] <bdx> yeah, I'm doing the same
[02:41] <bdx> good call
[02:42] <bdx> rick_h: what about a "default" space
[02:43] <rick_h> ?
[02:43] <rick_h> bdx: sorry, getting late here and I'm slow and not following
[02:43] <bdx> sorry, no, its my bad, same
[02:44] <bdx> what I'm digging at here, is how to get what I want from the network_get() output in a no-nonsense way
[02:45] <rick_h> bdx: yea, I think the key is going to be that the charm has to be deployed with the interface bound to a space.
[02:45] <bdx> entirely
[02:45] <rick_h> bdx: but going to punch out for the night. good luck and let me know how it goes!
[02:45] <bdx> kk
[02:46] <bdx> thanks
[02:46] <rick_h> np, ty for banging on stuff
=== blahdeblah is now known as blahdebsvlah
=== blahdebsvlah is now known as blahdeblah
[05:32] <Akshay> Hi All, can someone please help me here. We at Veritas Technologies LLC are trying to deploy juju based openstack pike bit but the deployement is failing for mysql charm at hook "shared-db" with error "keystoneauth1.exceptions.http.InternalServerError: Internal Server Error (HTTP 500)"
[06:12] <Akshay_> Hi All, can someone please help me here. We at Veritas Technologies LLC are trying to deploy juju based openstack pike bit but the deployement is failing for mysql charm at hook "shared-db" with error "keystoneauth1.exceptions.http.InternalServerError: Internal Server Error (HTTP 500)"
[07:49] <burton-aus> Hi Akshay_ would you mind to subscribe this mailing list then send your question there with details? juju@lists.ubuntu.com
[07:53] <burton-aus> Akshay Akshay_ the subscription link is: https://lists.ubuntu.com/mailman/listinfo/juju
[09:11] <Akshay_> thanks for the help Burton, I will try that.
[09:21] <burton-aus> Akshay_ no worries.
[10:03] <Akshay_> Hi Burton, I have subscribed to the mailing list, after how much does it generally gets verified/confirmed?
[10:03] <Akshay_> As my mails are getting rejected for now
[10:43] <burton-aus> Akshay_ let me ask admin to approve it for you.
=== freyes__ is now known as freyes
=== cassiocassio is now known as cassio
=== cassio is now known as cassiocassio
[14:40] <skay> how can I get the set of current flags during tests? I'd like to do something similar to wait_for_messages from amulet
[14:46] <cory_fu> skay: There's no API for that defined directly in Amulet, but you can use something like yaml.loads(unit.run('charms.reactive get_states --format=yaml')).keys()
[14:46] <skay> thanks
[14:47] <cory_fu> skay: kwmonroe just reminded me that you should probably use get_flags instead, which I think would make the .keys() bit pointless as well
[14:47] <skay> ack, thanks!
[14:51] <skay> I'm forcing an error in my reactive method that handles a flag being set, and my status shows this: (upgrade-hook) my error message
[14:51] <skay> I've been doing that live, but now I want to get an amulet test going so that I can figure out why that's happening
[14:52] <skay> I'd prefer to give a status to the operator that the failure is inside my method and not due to a failure in a hook
[14:52] <skay> that's another problem I've been having
[14:53] <skay> also, TIL I shouldn't use an error status, I should use blocked.
[14:55] <skay> hmm, I've let it run for a while and the status has settled down and no longer prefixes it with the hook name. I can make due to prefixing my error statuses by hand for now if I want that
[15:00] <kwmonroe> skay: i'm not entirely sure what you're asking -- are you having trouble setting/catching status in an amulet test?
[15:01] <kwmonroe> and yeah, +1 on blocked vs error (when you're actually blocked, of course :)
[15:01] <skay> kwmonroe: no. I was having trouble with the status appearing how I wanted it to
[15:01] <skay> kwmonroe: I was mistaken, end of problem.
[15:01] <kwmonroe> w00t - the end of a problem is the best part.
[15:01] <skay> kwmonroe: for a while, it looked like the status I had set was appended to "(upgrade-hook) <my status string>"
[15:02] <skay> carry on :)
[15:02] <kwmonroe> heh
[15:53] <ryebot> What does the offline story for juju look like?
[15:53] <ryebot> Are there any docs for offline installs?
[16:07] <bdx> I'm wondering about a story too, does lib-juju have support for JAAS (obtaining/discharging the macaroons) yet?
[17:23] <cory_fu> skay: The hook name prefix is just to indicate which hook is currently executing and should not be considered when matching status messages in Amulet
[17:24] <skay> ack
[17:24] <cory_fu> It's automatically added in the tabular format status by Juju, but isn't actually part of the message.  You can see the raw message with `juju status --format=yaml [application]`
[20:00] <razorz> Anyone seen an issue with using juju/lxd on an ubuntu server box hosted on an ESXi box and trying to do bridging? lol  I got it working last night on my home machine (bare metal) in like 5 minutes, but on this server, even after a clean install, it's still a mess..
[20:04] <bdx> razorz: ensure to set promiscuous to 'true"
[20:04] <bdx> on your esxi interfaces
[20:07] <bdx> razorz: and also on the vm interface too
[20:07] <bdx> not sure thats your problem
[20:07] <bdx> but thats where I would start
[20:15] <razorz> bdx: I'll check that, thanks
[20:15] <bdx> np
[21:30] <razorz> bdx: very possible promiscuous was the issue
[21:32] <bdx> razorz: cool, yeah .... I know its disabled by default, and an easy thing to miss. glad you got it working
[21:36] <razorz> bdx: I literally spent 15 hours on this.. creating new bridges, breaking LXD totally to the point I had to reinstall the OS and it was that dumb lol
[21:37] <bdx> razorz: lol oh man, at least you gave it a good go
[21:39] <bdx> razorz: "even after a clean install" - these were your key words
[21:39] <bdx> lol
[21:43] <bdx> razorz: I feel your pain with that though, I cant even count how many times that had bitten me with "clean installs" of esxi
[21:44] <razorz> bdx: well I've been so used to dealing with nothing but ESXi and basic Linux crap and of course windows.. and I do all the Cisco routing here as well. I thought i had a routing issue going on
[21:44] <razorz> and that I was oblivious to the way that Linux handles bridges
[21:44] <razorz> but when it worked at home in a few minutes I was dumbfounded.. then came here and did the exact thing and it timed out, wanted to punch my screens
[21:44] <bdx> haha, right