[00:27] kwmonroe: nope! i need the local kvm provider [00:27] and yacketty would make it more likely that upstart would break things, so no to that too :) [00:36] hallyn, s/juju.ubuntu.com/jujucharms.com/ :P [00:36] https://jujucharms.com/docs/1.25/reference-constraints [00:46] pmatulis: wish i could remember which blog i found that in, but i was looking through a lot of them last night... [00:46] pmatulis: thanks [00:46] (i had seen that page, doesn't have the info i need, but glad it answers that mystery :) [00:48] ;) [00:49] hallyn, kindly open a bug if the documentation is lacking - https://github.com/juju/docs/issues/new [00:55] lolz - i see, i can't use local kvm provider anyway without systemd. drat. [00:56] curses! [02:29] hallyn what are you working on that you need juju 1.25 and upstart bidniss? [02:41] 1.25 for local kvm provider [02:41] upstart bc i want upstart [02:41] ah ok. [02:41] I didn't know if you were kicking tires or were building the next cloud for your mobile DC :) === jog__ is now known as jog [03:35] nah in the cloud i leave system installed. upstart is just for battery life on my laptop [05:15] * hallyn wonders how much work it would be to implement a juju-2.0 version of libvirt-kvm (uvtool) provider [05:15] * hallyn wonders whether he could finagle rbasak into writing it [05:15] you know, to avoid uvtool become OBSOLETE. yeah, i'll goad him into it. bound to work [05:16] hallyn: As in, something that would allow us to just point juju at a libvirt host and juju deploy VMs? Because I totally want that. [05:17] yeah - which is basically how the local-kvm provider in 1.x works [05:17] There's a local KVM provider in 1.x? [05:17] except i suspect it's more complicatd than it needs to be [05:17] yup [05:17] How did I not know about this? [05:17] Where are my angry eyes? [05:17] you use local provider, and change type to kvm instead of container [05:17] one sec, [05:17] https://jujucharms.com/docs/1.25/config-KVM [05:17] no need for ppa though [05:18] just install juju-local and add that environments.yaml section [05:18] been beating on it for the last two days, pretty stable [05:18] hallyn: I think I love you. [05:18] [05:18] you'll love rbasak more when he writes a new uvtool based one for juju 2.0 [05:19] hallyn: I most certainly owe you a six-pack of $PREFERRED_BEVERAGE [05:19] well gawsh, all i did was find it not write it, but i'm not turning down $PREFERRED_BEVERAGE :) [05:20] Now all I have to do is work out how to get on a sprint you're on. You might be waiting for that sixer a while... ;-) [05:21] :) [05:21] And I most certainly will owe rbasak double if he does a juju 2 version. :-) [05:21] +1 [07:10] Good morning juju world! [07:30] SaMnCo: I am almost there === frankban|afk is now known as frankban [09:20] gday! [09:39] hallyn: AFAIK, it's a design decision for there not to be local KVM support in Juju 2. I'm told Juju still supports KVM via uvtool, just not in the local provider. [10:11] hi, I'm new to juju, I following the doc, and I tried to create a test charm using [10:11] 'charm create -t python mycharm' [10:11] but the lib dir was not created [10:11] any suggestions ? [10:13] Hi SDBStefano havent tried this template before. Let me give it a try now [10:16] Hi all, was here yesterday already... juju bootstrap on openstack with self signed certificate - cannot bootstrap, getting "signed by unknown authority" error with --debug [10:16] searching for some option --insecure like in nova [10:16] running rc3 version now [10:17] herb64: have you asked on #openstack-charms ? [10:17] hi, kjackal, no.. would this be the better place to ask? [10:19] herb64: I believe so, since your question is rather specific [10:20] SDBStefano: yeap it does not create a lib dir [10:20] SDBStefano: Why did you expect such a directory? Did you read this somewhere? [10:23] SDBStefano: this bug should be related: https://bugs.launchpad.net/charm-tools/+bug/1395560 [10:23] Bug #1395560: "create -t python " does not install lib/charmhelpers [10:28] hi kjackal_, first thanks a lot for helping, yes here : http://pythonhosted.org/charmhelpers/getting-started.html [10:33] I'm using : charm version charm 2.2.0-0ubuntu1~ubuntu16.04.1~ppa2 charm-tools 2.1.4 [10:40] so it seems to be a problem, not already solved, am I wrong ? [10:43] yeap, you are right SDBStefano [10:45] is there any other way to get the python library (charm-helpers) ? as a tar or something else [10:53] SDBStefano: what exactly do you need to do? There is the option to add it as dependency like we do here: https://github.com/juju-solutions/layer-basic/blob/master/wheelhouse.txt [10:54] SDBStefano: if you build your charm using layers you can just use the basic layer and you should be done [10:54] so, are you saying that I don't need the charm-helpers ? [10:54] if not, you should be able to add a wheelhouse.txt in your charm and the charm build process should bring the dependency in [10:55] SDBStefano: by using the basic layer you are importing the charmhelpers [10:55] so it seems that I have to proceed and see how to use charm layers [10:56] ok, thanks, I'm going to try [10:56] SDBStefano: layers is the recomended way. But if you do not want to use layers have a look at what the basic layer is doing [10:58] SDBStefano: for example https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L36 [10:58] I'm going to follow your suggestion and looking at how to use the layers [10:58] SDBStefano: yeap that is the right way to go, you will get alot of functionality for free [10:59] thanks a lot. out of curiosity I'm in Italy, where are you ? [11:00] Athens Greece [11:00] SDBStefano: We are almost on the same timezone, ping me again if you get into trouble === Guest10825 is now known as zeus` === zeus` is now known as zeus [13:38] kjackal - I was looking at https://jujucharms.com/docs/devel/authors-charm-building that talks about layers [13:38] but it describe bash scripts [13:39] but if I understood the good direction is having all python as the github you adviced [13:39] so is this doc https://jujucharms.com/docs/devel/developer-getting-started fine ? [13:39] or should I follow only the info within the github ? [14:00] rbasak: drat, if it's a design decision then i guess you can't get away with coding it (meaning i may have to). [14:01] rbasak: the claimed support is rubbish. having to manually create a vm, register it with juju, then tell juju to send a workload to it means i may as well use ansible [14:04] hallyn: does KVM support work with the manual provider? If so, then you could probably hack something together for a single machine KVM use case. [14:05] eg. by putting either the client or the "machine" in a container. [14:05] right. i was just trying to badger you into doing it :) [14:05] Then as far as Juju is concerned your manual provider machine is somewhere else, and you can create KVMs on it? [14:06] but really, using local kvm provider made my charm iteration way faster and cheaper, so this still isn't seeming like a step up for me. but, i'll figure something out (or stick with 1.x) - thx rbasak [14:07] my upgrade-charm hook froze so I killed it manually via the PID [14:07] now the state is in upgrading still [14:07] how do I reset the state of the unit? [14:11] SDBStefano: here is an example of layers in python https://jujucharms.com/docs/2.0/developer-layer-example [14:13] SDBStefano: this give a good description of what layers are: https://jujucharms.com/docs/2.0/developer-layers [14:24] looks like the hook has a timeout, it's now in an error state and I can recover it [14:33] http://i.imgur.com/yonlG9F.png I feel I'm almost there. Can someone take a look and let me know what may be able to get me past this issue? [14:34] http://pastebin.com/qBtDJsyd [14:35] i have 6 machines, do I need 7? [14:42] if I'm using the juju stable ppa on trusty.. how do I switch back to "juju 1"? [14:42] the instructions on first launch don't work [15:14] gQuigs i'm looking into this for you, 1 moment while i spin up a vanilla trusty image [15:20] gQuigs looks like the meta package has updated to 2.0, i'm not seeing a 1.x package anymore [15:26] so I guess the help text could say, if you want juju1.25 remove juju and the PPA and install it from trusty.. [15:28] gQuigs: that does appear to be the case. let me nuke this image and try again without adding the ppa [15:30] gQuigs - that does indeed install 1.25, i also see a juju-core in this ppa enabled image too... that may be the 1.25 we're looking for [15:37] gQuigs with that ppa enabled, if you install juju-core, you will get 1.25 [15:51] lazyPower: intersting.. yup, I had to remove juju-2.0 juju juju-core [15:51] and then reinstall juju-core and I'm back to 1.25 [15:51] lazyPower: thanks! [15:51] gQuigs at one time you could update-alternatives, i'm not certain thats still the case [15:52] but you can, and should be able to use juju 1.x and juju 2.x side by side on the same system. I know that marcoceppi does this, and he may have some insights on how you can do this that we should capture and put in the docs. [15:52] should there be a PPA specific helptext? [15:52] yea, I'm happy having separate machines for 1.x vs 2.x [15:52] gQuigs : what would the help text say? [15:53] lazyPower: currently it says this: http://pastebin.ubuntu.com/23324079/ [15:54] ahhh yeah thats stale [15:54] thank you for capturing that. I'll file a bug [15:54] so I'd say, We've detected you are using the PPA, please remove juju juju-2.0 juju-core and reinstall just juju-core, or whatever it needs to make it work [15:55] gQuigs as you've got the primary information on how you arrived from A-Z would yo mind terribly filing the bug? https://bugs.launchpad.net/juju/+filebug [15:55] if they route through me, i wont have all the details you've got, so its better if you take stakeholder on the bug [15:55] lazyPower: I was about to say I can file it :) [15:55] perfect :) Thanks for tracking this down. [15:56] lazyPower, gQuigs: please open a docs issue with the relevant info to have a docs change - https://github.com/juju/docs/issues/new [15:57] pmatulis: oh is that a docs bug? [15:58] the help text in juju? [15:58] pmatulis you bet, i'll xref w/ the core bug. [15:58] that way if any action needs to be taken on either side we have a work order for it [16:01] reported - https://bugs.launchpad.net/juju/+bug/1633542 [16:01] Bug #1633542: Juju 2.x upgrade [ppa] doesn't show a workable way to downgrade to 1.25 [16:02] should I report to gh to? [16:02] gQuigs - Certainly, xref that core bug as I imagine the steps to fix will be posted there and pmatulis or i can circle back afterwords and cleanup the docs [16:07] do I need more permissions to link them? (I can ling ubuntu bugs to other trackers...) [16:07] gh is https://github.com/juju/docs/issues/1470 [16:08] thanks for the bugs gQuigs, just putting in the link is enough. === frankban is now known as frankban|afk [17:11] if i have an empty .jenv file, preventing bootstrap, how should i re-init a new one? [17:11] (if i just delete it, then juju bootstrap panics) [17:27] oops, nm, had to s/_/-/ in google-provided creds for juju [17:28] (which juju should probably know about and just dtrt) [18:39] can i specify which machine in MAAS the juju controller will deploy to? === vance is now known as vmorris === vmorris is now known as vance === vance is now known as vmorris [18:41] vance, with juju 2, when you're bootstrapping you can use --to [18:42] jhobbs: thanks, i was just reading that in the docs. appreciate it === perrito667 is now known as perrito666 === Spads_ is now known as Spads === xnox_ is now known as xnox === thomi_ is now known as thomi === iatrou_ is now known as iatrou === cppforlife__ is now known as cppforlife_ === wolsen_ is now known as wolsen === freyes__ is now known as freyes === yo61_ is now known as yo61 [19:57] tvansteenburgh, bcsaller, petevg: Reviews welcome on my two PRs on theblues: https://github.com/juju/theblues/pull/46 and https://github.com/juju/theblues/pull/47 [19:57] Cool. Taking a look ... [19:58] petevg, bcsaller: Also, tvansteenburgh talked me into cowboying it in, but my changes to support bundle deploys in libjuju is at https://github.com/juju-solutions/python-libjuju/commit/fd2a74a2eba716e7ea298fe420f070221ff4581f [20:12] bcsaller, cory_fu: I'm realizing that there's a good reason for the glitch tests to run outside of the matrix right now: I'm manually spinning up the model in the tests, and attaching it to a mock object that I'm using as a context. There's more integration work to be done outside of glitch before the glitch tests can just run things in the matrix. [20:12] It's relatively small integration work, but I think that I'd like to ultimately keep it in a separate commit -- that PR is already huge. [20:13] What say you two to giving a +1 on merging the glitch branch, and then I'll create a new branch for integration? [20:14] petevg: let me do a quick pass over it, but yeah, that will be fine [20:15] Cool. I'm creating the integration branch right now -- I'll just rebase when/if you give the go ahead to merge the glitch branch. [20:23] bdx, hi, are you around? [20:27] mtr green.5thcolumn.net [21:04] petevg, bcsaller: Any objection to me moving all of the existing plugins (currently under tests/; save maybe for chaos) to matrix/plugins/ and switching to using entry-points for discovering plugins? [21:04] cory_fu: no objection. I've already moved glitch there. [21:05] bcsaller: Your current implementation uses a dot-path resolver, but I feel like entry-points are both more standard and easier to maintain [21:06] But I'm up for arguments to the contrarry [21:06] *contrary [21:10] cory_fu: I am fine with entry points, maybe as well, but I find the dot-path style to be less friction [21:11] glitch has a main.py that can be renamed to __main__.py, and it also drops the stuff it wants to expose into __init__.py, so it should work w/ either method. [21:11] petevg: I am looking to merge your branch but have some changes I'd like to propose in code, I'll push a different branch in a bit, just wanted to let you know === verterok` is now known as verterok [21:12] bcsaller: cool. [21:12] petevg: I don't think main.py or __init__.py would matter to entry-points. [21:13] cory_fu: I thought that entry-points really liked to have a __main__.py; I am most likely just being wrong :-") [21:13] Nope [21:13] They just need a pointer in some module's setup.py [21:13] Got it. [21:14] bcsaller: Having a dotted-path resolver kind of makes entry-points moot. The purpose of entry-points was to make it so that everyone didn't have to implement their own dotted-path resolved. ;) [21:14] *resolver [21:15] cory_fu: the setup.py part bothers me, I see this being our std tests + some included in the bundles test dir from which we'd resolve an additional plugin [21:15] Plus to standardize how 3rd party libraries registered their plugins, so it wasn't just all ad-hoc [21:15] in that context there may not be a setup.py [21:16] Hrm. Yeah, fair enough [21:16] bcsaller: Ok, fine, I leave well enough alone. :) [21:17] ha [21:17] I was just tired of seeing yet-another-dotted-path-resolver-implementation