[00:27] <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:36] <pmatulis> hallyn, s/juju.ubuntu.com/jujucharms.com/  :P
[00:36] <pmatulis> https://jujucharms.com/docs/1.25/reference-constraints
[00:46] <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:48] <pmatulis> ;)
[00:49] <pmatulis> hallyn, kindly open a bug if the documentation is lacking - https://github.com/juju/docs/issues/new
[00:55] <hallyn> lolz - i see, i can't use local kvm provider anyway without systemd.  drat.
[00:56] <hallyn> curses!
[02:29] <lazyPower> hallyn what are you working on that you need juju 1.25 and upstart bidniss?
[02:41] <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 :)
[03:35] <hallyn> 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] <hallyn> you know, to avoid uvtool become OBSOLETE.  yeah, i'll goad him into it.  bound to work
[05:16] <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:17] <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:18] <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> you'll love rbasak more when he writes a new uvtool based one for juju 2.0
[05:19] <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:20] <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:21] <hallyn> :)
[05:21] <blahdeblah> And I most certainly will owe rbasak double if he does a juju 2 version. :-)
[05:21] <hallyn> +1
[07:10] <kjackal_> Good morning juju world!
[07:30] <kjackal_> SaMnCo: I am almost there
[09:20] <Spaulding> gday!
[09:39] <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.
[10:11] <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:13] <kjackal_> Hi SDBStefano havent tried this template before. Let me give it a try now
[10:16] <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:17] <kjackal_> herb64: have you asked on #openstack-charms ?
[10:17] <herb64> hi, kjackal, no.. would this be the better place to ask?
[10:19] <kjackal_> herb64: I believe so, since your question is rather specific
[10:20] <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:23] <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:28] <SDBStefano> hi kjackal_, first thanks a lot for helping, yes here : http://pythonhosted.org/charmhelpers/getting-started.html
[10:33] <SDBStefano> I'm using : charm version charm 2.2.0-0ubuntu1~ubuntu16.04.1~ppa2 charm-tools 2.1.4
[10:40] <SDBStefano> so it seems to be a problem, not already solved, am I wrong ?
[10:43] <kjackal_> yeap, you are right SDBStefano
[10:45] <SDBStefano> is there any other way to get the python library (charm-helpers) ? as a tar or something else
[10:53] <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:54] <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:55] <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:56] <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:58] <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:59] <SDBStefano> thanks a lot. out of curiosity I'm in Italy, where are you ?
[11:00] <kjackal_> Athens Greece
[11:00] <kjackal_> SDBStefano: We are almost on the same timezone, ping me again if you get into trouble
[13:38] <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:39] <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 ?
[14:00] <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:01] <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:04] <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:05] <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:06] <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:07] <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:11] <kjackal_> SDBStefano: here is an example of layers in python https://jujucharms.com/docs/2.0/developer-layer-example
[14:13] <kjackal_> SDBStefano: this give a good description of what layers are: https://jujucharms.com/docs/2.0/developer-layers
[14:24] <rts-sander> looks like the hook has a timeout, it's now in an error state and I can recover it
[14:33] <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:34] <bildz> http://pastebin.com/qBtDJsyd
[14:35] <bildz> i have 6 machines, do I need 7?
[14:42] <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
[15:14] <lazyPower> gQuigs i'm looking into this for you, 1 moment while i spin up a vanilla trusty image
[15:20] <lazyPower> gQuigs looks like the meta package has updated to 2.0, i'm not seeing a 1.x package anymore
[15:26] <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:28] <lazyPower> gQuigs: that does appear to be the case. let me nuke this image and try again without adding the ppa
[15:30] <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:37] <lazyPower> gQuigs with that ppa enabled, if you install juju-core, you will get 1.25
[15:51] <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:52] <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:53] <gQuigs> lazyPower: currently it says this: http://pastebin.ubuntu.com/23324079/
[15:54] <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:55] <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:56] <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:57] <gQuigs> pmatulis: oh is that a docs bug?
[15:58] <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
[16:01] <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:02] <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:07] <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:08] <lazyPower> thanks for the bugs gQuigs,   just putting in the link is enough.
[17:11] <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:27] <hallyn> oops, nm, had to s/_/-/ in google-provided creds for juju
[17:28] <hallyn> (which juju should probably know about and just dtrt)
[18:39] <vance> can i specify which machine in MAAS the juju controller will deploy to?
[18:41] <jhobbs> vance, with juju 2, when you're bootstrapping you can use --to <maas machine name>
[18:42] <vmorris> jhobbs: thanks, i was just reading that in the docs. appreciate it
[19:57] <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:58] <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
[20:12] <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:13] <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:14] <bcsaller> petevg: let me do a quick pass over it, but yeah, that will be fine
[20:15] <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:23] <cmars> bdx, hi, are you around?
[20:27] <bildz> mtr green.5thcolumn.net
[21:04] <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:05] <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:06] <cory_fu> But I'm up for arguments to the contrarry
[21:06] <cory_fu> *contrary
[21:10] <bcsaller> cory_fu: I am fine with entry points, maybe as well, but I find the dot-path style to be less friction
[21:11] <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:12] <petevg> bcsaller: cool.
[21:12] <cory_fu> petevg: I don't think main.py or __init__.py would matter to entry-points.
[21:13] <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:14] <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:15] <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:16] <cory_fu> Hrm.  Yeah, fair enough
[21:16] <cory_fu> bcsaller: Ok, fine, I leave well enough alone.  :)
[21:17] <bcsaller> ha
[21:17] <cory_fu> I was just tired of seeing yet-another-dotted-path-resolver-implementation