=== defunctzombie is now known as defunctzombie_zz === Beret- is now known as Beret === _mup__ is now known as _mup_ === CyberJacob|Away is now known as CyberJacob === defunctzombie is now known as defunctzombie_zz === DarrenS is now known as Guest82988 === thumper is now known as Guest68473 === CyberJacob is now known as Guest78532 === Tm_T is now known as Guest51964 === ehg_ is now known as Guest31819 === Guest68473 is now known as thumper === thumper is now known as Guest83673 === _thumper_ is now known as thumper === sidnei` is now known as sidnei === Guest78532 is now known as CyberJacob === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === CyberJacob is now known as CyberJacob|Away === Guest31819 is now known as ehg === CyberJacz is now known as CyberJacob === CyberJacob is now known as Guest45596 === virusuy is now known as Guest73883 === virusuy is now known as Guest51645 [12:06] ahasenack: what part of the documentation were you missing? [12:07] marcoceppi: relation-* commands, env vars that are available [12:07] searching for relation-set turned up a blog post, to give you an idea [12:07] in the search box from the juju documentation page [12:07] ahasenack: okay. well need to make a charm author reference doc soon [12:08] yep [12:08] and it still talks about debug-hooks as if they exist [12:08] I filed a bug about that yesterday, but for some reason it got filed in juju-core, not juju-core/docs, so I marked it as invalid and didn't file a new one [12:11] ahasenack: thanks. you'll need to target the docs series on juju-core for doc bugs [12:12] probably need to clarify that. tagging docs should work too [12:18] marcoceppi: I really miss manpages for the tools [12:19] marcoceppi: find myself trying to read go to get the command line options of the tools [12:21] marcoceppi: so this is the url to file a bug report about the docs? https://bugs.launchpad.net/juju-core/docs/ the report a bug link? [12:32] ahasenack: that should be it [12:33] marcoceppi: so that link is https://bugs.launchpad.net/juju-core/docs/+filebug [12:33] marcoceppi: but when I click on it, the page that loads is https://bugs.launchpad.net/juju-core/+filebug [12:34] ahasenack: there's a bug for manpages too against Juju-core [12:34] ahasenack: thanks. I'll update the docs [12:34] marcoceppi: yeah, that one I think I filed [12:35] marcoceppi: so I don't see how doc bugs are different from juju-core bugs, given that url redirect [12:36] I think it auto fills the targeted series when you report. need to verify though [12:37] as soon as I figure out the sandbox URL for lp [12:48] ok, lemme try to file the bug about debug-hooks, let's see what happens [12:48] marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1198169 that's what it became [12:48] I don't know where to set it to "docs" [12:48] <_mup_> Bug #1198169: debug-hooks should be removed from juju-core documentation === med_ is now known as Guest39539 === amithkk is now known as Guest79504 === ahasenack is now known as Guest28536 === Guest51964 is now known as Tm_T [14:08] I have an upgrade-charm question [14:08] hm [14:08] freenode in trouble === benji__ is now known as benji [14:27] What's your upgrade question? [14:28] wedgwood_: Do you have an opinion on https://bugs.launchpad.net/charm-helpers/+bug/1195634? The alternative is separate functions for magic & non-magic & different-magic. [14:28] <_mup_> Bug #1195634: Better magic for write_file [14:28] * wedgwood_ looks [14:29] stub: that's old stuff from spads' original library. I would personally prefer to separate that out to core.template (or contrib.template) and give people an option of template formats. [14:31] stub: and I don't really think the magic is better than non-magic [14:31] wedgwood_: That sort of sounds like a +1 for proceeding the way I suggest === Guest28536 is now known as ahasenack === wedgwood_ is now known as wedgwood [14:33] stub: yes, I suppose it is :) [14:33] Just didn't want to waste any time if another approach was preferred ;) === makyo_ is now known as Makyo === defunctzombie_zz is now known as defunctzombie [15:45] Hmm: error: unknown constraint "instance-type" [15:45] It is supposed to be supported according to the documentation, but it fails after replacing juju with juju-core [15:47] mariusko_: you can't use instance-type with juju-core at present [15:47] just give the cpu/mem characteristics of the sort of machine you want [15:48] Ah ok [15:48] Same problem with amazon region. How would that be workaround? [15:49] invalid value "ec2-zone=a" for flag --constraints: unknown constraint "ec2-zone" [15:49] region isn't a constraint, you just put "region" in your config [15:50] ah not sure for availabilty zone [15:50] can you file a bug on that one? [15:51] Hmm, it is critical to support HA [15:52] Hmm: https://bugs.launchpad.net/juju-core/+bug/1183831 [15:52] <_mup_> Bug #1183831: ec2 constraints missing [15:53] it's also a little wonky as a constraint, because you'd really want different units of the same service across several availabilty zones, no? [15:54] Japp, that is true [15:54] you can leave a comment on that bug if you've anything to add [15:54] I think at the least we should recognize the constraint and print an error saying it's gone on purpose rather than just professing ignorance [15:55] It is actually a workaround by adding haproxy-a, haproxy-b etc and relating them accordingly and placing them in different zones [15:55] For me it is a blocker for moving from juju to juju-core... [15:55] right, which I think is an argument for just adding it, and getting a better solution later [15:55] Japp [16:02] mgz: https://bugs.launchpad.net/juju-core/+bug/1183831/comments/4 [16:02] <_mup_> Bug #1183831: ec2 constraints missing [16:03] Should it be reopened? === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie [18:25] hi, i just installed ubuntu server with Virtual Machine Host and want to deploy some virtual machine with juju [18:25] is there any documentation on that [18:25] ? [18:26] nxvl: try these? https://juju.ubuntu.com/docs/ [18:26] hmm, there is no easy to find link from home page [18:26] thanks [18:27] will take a look [18:27] oh, wait, yes have seen that, it talks about AWS, HP OpenStack and MAAS, but no ubuntu server virtual machine host [18:28] nxvl: basically, do a 'local' deploy? [18:28] JoseeAntonioR: that uses lxc, not kvm [18:28] AFAICT [18:29] erm, yes [18:30] jcastro: ^^ [18:30] nxvl: he's on holidays [18:31] oh [18:38] nxvl: lxc is not supported in juju-core yet [18:39] ahasenack: yeah i don't like lxc anyways [18:39] nxvl: So juju does orchestration, it doesn't do provisioning [18:40] You'll need a provisioner (in this case AWS, HP, etc are provisioners) for "bare metal" you can use MAAS (or virtual MAAS which is just MAAS on virtual machines) [18:40] The only real "provisioner" Juju has (had, coming back soon to juju-core) was the local provider meant for development and testing purposes [18:41] There's an "ssh provider" coming soon which will allow you to provision any hardware/machine via SSH, which might be of interest to you if MAAS doesn't fit what you're looking for [18:41] nxvl: this may also be useful: http://jujucharms.com/~virtual-maasers/precise/virtual-maas [18:41] Until then MAAS is essentially your only "bare metal" option [18:42] you'll be running actual programs several layers of emulation deep, so it won't be quick.. [18:42] marcoceppi: right, so the thing is: i will be using AWS for final deployment of the app, but i want firt test and write my charms "locally", for that i have 1 physical server where i want to deploy my test environment using juju so i can develop my internal charms [18:43] nxvl: Right, so unfortuantely at this time the local provider is the only way to do so (outside of MAAS, but that requires more than one piece of hardware) When the SSh provider lands you'd be able to just "deploy" to that machine without needing any prerequisites [18:43] so basically i need to test/develop on one machine that will emulate AWS [18:44] nxvl: You need to test/develop on a machine that utilizes a "provider" level that Juju knows how to talk with - if you're going to be testing the charm [18:44] so, what if i hear about this juju charm awesomeness and i want to test it before i mess with my AWS cloud? [18:45] i basically can't? [18:45] we sysadmins are quite grumpy when it comes to playing with live infrastructure [18:45] nxvl: You'll just need to use a provider juju knows how to talk to. AWS, HP Cloud, OpenStack, LXC (local provider), or MAAS [18:45] We plan to add the "here's a machine deploy this charm" provider, but that's not ready yet [18:46] aka, the SSH Provider [18:46] nxvl: Set up a few KVM machines, and PXE boot them off a MAAS VM. [18:46] but ahasenack just told me that juju-core does not supports lxc [18:46] nxvl: what jpds isn't too difficult, if you've got the time. I was able to cobble together VirtualBox machines with MAAS so straight KVM would be easier [18:46] nxvl: MAAS VM != LXC, I use KVM. [18:47] yeah i prefer kvm [18:48] nxvl: so, clarification, the local provider will actually create the "VMs" for you. Where as with MAAS you enlist machines for MAAS to use, then juju will turn them on and deploy to them when it needs to. Two different providers [18:48] jpds: so, what you are saying is: install a KVM machine with MAAS main server and then PXE boot a couple of other machine as MAAS nodes and be happy? [18:48] nxvl: Yes. [18:48] nxvl: Then point juju at the MAAS main server. [18:49] jpds: that's why i like you so much! How is London? [18:49] nxvl: Todo bien. [18:50] marcoceppi: i don't mind creating the MAAS VMs for testing purposes and then leverage on AWS to do that, that's fine [18:51] Then that would be a fine route to go. The docs on MAAS+Juju are a little light so if you get stuck feel free to pop back in here, I'm sure we can find someone to help you out [18:54] I do MAAS+juju in VMs all the time. [20:14] jamespage, i through up 3 MPs to charm-helpers, all of which are required to support the new openstack templating stuff [20:14] adam_g, ack - I'll look on monday [20:15] cool, thanks === ppetraki_ is now known as ppetraki === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie [21:30] marcoceppi: hey, have a sec so check my code? [21:30] s/so/to === Guest45596 is now known as Guest45596|Away === Guest45596|Away is now known as CyberJacob === CyberJacob is now known as Guest42928 === Guest42928 is now known as Guest42928|Away