=== frankban|afk is now known as frankban | ||
kjackal | hi ak_dev, are you ok with the peer relation problems? Reading your post on the ovn issue | 07:31 |
---|---|---|
anrah | Is there a way to mock reactive-decorators when writing unit-tests for charms? | 09:53 |
anrah | I mean by that that somehow to write test without actually deploying the unit to make sure that spesific method is called | 09:54 |
ak_dev | kjackal: hey, sorry had to go out for classes | 10:11 |
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:12 |
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:13 |
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:14 |
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:15 |
kjackal_ | ak_dev: I am here! | 10:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
ak_dev | https://www.irccloud.com/pastebin/NHnDb9tG/ | 10:24 |
kjackal_ | ah, that sounds better :) | 10:24 |
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:25 |
kjackal_ | ak_dev: you have a single ovn unit acting as a master to all the rest or are all ovn subordinates equal? | 10:26 |
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:27 |
ak_dev | https://github.com/AakashKT/ovn-kubernetes-charm/blob/lenovo-pod/layers/ovn/reactive/ovn.py#L146 | 10:28 |
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:29 |
kjackal_ | ak_dev: help me understand something | 10:37 |
kjackal_ | ak_dev: you start with a single ovn charm | 10:37 |
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:38 |
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:39 |
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:41 |
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:42 |
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:43 |
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:51 |
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:52 |
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:53 |
ak_dev | kjackal_: so I am not sure where its going wrong | 10:55 |
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_: ^^ | 10:57 |
=== 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 | ||
tychicus | what is the difference between charms and bundles maintained by openstack-charmers vs openstack-charmers-next? | 17:53 |
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:54 |
rick_h | tychicus: yes, they're useful for preparing for what's coming in the future but they're in dev | 17:55 |
tychicus | rick_h: thank you. I will keep that in mind | 17:56 |
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:00 |
rick_h | tychicus: not sure, beisner do you know about the ceph-fs stuff there? ^ | 18:01 |
beisner_ | hi rick_h tychicus - looking at that ceph-fs doc issue now | 18:37 |
beisner_ | fyi, it seems to be erroneous line left in the readme | 18:38 |
tychicus | beisner_: so I should just be able to juju deploy ceph-fs and juju add-relation ceph-fs ceph-mon | 18:41 |
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:43 |
tychicus | right, I already have the ceph cluster up and running, just looking to add ceph fs | 18:44 |
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 ;-) | 19:46 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!