=== frankban|afk is now known as frankban [07:31] hi ak_dev, are you ok with the peer relation problems? Reading your post on the ovn issue [09:53] Is there a way to mock reactive-decorators when writing unit-tests for charms? [09:54] I mean by that that somehow to write test without actually deploying the unit to make sure that spesific method is called [10:11] kjackal: hey, sorry had to go out for classes [10:12] I still have an issue there, are you free to talk? [10:12] 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] jamespage: Is that intentional? [10:13] armaan: that line indicates the earliest release that version of the template that generate the file supports [10:13] so its not always the same as the series you're deploying [10:14] 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] jamespage: The rpc messages are very similar to this bug https://bugs.launchpad.net/oslo.messaging/+bug/1338732 [10:15] Bug #1338732: Timed out waiting for a reply via rabbit

Released by james-page> [10:17] ak_dev: I am here! [10:18] kjackal_: hey great! So the issue is with me getting stale data over the relation [10:18] just a sec [10:19] this is the interface : https://github.com/AakashKT/ovn-kubernetes-charm/tree/lenovo-pod/interfaces/master-config [10:19] the setup works fine with one master / OVN and one worker / OVN [10:19] OVN being the subordinate to master and worker [10:20] and I am using the above interface to pass some data from master OVN to the worker OVN [10:20] the data being sent is for that particular worker instance [10:20] wait up ak_dev this does not sound right [10:21] kjackal_: oh alright, did I follow a wrong approach? [10:21] the peer relation is for a relation established among units of the same application [10:22] 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] kjackal_: in this case, I will have many OVN units subordinate to either master or worker [10:23] if you have a master-worker relation you should be using an interface with provides/requires parts [10:23] ak_dev: can you show me where this interface is used? [10:23] kjackal_: oh, so I need to exchange data between different OVN charms [10:23] yeah [10:24] https://www.irccloud.com/pastebin/NHnDb9tG/ [10:24] ah, that sounds better :) [10:25] ah okay :-) [10:25] I am not sure whether I have implemented the interface right, but I get the wrong data when I add another unit [10:26] ak_dev: you have a single ovn unit acting as a master to all the rest or are all ovn subordinates equal? [10:27] kjackal_: oh, we can set one to be master? I have not set anything as such, so all are equal [10:27] ok [10:28] https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L146 [10:29] kjackal_: for the master side of the data [10:29] https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L389 [10:29] https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L413 [10:29] worker side [10:37] ak_dev: help me understand something [10:37] ak_dev: you start with a single ovn charm [10:38] 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] 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] and will set the 'worker.cert.sent' state [10:39] kjackal_: yeah [10:41] 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] ak_dev: and will set the 'worker.data.registered' state [10:42] kjackal_: this part is for worker to receive data again from master [10:43] https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L146 [10:43] here is where master receives the data just sent [10:51] ak_dev: ok I think I get it [10:51] ak_dev: so what goes wrong with this interface? [10:51] Some exception ? [10:52] no, so for the first two units, one subordinate to master and one subordinate to worker, this works fine [10:52] when I add another unit subordinate to another worker unit, things go wrong [10:52] here, by worker and master I mean kubernetes-worker and kubernetes-master [10:52] "go wrong" how? [10:53] ak_dev: what happens [10:53] ? [10:53] in the new unit, I get the same data that was sent to the first unit from master [10:53] now in the new unit, the state "worker.cert.sent" does get set [10:55] kjackal_: so I am not sure where its going wrong [10:57] is there any way you can connect via juju to my controller? I have this setup already, with the error [10:57] on GCE [10:57] kjackal_: ^^ === disposable3 is now known as disposable2 === zeus is now known as Guest75507 === Guest75507 is now known as zeus` === zeus` is now known as zeus === frankban is now known as frankban|afk [17:53] what is the difference between charms and bundles maintained by openstack-charmers vs openstack-charmers-next? [17:54] tychicus: the -next are the in dev charms/bundles for the next release of openstack [17:54] 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] ok, so those should be avoided for production environments [17:55] tychicus: yes, they're useful for preparing for what's coming in the future but they're in dev [17:56] rick_h: thank you. I will keep that in mind [18:00] 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] tychicus: not sure, beisner do you know about the ceph-fs stuff there? ^ [18:37] hi rick_h tychicus - looking at that ceph-fs doc issue now [18:38] fyi, it seems to be erroneous line left in the readme [18:41] beisner_: so I should just be able to juju deploy ceph-fs and juju add-relation ceph-fs ceph-mon [18:43] 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] right, I already have the ceph cluster up and running, just looking to add ceph fs [19:46] 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] confusion, even ;-) === rick_h changed the topic of #juju to: OUTAGE: jaas issue with add-model (https://lists.ubuntu.com/archives/juju/2017-July/009256.html) | #juju Juju as a Service Beta now available at https://jujucharms.com/jaas | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms