| hallyn | kwmonroe: nope! i need the local kvm provider | 00:27 |
|---|---|---|
| hallyn | and yacketty would make it more likely that upstart would break things, so no to that too :) | 00:27 |
| pmatulis | hallyn, s/juju.ubuntu.com/jujucharms.com/ :P | 00:36 |
| pmatulis | https://jujucharms.com/docs/1.25/reference-constraints | 00:36 |
| hallyn | pmatulis: wish i could remember which blog i found that in, but i was looking through a lot of them last night... | 00:46 |
| hallyn | pmatulis: thanks | 00:46 |
| hallyn | (i had seen that page, doesn't have the info i need, but glad it answers that mystery :) | 00:46 |
| pmatulis | ;) | 00:48 |
| pmatulis | hallyn, kindly open a bug if the documentation is lacking - https://github.com/juju/docs/issues/new | 00:49 |
| hallyn | lolz - i see, i can't use local kvm provider anyway without systemd. drat. | 00:55 |
| hallyn | curses! | 00:56 |
| lazyPower | hallyn what are you working on that you need juju 1.25 and upstart bidniss? | 02:29 |
| hallyn | 1.25 for local kvm provider | 02:41 |
| hallyn | upstart bc i want upstart | 02:41 |
| lazyPower | ah ok. | 02:41 |
| lazyPower | I didn't know if you were kicking tires or were building the next cloud for your mobile DC :) | 02:41 |
| === jog__ is now known as jog | ||
| hallyn | nah in the cloud i leave system installed. upstart is just for battery life on my laptop | 03:35 |
| * 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 | |
| hallyn | you know, to avoid uvtool become OBSOLETE. yeah, i'll goad him into it. bound to work | 05:15 |
| blahdeblah | 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:16 |
| hallyn | yeah - which is basically how the local-kvm provider in 1.x works | 05:17 |
| blahdeblah | There's a local KVM provider in 1.x? | 05:17 |
| hallyn | except i suspect it's more complicatd than it needs to be | 05:17 |
| hallyn | yup | 05:17 |
| blahdeblah | How did I not know about this? | 05:17 |
| blahdeblah | Where are my angry eyes? | 05:17 |
| hallyn | you use local provider, and change type to kvm instead of container | 05:17 |
| hallyn | one sec, | 05:17 |
| hallyn | https://jujucharms.com/docs/1.25/config-KVM | 05:17 |
| hallyn | no need for ppa though | 05:17 |
| hallyn | just install juju-local and add that environments.yaml section | 05:18 |
| hallyn | been beating on it for the last two days, pretty stable | 05:18 |
| blahdeblah | hallyn: I think I love you. | 05:18 |
| hallyn | <blush> | 05:18 |
| hallyn | you'll love rbasak more when he writes a new uvtool based one for juju 2.0 | 05:18 |
| blahdeblah | hallyn: I most certainly owe you a six-pack of $PREFERRED_BEVERAGE | 05:19 |
| hallyn | well gawsh, all i did was find it not write it, but i'm not turning down $PREFERRED_BEVERAGE :) | 05:19 |
| blahdeblah | 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:20 |
| hallyn | :) | 05:21 |
| blahdeblah | And I most certainly will owe rbasak double if he does a juju 2 version. :-) | 05:21 |
| hallyn | +1 | 05:21 |
| kjackal_ | Good morning juju world! | 07:10 |
| kjackal_ | SaMnCo: I am almost there | 07:30 |
| === frankban|afk is now known as frankban | ||
| Spaulding | gday! | 09:20 |
| rbasak | 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. | 09:39 |
| SDBStefano | hi, I'm new to juju, I following the doc, and I tried to create a test charm using | 10:11 |
| SDBStefano | 'charm create -t python mycharm' | 10:11 |
| SDBStefano | but the lib dir was not created | 10:11 |
| SDBStefano | any suggestions ? | 10:11 |
| kjackal_ | Hi SDBStefano havent tried this template before. Let me give it a try now | 10:13 |
| herb64 | 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 |
| herb64 | searching for some option --insecure like in nova | 10:16 |
| herb64 | running rc3 version now | 10:16 |
| kjackal_ | herb64: have you asked on #openstack-charms ? | 10:17 |
| herb64 | hi, kjackal, no.. would this be the better place to ask? | 10:17 |
| kjackal_ | herb64: I believe so, since your question is rather specific | 10:19 |
| kjackal_ | SDBStefano: yeap it does not create a lib dir | 10:20 |
| kjackal_ | SDBStefano: Why did you expect such a directory? Did you read this somewhere? | 10:20 |
| kjackal_ | SDBStefano: this bug should be related: https://bugs.launchpad.net/charm-tools/+bug/1395560 | 10:23 |
| mup | Bug #1395560: "create -t python " does not install lib/charmhelpers <Juju Charm Tools:Triaged> <https://launchpad.net/bugs/1395560> | 10:23 |
| SDBStefano | hi kjackal_, first thanks a lot for helping, yes here : http://pythonhosted.org/charmhelpers/getting-started.html | 10:28 |
| SDBStefano | I'm using : charm version charm 2.2.0-0ubuntu1~ubuntu16.04.1~ppa2 charm-tools 2.1.4 | 10:33 |
| SDBStefano | so it seems to be a problem, not already solved, am I wrong ? | 10:40 |
| kjackal_ | yeap, you are right SDBStefano | 10:43 |
| SDBStefano | is there any other way to get the python library (charm-helpers) ? as a tar or something else | 10:45 |
| kjackal_ | 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:53 |
| kjackal_ | SDBStefano: if you build your charm using layers you can just use the basic layer and you should be done | 10:54 |
| SDBStefano | so, are you saying that I don't need the charm-helpers ? | 10:54 |
| kjackal_ | 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:54 |
| kjackal_ | SDBStefano: by using the basic layer you are importing the charmhelpers | 10:55 |
| SDBStefano | so it seems that I have to proceed and see how to use charm layers | 10:55 |
| SDBStefano | ok, thanks, I'm going to try | 10:56 |
| kjackal_ | 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:56 |
| kjackal_ | SDBStefano: for example https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/basic.py#L36 | 10:58 |
| SDBStefano | I'm going to follow your suggestion and looking at how to use the layers | 10:58 |
| kjackal_ | SDBStefano: yeap that is the right way to go, you will get alot of functionality for free | 10:58 |
| SDBStefano | thanks a lot. out of curiosity I'm in Italy, where are you ? | 10:59 |
| kjackal_ | Athens Greece | 11:00 |
| kjackal_ | SDBStefano: We are almost on the same timezone, ping me again if you get into trouble | 11:00 |
| === Guest10825 is now known as zeus` | ||
| === zeus` is now known as zeus | ||
| SDBStefano | kjackal - I was looking at https://jujucharms.com/docs/devel/authors-charm-building that talks about layers | 13:38 |
| SDBStefano | but it describe bash scripts | 13:38 |
| SDBStefano | but if I understood the good direction is having all python as the github you adviced | 13:39 |
| SDBStefano | so is this doc https://jujucharms.com/docs/devel/developer-getting-started fine ? | 13:39 |
| SDBStefano | or should I follow only the info within the github ? | 13:39 |
| hallyn | 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:00 |
| hallyn | 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:01 |
| rbasak | 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:04 |
| rbasak | eg. by putting either the client or the "machine" in a container. | 14:05 |
| hallyn | right. i was just trying to badger you into doing it :) | 14:05 |
| rbasak | Then as far as Juju is concerned your manual provider machine is somewhere else, and you can create KVMs on it? | 14:05 |
| hallyn | 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:06 |
| rts-sander | my upgrade-charm hook froze so I killed it manually via the PID | 14:07 |
| rts-sander | now the state is in upgrading still | 14:07 |
| rts-sander | how do I reset the state of the unit? | 14:07 |
| kjackal_ | SDBStefano: here is an example of layers in python https://jujucharms.com/docs/2.0/developer-layer-example | 14:11 |
| kjackal_ | SDBStefano: this give a good description of what layers are: https://jujucharms.com/docs/2.0/developer-layers | 14:13 |
| rts-sander | looks like the hook has a timeout, it's now in an error state and I can recover it | 14:24 |
| bildz | 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:33 |
| bildz | http://pastebin.com/qBtDJsyd | 14:34 |
| bildz | i have 6 machines, do I need 7? | 14:35 |
| gQuigs | if I'm using the juju stable ppa on trusty.. how do I switch back to "juju 1"? | 14:42 |
| gQuigs | the instructions on first launch don't work | 14:42 |
| lazyPower | gQuigs i'm looking into this for you, 1 moment while i spin up a vanilla trusty image | 15:14 |
| lazyPower | gQuigs looks like the meta package has updated to 2.0, i'm not seeing a 1.x package anymore | 15:20 |
| gQuigs | so I guess the help text could say, if you want juju1.25 remove juju and the PPA and install it from trusty.. | 15:26 |
| lazyPower | gQuigs: that does appear to be the case. let me nuke this image and try again without adding the ppa | 15:28 |
| lazyPower | 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:30 |
| lazyPower | gQuigs with that ppa enabled, if you install juju-core, you will get 1.25 | 15:37 |
| gQuigs | lazyPower: intersting.. yup, I had to remove juju-2.0 juju juju-core | 15:51 |
| gQuigs | and then reinstall juju-core and I'm back to 1.25 | 15:51 |
| gQuigs | lazyPower: thanks! | 15:51 |
| lazyPower | gQuigs at one time you could update-alternatives, i'm not certain thats still the case | 15:51 |
| lazyPower | 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 |
| gQuigs | should there be a PPA specific helptext? | 15:52 |
| gQuigs | yea, I'm happy having separate machines for 1.x vs 2.x | 15:52 |
| lazyPower | gQuigs : what would the help text say? | 15:52 |
| gQuigs | lazyPower: currently it says this: http://pastebin.ubuntu.com/23324079/ | 15:53 |
| lazyPower | ahhh yeah thats stale | 15:54 |
| lazyPower | thank you for capturing that. I'll file a bug | 15:54 |
| gQuigs | 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:54 |
| lazyPower | 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 |
| lazyPower | 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 |
| gQuigs | lazyPower: I was about to say I can file it :) | 15:55 |
| lazyPower | perfect :) Thanks for tracking this down. | 15:55 |
| pmatulis | lazyPower, gQuigs: please open a docs issue with the relevant info to have a docs change - https://github.com/juju/docs/issues/new | 15:56 |
| gQuigs | pmatulis: oh is that a docs bug? | 15:57 |
| gQuigs | the help text in juju? | 15:58 |
| lazyPower | pmatulis you bet, i'll xref w/ the core bug. | 15:58 |
| lazyPower | that way if any action needs to be taken on either side we have a work order for it | 15:58 |
| gQuigs | reported - https://bugs.launchpad.net/juju/+bug/1633542 | 16:01 |
| mup | Bug #1633542: Juju 2.x upgrade [ppa] doesn't show a workable way to downgrade to 1.25 <juju:New> <https://launchpad.net/bugs/1633542> | 16:01 |
| gQuigs | should I report to gh to? | 16:02 |
| lazyPower | 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:02 |
| gQuigs | do I need more permissions to link them? (I can ling ubuntu bugs to other trackers...) | 16:07 |
| gQuigs | gh is https://github.com/juju/docs/issues/1470 | 16:07 |
| lazyPower | thanks for the bugs gQuigs, just putting in the link is enough. | 16:08 |
| === frankban is now known as frankban|afk | ||
| hallyn | if i have an empty .jenv file, preventing bootstrap, how should i re-init a new one? | 17:11 |
| hallyn | (if i just delete it, then juju bootstrap panics) | 17:11 |
| hallyn | oops, nm, had to s/_/-/ in google-provided creds for juju | 17:27 |
| hallyn | (which juju should probably know about and just dtrt) | 17:28 |
| vance | can i specify which machine in MAAS the juju controller will deploy to? | 18:39 |
| === vance is now known as vmorris | ||
| === vmorris is now known as vance | ||
| === vance is now known as vmorris | ||
| jhobbs | vance, with juju 2, when you're bootstrapping you can use --to <maas machine name> | 18:41 |
| vmorris | jhobbs: thanks, i was just reading that in the docs. appreciate it | 18:42 |
| === 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 | ||
| cory_fu | 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 |
| petevg | Cool. Taking a look ... | 19:57 |
| cory_fu | 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 | 19:58 |
| petevg | 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 |
| petevg | 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:12 |
| petevg | What say you two to giving a +1 on merging the glitch branch, and then I'll create a new branch for integration? | 20:13 |
| bcsaller | petevg: let me do a quick pass over it, but yeah, that will be fine | 20:14 |
| petevg | 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:15 |
| cmars | bdx, hi, are you around? | 20:23 |
| bildz | mtr green.5thcolumn.net | 20:27 |
| cory_fu | 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 |
| petevg | cory_fu: no objection. I've already moved glitch there. | 21:04 |
| cory_fu | bcsaller: Your current implementation uses a dot-path resolver, but I feel like entry-points are both more standard and easier to maintain | 21:05 |
| cory_fu | But I'm up for arguments to the contrarry | 21:06 |
| cory_fu | *contrary | 21:06 |
| bcsaller | cory_fu: I am fine with entry points, maybe as well, but I find the dot-path style to be less friction | 21:10 |
| petevg | 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 |
| bcsaller | 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 | 21:11 |
| === verterok` is now known as verterok | ||
| petevg | bcsaller: cool. | 21:12 |
| cory_fu | petevg: I don't think main.py or __init__.py would matter to entry-points. | 21:12 |
| petevg | cory_fu: I thought that entry-points really liked to have a __main__.py; I am most likely just being wrong :-") | 21:13 |
| cory_fu | Nope | 21:13 |
| cory_fu | They just need a pointer in some module's setup.py | 21:13 |
| petevg | Got it. | 21:13 |
| cory_fu | 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 |
| cory_fu | *resolver | 21:14 |
| bcsaller | 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 |
| cory_fu | Plus to standardize how 3rd party libraries registered their plugins, so it wasn't just all ad-hoc | 21:15 |
| bcsaller | in that context there may not be a setup.py | 21:15 |
| cory_fu | Hrm. Yeah, fair enough | 21:16 |
| cory_fu | bcsaller: Ok, fine, I leave well enough alone. :) | 21:16 |
| bcsaller | ha | 21:17 |
| cory_fu | I was just tired of seeing yet-another-dotted-path-resolver-implementation | 21:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
