[07:31] <kjackal> hi ak_dev, are you ok with the peer relation problems? Reading your post on the ovn issue
[09:53] <anrah> Is there a way to mock reactive-decorators when writing unit-tests for charms?
[09:54] <anrah> I mean by that that somehow to write test without actually deploying the unit to make sure that spesific method is called
[10:11] <ak_dev> kjackal: hey, sorry had to go out for classes
[10:12] <ak_dev> I still have an issue there, are you free to talk?
[10:12] <armaan> jamespage: hello, i have deployed mitaka and just noticed that neutron.conf in compute and network node starts with #kilo line while neutron.conf in neutron-api container starts with #mitaka
[10:12] <armaan> jamespage: Is that intentional?
[10:13] <jamespage> armaan: that line indicates the earliest release that version of the template that generate the file supports
[10:13] <jamespage> so its not always the same as the series you're deploying
[10:14] <armaan> jamespage: ok. I asked because all agents logs are filled with either rabbit timeout messages or pymysql db errors. I can spawn VMs but i cannot ping them
[10:15] <armaan> jamespage: The rpc messages are very similar to this bug https://bugs.launchpad.net/oslo.messaging/+bug/1338732
[10:15] <mup> Bug #1338732: Timed out waiting for a reply via rabbit <icehouse-backport-potential> <in-stable-icehouse> <in-stable-juno> <verification-needed> <Ubuntu Cloud Archive:Fix Released> <oslo.messaging:Fix Released by sileht> <oslo.messaging (Ubuntu):Fix Released> <oslo.messaging (Ubuntu Trusty):Fix
[10:15] <mup> Released by james-page> <oslo.messaging (Ubuntu Utopic):Won't Fix by niedbalski> <oslo.messaging (Ubuntu Vivid):Fix Released> <https://launchpad.net/bugs/1338732>
[10:17] <kjackal_> ak_dev: I am here!
[10:18] <ak_dev> kjackal_: hey great! So the issue is with me getting stale data over the relation
[10:18] <ak_dev> just a sec
[10:19] <ak_dev> this is the interface : https://github.com/AakashKT/ovn-kubernetes-charm/tree/lenovo-pod/interfaces/master-config
[10:19] <ak_dev> the setup works fine with one master / OVN and one worker / OVN
[10:19] <ak_dev> OVN being the subordinate to master and worker
[10:20] <ak_dev> and I am using the above interface to pass some data from master OVN to the worker OVN
[10:20] <ak_dev> the data being sent is for that particular worker instance
[10:20] <kjackal_> wait up ak_dev this does not sound right
[10:21] <ak_dev> kjackal_: oh alright, did I follow a wrong approach?
[10:21] <kjackal_> the peer relation is for a relation established among units of the same application
[10:22] <kjackal_> for example if you have many masters and you want them to talk to eachother one option is to use a peer interface
[10:23] <ak_dev> kjackal_: in this case, I will have many OVN units subordinate to either master or worker
[10:23] <kjackal_> if you have a master-worker relation you should be using an interface with provides/requires parts
[10:23] <kjackal_> ak_dev: can you show me where this interface is used?
[10:23] <ak_dev> kjackal_: oh, so I need to exchange data between different OVN charms
[10:23] <ak_dev> yeah
[10:24] <ak_dev> https://www.irccloud.com/pastebin/NHnDb9tG/
[10:24] <kjackal_> ah, that sounds better :)
[10:25] <ak_dev> ah okay :-)
[10:25] <ak_dev> I am not sure whether I have implemented the interface right, but I get the wrong data when I add another unit
[10:26] <kjackal_> ak_dev: you have a single ovn unit acting as a master to all the rest or are all ovn subordinates equal?
[10:27] <ak_dev> kjackal_: oh, we can set one to be master? I have not set anything as such, so all are equal
[10:27] <kjackal_> ok
[10:28] <ak_dev> https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L146
[10:29] <ak_dev> kjackal_: for the master side of the data
[10:29] <ak_dev> https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L389
[10:29] <ak_dev> https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L413
[10:29] <ak_dev> worker side
[10:37] <kjackal_> ak_dev: help me understand something
[10:37] <kjackal_> ak_dev: you start with a single ovn charm
[10:38] <kjackal_> ak_dev: you add a second peer and this causes the connected state to be set:https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/interfaces/master-config/peers.py#L109
[10:39] <kjackal_> then the worker side will send its data over https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L413
[10:39] <kjackal_> and will set the 'worker.cert.sent' state
[10:39] <ak_dev> kjackal_: yeah
[10:41] <kjackal_> ak_dev: then the master will recieve the data: https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L389
[10:42] <kjackal_> ak_dev: and will set the 'worker.data.registered' state
[10:42] <ak_dev> kjackal_: this part is for worker to receive data again from master
[10:43] <ak_dev> https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L146
[10:43] <ak_dev> here is where master receives the data just sent
[10:51] <kjackal_> ak_dev: ok I think I get it
[10:51] <kjackal_> ak_dev: so what goes wrong with this interface?
[10:51] <kjackal_> Some exception ?
[10:52] <ak_dev> no, so for the first two units, one subordinate to master and one subordinate to worker, this works fine
[10:52] <ak_dev> when I add another unit subordinate to another worker unit, things go wrong
[10:52] <ak_dev> here, by worker and master I mean kubernetes-worker and kubernetes-master
[10:52] <kjackal_> "go wrong" how?
[10:53] <kjackal_> ak_dev: what happens
[10:53] <kjackal_> ?
[10:53] <ak_dev> in the new unit, I get the same data that was sent to the first unit from master
[10:53] <ak_dev> now in the new unit, the state "worker.cert.sent" does get set
[10:55] <ak_dev> kjackal_: so I am not sure where its going wrong
[10:57] <ak_dev> is there any way you can connect via juju to my controller? I have this setup already, with the error
[10:57] <ak_dev> on GCE
[10:57] <ak_dev> kjackal_: ^^
[17:53] <tychicus> what is the difference between charms and bundles maintained by openstack-charmers vs openstack-charmers-next?
[17:54] <rick_h> tychicus: the -next are the in dev charms/bundles for the next release of openstack
[17:54] <rick_h> tychicus: they might include new charms for a new service in the openstack or new config/behaviors that are going to be setup/allowed to be tweaked
[17:54] <tychicus> ok, so those should be avoided for production environments
[17:55] <rick_h> tychicus: yes, they're useful for preparing for what's coming in the future but they're in dev
[17:56] <tychicus> rick_h: thank you. I will keep that in mind
[18:00] <tychicus> I am looking at adding the ceph fs charm https://jujucharms.com/ceph-fs/ to my existing ceph deployment.  the documentation mentions "In my example deployments on EC2 the following ceph.yaml will work:" I don't see the afore mentioned ceph.yaml, is there something I am missing?
[18:01] <rick_h> tychicus: not sure, beisner do you know about the ceph-fs stuff there? ^
[18:37] <beisner_> hi rick_h tychicus - looking at that ceph-fs doc issue now
[18:38] <beisner_> fyi, it seems to be erroneous line left in the readme
[18:41] <tychicus> beisner_: so I should just be able to juju deploy ceph-fs and juju add-relation ceph-fs ceph-mon
[18:43] <beisner_> tychicus - indeed.  the charms have config options which can be adjusted to fit your needs.  osd device names, for example.  also, whether or not to unmount ephemeral devices.
[18:44] <tychicus> right, I already have the ceph cluster up and running, just looking to add ceph fs
[19:46] <beisner_> i've raised a docfix review to remove that bit of confustion on the ceph-fs charm.  thanks for raising that here, tychicus & rick_h
[19:46] <beisner_> confusion, even ;-)