[05:20] A juju bootstrap got interrupted (failed connecting to the newly provisioned server via ssh due to a bad known_hosts entry), can I continue it or do I have to re-provision the server from scratch? [05:45] haasn: I think it's best to re-provision. It'll be hard to know how far it got and how best to recover. [07:18] https://twitter.com/search?q=%23cfgmgmtcamp&src=typd [08:48] Is it Juju's official error handling strategy that when something goes wrong, you nuke and start over again? [08:50] I'm running into errors like services being stuck on “failed hook” or machines being stuck on “pending” forever [08:50] At an alarmingly often rate [08:50] And every time there does not seem to be a reliable solution other than nuking everything and starting over, at least in terms of the stuff I added [09:07] haasn: you can try 'juju resolved --retry' https://jujucharms.com/docs/1.25/authors-hook-errors [09:19] haasn: For 'pending' stuckage, juju destroy-machine --force {machineno} is your best bet. I get this a lot with Juju 1.25 and the lxc provider. [09:19] haasn: For 'failed hook', 'juju resolved --retry unit/42' is your only option unless you want to debug the charm. [09:44] haasn: no, that is not juju's official error handling strategy. [14:37] Hi [14:38] How do i know last unit in the relation-joined? [14:39] without using relation-list [14:43] sharan: there's no way to really know since the model is always mutating. At anytime a user could add or remove unit and you no longer have a "last" unit :) [14:57] marcoceppi: ok, so we are not able to find the last unit :( , if user adds only 4 units and he will not perform any operation by add or removing unit. At this scenario is their any possibilities?? [14:58] sharan: no, not really. Juju is a fluid system there really is no expectation of idempotent state. What are you trying to solve ultimately? [15:03] marcoceppi: in my Websphere extreme scale(WXS) charm i need to restart the server every time when it has a peer relation with another WXS. I am stopping the server if server is started in relation-joined and again starting the server in relation-changed hook. [15:05] marcoceppi:is this the right way to restart the server? [15:06] sharan: yeah, there's really nothing you can do at this point except to use something like leadership to help coordinate. You can't really use relation-list because that's not a continued state of the environment and won't show all 4 right off the bat [15:18] marcoceppi: you mean leadership concept is better over the relation-joined and relation-changed for restarting the server whenever it has a peer relation. [15:18] sharan: possibly, what information do you need in the peer relation? [15:29] marcoceppi: is it possible to have peer relation between 2 products? i mean 1 product have peer relation and second product also have peer relation, is it possible to have again a realtion between these products? [16:14] how hard is it to have two separate charms relate to the same database in Postgres? [16:20] icey: not very [16:21] I just ran into an issue where the 2nd relation added did not have roles to acces the database -_- [16:25] icey: thta's weird [16:25] * marcoceppi takes a look [16:25] marcoceppi: trying to have the charm add roles as well as request the given database now [17:59] Marco, after last weeks juju charm summit I failed to get juju to work https://bugs.launchpad.net/juju-gui/+bug/1542652 [17:59] What can I do in the mean time to get started with juju? [17:59] Bug #1542652: juju-gui hangs on "Connecting to the Juju environment" [18:01] smartbit: you don't really need the gui to use Juju. If you ssh into the vagrant box you can just "juju status" or issue any other of the juju commands to start interacting with the environment [18:03] I understand, but would like to get a hands-on with it. Particular on juju 2.0 alpha. [18:04] hands-on with the GUI [18:04] smartbit: hum, if you'd like you could apply here: https://developer.juju.solutions and we can give you AWS cloud run time [18:05] smartbit: that way you won't need to use vagrant and the GUI will work there [18:05] seems resonable. I'll take the AWS route for now. [18:11] stub: retry on the unit just gave me the same error again, I had to physically destroy the machine it was on (because there's no way to force-destroy a unit afaik) and everything it was connected with and start over from scratch. Also “juju destroy-machine --force” is my definition if nuking it and starting over [18:13] Especially when it means I'm trying to deploy, say, the “openstack-monitoring” solution, and afaik there's no way to “partially” add that solution except painstakingly and by hand, so I have to nuke every other service and start from scratch again [18:13] .. and of course if another machine gets stuck on ‘pending’ the second time around, again [18:13] and so on [18:13] It just doesn't seem like a very reliable design [18:18] marco: submitted the request [18:22] smartbit: you should have an email in a few mins [20:05] randleman: hi there, are you going to be at IBM Interconnect === natefinch is now known as natefinch-afk [20:57] asanjar o/ [20:58] hi lazypower|travel, how are you my friend [20:58] Really good :) bumming around in Oxford UK on mini-cation. Dropped in to check messages [21:02] lazypower|travel: wow Mr. traveler [21:02] Tryin anyway :) [21:03] lazypower|travel: are you enjoying the weather? you must go to an EPL game [21:04] Well, I saw a Rugby match yesterday at the pub where I went to watch an ice hockey game. The weather has been miserable since I arrived, but thats to be expected for the time of year [21:56] stub: you about? [22:49] Hmm. I can so reliably reproduce this issue that I'm really struggling to think of what's going on [22:50] Basically I add a machine in juju (configured with a MAAS environment). It acquires a node and starts deploying it, and the deployment process completes + the machine shuts down afterwards [22:50] And.. that's it [22:50] The machine never turns itself back on, and even if I turn it on manually again juju just sits there and does nothing [22:50] it's supposed to ssh into the machine and start running apt updates etc. [22:50] and it works on some machines, just inexplicably not others. The ones it fails on are all VMs, but I'm not sure if that's just a coincidence [22:51] but it _has_ worked on VMs just fine, too [22:51] seems pretty random [22:59] Hmm, I think I'm getting closer: ssh into the machine and `sudo reboot` also does not work, it just shuts down