[01:36] I've done something slightly dumb; moved a juju controller/model, on lxd, to a new bridge. The containers have the right ip now, but the juju controller isn't accessible. It looks like the api websocket isn't listening on the new ip. === frankban|afk is now known as frankban [07:43] Good morning Juju world! [08:00] kjackal: hello! do you have a good example for peer relations? [08:00] hello admcleod, I guess the best would be ZK or spark [08:01] spark please [08:01] admcleod: Give me a sec to spot the respective [08:01] code [08:01] interface-spark-quorum? [08:05] admcleod: Here is the interface: https://github.com/juju-solutions/interface-spark-quorum/blob/master/peers.py [08:05] admcleod: Here is the interface: https://github.com/juju-solutions/interface-spark-quorum/blob/master/peers.py [08:05] thanks [08:06] admcleod: updating peers ends up here: https://github.com/juju-solutions/layer-apache-spark/blob/master/lib/charms/layer/apache_spark.py [08:07] admcleod: after going though the reactive part: https://github.com/juju-solutions/layer-apache-spark/blob/master/reactive/spark.py#L143 [08:07] kjackal: i wonder, why use unit scope and not global for peering? [08:07] admcleod: https://github.com/juju-solutions/layer-apache-spark/blob/master/lib/charms/layer/apache_spark.py#L294 [08:07] admcleod: that is a good question! [08:08] admcleod: not sure I have a good answer [08:09] or service [08:33] kjackal: looks like UNIT is what it should be. im trying to do something really simple, just setting a state (conv.set_remote('thing', True) and then trying to read it back (a = conv.get_remote('thing') [08:34] kjackal: but it keeps returning None and im sure its something simple. got a good example of this? [08:35] admcleod: you want all nodes to agree on a remote 'thing'? [08:35] kjackal: yep [08:36] admcleod: have you consedered using the leadership layer? [08:36] yes, but this should work no? [08:37] yes, peers should work as well but I feel you will be coding the same logic that you can find in leadership [08:37] thats fine [08:37] admcleod: let me look at the zk layer, It might be easier [08:39] kjackal: i want the leader to be able to set 'is_leader, True', which all other peers should be able to see - that bit i could do with leadership. but i also want all other peers to set a state, "non-leader ready" [08:40] admcleod: looking at the zk quorum there is not magic: https://github.com/juju-solutions/interface-zookeeper-quorum/blob/master/peers.py#L55 [08:41] admcleod: give me a sec for the non-leader state, I have seen an example [08:42] admcleod: here is how kubernetes-master figures out if it is the leader: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L145 [08:43] admcleod: and here is what happens if it is not: https://github.com/kubernetes/kubernetes/blob/master/cluster/juju/layers/kubernetes-master/reactive/kubernetes_master.py#L191 [08:44] I think you should have something like "when_not('leadership.is_leader') [08:44] def nonleader(): [08:44] set_state('non-leader') [08:44] status_set('active', 'non-leader ready')" [08:44] admcleod: ^ [08:45] kjackal: right.. yeah... but [08:45] kjackal: when_not leader, i want to set something.. like "ok im ready". [08:46] kjackal: then once all the other nodes have set ready, the leader can do action [08:48] admcleod: I see... this is tricky... how would you know that all your non-leaders are up? What if you have some non-leader pending provision? [08:48] kjackal: it gets a list of all other nodes (it knows its the leader). it checks if those other nodes had set a state (ready). if it hasnt, it waits === firl_ is now known as firl === stormmore is now known as Budgie^Smore [08:57] kjackal: anyway. i guess the thing here is... for me, set_remote and get_remote dont appear to be working as id expect [09:00] admcleod: The thing that needed some care when we were doing these interactions was that we would have to use conv.set_state('my_state') to signal the other side that something has changed https://github.com/juju-solutions/interface-zookeeper-quorum/blob/master/peers.py#L31 [09:01] ah. [09:01] admcleod: after that the other end would have to go and do a get_remote('whatever') [09:02] admcleod: basicaly you should model the message enchange "protocol" using conversation states [09:02] kjackal: told you it was somethign simple. thanks [09:02] admcleod: :) [09:58] kjackal: also, how do you force an update-status now? [10:04] kjackal: nvm [11:02] hey all! is the Joyent cloud still supported? [11:03] hey all! is the Joyent cloud still officially supported? [11:21] is there anything special I should know about using Juju with MAAS? [11:22] used to work just fine up until I removed the model and tried to redeploy the environment [11:22] now it doesn't boot the servers and I don't see anything in the logs [11:48] Diabelko: can you still play with the nodes via MaaS? [12:37] joedborg: Joyent should be still supported [13:15] kjackal: seems that apt fails now [13:25] joedborg: how does it fail? At which point? === lazyPower is now known as lp|swap === freyes__ is now known as freyes [14:57] kjackal: turns out its a problem with the function im calling after i set the state (with set_remote) - it seems as if, since its in 'executing' state, the state i sent hasnt been committed.. and there doesnt seem to be a flush that applies to set_remote [16:03] tvansteenburgh, petevg, stokachu (and anyone else who feels like reviewing): https://github.com/juju/python-libjuju/pull/102 when you have a chance [17:15] lp|swap, what you swaping today? === frankban is now known as frankban|afk [17:45] stormmore: Yes he is. Is there something I can help you wiht? [17:58] mbruzek, not at the moment, thanks though :) just wanted to let him know that I think I figured out the last "bug" I came across with regards to seeing old replicasets for heapster [17:59] Was there any code change needed? (hint: I am working on our next release) [18:00] mbruzek, no I think based on what I am seeing elsewhere, it is working as designed. [18:00] mbarnett, the "problem" (hence the confusion) is that heapster ends up with 3 replicasets but only 1 which has running containers [18:01] mbruzek, no code needed I think based on what I am seeing elsewhere, it is working as designed. [18:01] stormmore: OK glad to read that. If you need anything in the next release please let me know [18:02] mbruzek, in testing deployments of my own services, it would appear that this is the design so that it makes it easier to roll back [18:03] hi guys [18:03] i have a problem with python-jujuclient and juju ha and maybe you can help me [18:04] jamespage: Hey, thanks for the reply! Could you resend that message? I didn't have chat logging turned on until now >_< [I got a notification that said, "Actually that's a charm bug that's been...", but I didn't have enough scrollback] [18:04] we run juju 2.0.1 with 3 state machines in ha [18:05] we have a custom python code that uses python-jujuclient to deploy a bundle and then use juju.watcher to monitor the deployment untill it is finished [18:06] the problem is that sometimes after a bundle deployment, jujuclient tries to reconnect to a watcher [18:06] https://paste.ubuntu.com/24307892/ [18:06] here is a paste of the error [18:06] iḿ not that good with python but as i understand there is no ´connector´ instanciated in jujuclient code when the reconnect occurs [18:07] there is a bug opened in december 2016 with the same problem, it seems this only occurs in a juju ha env [18:08] this bug https://bugs.launchpad.net/python-jujuclient/+bug/1639104 is similar to what we expirience [18:08] Bug #1639104: can no longer deploy to model: 'error': 'shared state watcher was stopped'

[18:12] any suggestion will be greatly appreciated :) [18:16] mcapsali1: the best suggestion i can give is to submit a patch for the bug [18:17] mcapsali1: or you can try using the new python client [18:17] mcapsali1: python-jujuclient isn't gonna get much love going forward [18:18] mcapsali1: https://github.com/juju/python-libjuju [18:19] mcapsali1: I should note, though, that I think that also has an issue with reconnects (issues #98 and #99) [18:20] iĺl take a look into that [18:20] did not know there was a new python client [18:20] ty everyone [18:21] i will get back if i run into same problem is the new client :) [18:24] mcapsali1: It seems like the connector call ought to be picking up https://bazaar.launchpad.net/~juju-deployers/python-jujuclient/trunk/view/head:/jujuclient/juju2/environment.py#L21 [18:24] cory_fu: it's a Watcher though [18:24] i think there are just missing connector properties on the juju1 and juju2 Watcher subclasses [18:25] tvansteenburgh: Hrm. I figured the Watcher would need to be based off the correct Environment for the correct version of Juju? [18:25] I see [18:25] So it might be enough to copy that connector method to the Watcher class there? [18:26] yeah