=== CyberJacob is now known as zz_CyberJacob [07:48] Good morning Juju world! [09:33] hi everybody, does somebody have exp with riftio and juju? [10:50] Hi guys! [10:51] I have a strange issue, after reboot I can't see my juju status :( [10:51] 10:50:43 INFO juju.api apiclient.go:535 dialing "wss://10.190.134.11:17070/model/23ab79f9-57dc-41cc-8ecf-d367885d750e/api" [10:51] this is what i see from the debug, so probably one of the controllers changed IP? === freyes__ is now known as freyes [14:53] when I perform a deploy, is it the machine from which I am running the 'juju deploy' command that downloads the charms, or is it the controller machine? [14:54] vmorris: the controller [14:55] tvansteenburgh: ty [14:58] Spaulding: hey have you found an answer/root-cause/work-around to your troubles with juju status? [14:59] lazyPower: it's test env... so basically i removed the old env [14:59] and bootstrap new one [14:59] ok. so long as its resolved :) [14:59] yeah ;) [14:59] but still it was strange [15:00] looks like jujud was not able to start... [15:00] Spaulding: - capturing those logs and reproduction steps in a bug would go a long way to help resolving it. [15:01] next time lmk and i'll be happy to step you through what to do in that scenario [15:03] sure! [15:03] i think the problem was that i rebooted the machine after apt upgrade [15:03] and probably i should run something like juju upgrade [15:04] juju upgrade-juju [15:28] howdy marcoceppi - do you know the eta for a libcharmstore 0.0.5 cut @ pypi? [15:28] beisner: 5 mins [15:28] too fast, slow her down man [15:40] lazyPower: hey, are you there? [16:38] hackedbellini: yep hey there [16:53] thanks, marcoceppi [17:03] marcoceppi: good morning [17:03] marcoceppi: do you think we should remove k8-core from cwr? I made https://github.com/juju-solutions/build-cloud/pull/81 [17:04] given canonical-kubernetes is the main bundle and these charms and solution context is addressed there. [17:12] arosales: why remove it? [17:13] marcoceppi: well seems that testing is handled in canonical-k8 [17:13] it's a different toplogy, with different scale and different (less) components [17:13] unless there is different test scenerios in that bundle [17:13] it's a different scenario under test [17:14] thats fair, could you comment on the pull and I'll reject? [17:14] marcoceppi: also I think you guys were working on getting that bundle also updated with the latest correct? [17:14] looks like it still may be failing on the flake tests [17:16] ref = http://data.vapour.ws/cwr-tests/results/bundle_kubernetes_core/fd135530b9e94084992706899d0040ac/report.html [17:17] arosales: the bundle needs to be revv'd and it will be in due time as part of the release cycle [17:19] marcoceppi: gotcha, I was thinking it was just missed as part of the release last week when canonical-k8 was updated [17:19] well, canonical-k8s release was rushed due to preassure. so it was done out of band [17:20] * arosales can be patient until the next release those as we see the correct link in the canonical-k8 bundles [17:20] marcoceppi: cool -- thanks for the update [17:48] Good morning. Brand new install and trying to get conjure-up working again (sigh). This time I see that autopilot is an option. Tried that route and it failed because juju was not bootstrapped [17:48] i bootstrap juju to localhost with "maas" and it deploys, but not conjure-up fails [17:48] one day this will work! [17:49] but right now i want to take a hammer to all these charms [17:59] bildz: what are you trying to conjure-up? [18:00] im trying to start fresh with an environment [18:00] openstack [18:00] where does juju get configurations options to bootstrap? [18:01] is it in the postgres database for maas? [18:01] you, the operator, supplies them [18:02] Performing bootstrap: ant maas/http://10.9.9.11/MAAS [18:02] that's the wrong ip [18:02] and i have no idea where it's getting that [18:06] error: flag provided but not defined: --upload-tools [18:06] stokachu: ^^ === Richard is now known as Guest89712 [18:22] I need help with a Juju, conjure-up, Openstack deployment issue [18:23] After deployment I have an openstack0 and a conjureup0 interface with the same IP address [18:24] marcoceppi: arosales: https://github.com/juju-solutions/bundle-kubernetes-core/pull/39 [18:26] stokachu: ^^ [18:27] lazyPower: thanks === zz_CyberJacob is now known as CyberJacob [18:28] arosales: np, sorry it slipped through. There was some undue pressure last week to make an early release and that got left behind [18:28] RIP [18:30] lazyPower: no worries.i was mainly just confirming my understanding. Thanks for the work on it [18:31] lazyPower: sorry for the delay. I was in a meeting until now and am going to go to another one. I'll probably be back to redmine tomorrow. In the mean time, just to give you the actual state: [18:32] both the containers are having "executable file not found in $PATH" issue. I tried to run docker-compose by hand and this is what I got: [18:32] https://www.irccloud.com/pastebin/Xiq9xl0h/ [18:33] hackedbellini: one of two things has happened. The containers themselves are broken and no longer work how they did when that compose file was written, or the compose file is overriding some stuff and causing the failure [18:33] not sure which, we'll need ot dive into it deeper to figure out whats up [18:34] lazyPower: hrm I see. That is strange... the composer file looks like this right now: [18:34] https://www.irccloud.com/pastebin/1St1nbOd/ [18:35] how do you install juju 2 on trusty? [18:35] the issue happened even trying other versions (e.g. postgres:9.5) and even using the one from https://github.com/sameersbn/docker-redmine [18:35] hackedbellini: it might even be better if we start from scratch and build a RedMine container ourselves. The idea being: We control the inputs/outputs so we know how long something will work, and can make those decisions for the containers as it evolves, but the charm code would largely say the same. [18:36] tvansteenburgh: i believe you add the juju/stable and juju/devel ppas, and install the juju-2.0 package [18:36] but i haven't tried this so ymmv [18:36] using juju/stable, installing juju gets you juju1, and juju-2.0 doesn't exist [18:37] tvansteenburgh: this bug from last month looks like it did at one point and time exist https://bugs.launchpad.net/juju-release-tools/+bug/1633593 [18:37] Bug #1633593: [juju-2.0] trusty package doesn't install juju-2.0 commands via update-alternatives

[18:39] Guest89712: hello [18:39] lazyPower: hrm I see. It is a nice idea indeed [18:39] I have to go now to the other meeting, tomorrow I'll ping you again to continue from when we stopped :) [18:40] stokachu: are spells versioned? If so is there a quick way to see what spell one is using? [18:40] hackedbellini: sounds good. Glad we're making progress but sorry its taking so long [18:47] Guest89712: what is the conjure version you are using, ie out out of `conjure-up --version` [18:48] Checking [18:49] conjure-up --version conjure-up 2.0.2 [18:51] Guest89712: thanks and what does `dpkg -l | grep conjure-up` return? [18:53] arosales # dpkg -l | grep conjure-up ii conjure-up 2.0.2-0~201610141215~ubuntu16.04.1 all Package runtime for conjure-up spells [18:55] Guest89712: thanks, it looks like the latest is 2.0.2-0~201611211448~ubuntu16.04.1, as a data point [18:56] I would need to check with stokachu if there were any openstack fixes between 201610141215 and 201611211448 [18:56] * arosales looking at spell info atm Guest89712 [18:56] for openstack specifically [19:00] Guest89712: could you pastebin the outout of 'journalctl |grep conjure-up' [19:03] arosales Can you read: http://pastebin.com/FQpbBenk [19:06] Guest89712: thanks [19:09] stokachu: I am reading through http://conjure-up.io/docs/en/users/ but I am not finding a place tell which version of a spell I am running on or if I need to refresh my spell registry? I am guessing conjure-up runs the latest spell from the registry on each summon, correct? Or are spells version'ed per conjure-up binary version? [19:10] stokachu: working with Guest89712 on openstack0 and a conjureup0 interface with the same IP address [19:54] arosales: yea the latest spells are used from the registry [19:54] arosales: no way to set a version to be used [19:57] stokachu: independent of conjure-up binary version the latest spell is used from the registry @ https://github.com/conjure-up/spells correct? [19:57] arosales: yea thats correct [19:58] arosales: what channel are you in for that guest89712 person [19:58] stokachu: ok thanks, and did you have any openstack fixes on nova-lxd between conjure-up versions 201610141215 and 201611211448 ? [19:59] arosales: lemme check [20:00] stokachu: thanks [20:05] arosales: https://github.com/conjure-up/conjure-up/commit/50f4899 that was the only major thing [20:05] we added the custom bridge to our packaging [20:05] and the spell makes use of conjureup0 bridge device for openstack-novalxd [20:06] anyone else seen... [20:06] lutostag@cia:~$ juju models [20:06] ERROR cannot list models: upgrade in progress (upgrade in progress) [20:06] arosales: oh something is wrong with the latest lxd charm [20:06] lemme look into it [20:09] stokachu: thanks Guest89712 was seeing an issue where openstack0 and a conjureup0 interface with the same IP address [20:10] lutostag: sthat's a new one for me [20:10] arosales: maybe he installed an older conjure-up and then upgraded [20:10] arosales: there should only be conjureup0 [20:10] arosales: openstack0 was from like conjure-up 0.1.2 [20:11] stokachu: Guest89712 has 201610141215 currently installed http://pastebin.com/FQpbBenk [20:11] arosales: yea he upgraded from an older version it looks like [20:11] arosales: what channel is this in? [20:12] stokachu: sorry I didn't parse the last comment [20:13] arosales: so the package in the archive conjure-up 0.1.2 was setting up openstack0 as a bridge [20:13] arosales: in the next release of conjure-up (2.x) we renamed that to conjureup0 as the bridge [20:13] so it looks like the old bridge is still on their system [20:13] they need to remove openstack0 bridge [20:16] stokachu: ah, thanks for that insight [20:16] np [20:16] arosales: i also fixed the lxd charm issue too [20:16] arosales: so if they want to redeploy it should all be good [20:16] Guest89712: ^ fyi remove the openstack0 bridge, and if you are going to redeploy you may want to run "sudo apt update && sudo apt install conjure-up" [20:17] stokachu: good stuff, but Guest89712 needs to manually remove openstack0 bridge first, correct? [20:17] arosales: yea they'll need to do that manually [20:17] im going to file a bug to make sure the packaging does it [20:17] stokachu: ack --thanks [20:17] stokachu: also is there a good place I can look for change logs to conjure, or should I just look at the .deb package? [20:18] arosales: the changelog is usually just high level stuff, best place is to check git log [20:19] oh [20:19] arosales: https://github.com/conjure-up/conjure-up/releases [20:19] i also try to keep a good list here [20:19] stokachu: ah perfect. I should have look there first [20:19] thanks for the help stokachu. Guest89712 ^ that should fix you, and thanks for the feedback [20:20] np, lemme know if you need anything else [20:22] stokachu: thanks [20:42] I want to write a mojo spec that deploys a charm that needs to be deployed with a resource. would I pass some keyword args to the deploy command in my manifest? [20:42] on the command line, juju deploy --resource = [21:43] is there a way for me to tell if a resource has been updated, e.g. if I attach a new version of a resource [21:48] skay_: `juju resources`? [21:51] marcoceppi: I'm not certain if that does what I want, let me try [21:52] skay_: mthaddon is the best one to talk to about mojo stuff [21:54] tvansteenburgh: I think mojo may not be able to handle resources, but I'm not certain. I opened an issue [21:54] tvansteenburgh: I think what I'll do to work around it is have a script that runs juju attach [21:54] the docs say that will kick off an upgrade-hook [21:55] I can use resource_get in my charm to see if a resource exists (resource_get is available in charmhelpers in hookenv) [21:55] I'd sort of like to know if there was actuall a new resources and just skip that part if there wasn't [22:50] skay_: you'll need to do fingerprinting [22:51] skay_: there's no other way to know if the resource has changed. as the method blindly returns a path to the resource its fetched and magic happens. In order to know in charm code you'll need to shasum the payload or something to determine if its changed from last run, and use that against a value stored in unitdata or some other means of caching. [22:52] lazyPower: ack [22:52] skay_: we were talking about adjusting the charm helper to just do that for you, and instead of returning the path, returning a tuple with path and fingerprint. But there's already a good size of code out there consuming the resource helper.