=== gary_poster is now known as gary_poster|away [06:32] can someone shed some light on this bug? https://bugs.launchpad.net/juju-core/+bug/1261780 [06:32] <_mup_> Bug #1261780: go 1.1.2 TLS-enabled client does not accept our CACert [06:37] bashok: ignoring the fact that the question is about node.js :) ... http://stackoverflow.com/a/14090402/377270 [06:45] sarnold, thanks for the pointer, does it mean that my cert needs to have subjectAltName that points to the IP in the URI, [06:47] i'm pretty sure you can't use ip addresses in subjectAldNames [06:47] but it's been a while [06:48] bashok: I don't know if the request is being made by IP or not, but if it is, that would make sense to try [06:49] davecheney: I don't know if future RFCs removed the ability, but RFC 2818 says in part, "In some cases, the URI is specified as an IP address rather than a [06:49] hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI." [06:49] sarnold, thanks i will give a try to that [06:50] sarnold: right [06:50] thanks [06:50] this would only be for self signed certs [06:51] no CA would sign a cert for an IP [06:52] hahaha [06:52] davecheney: man I hope you're right :) [06:52] course worse things have happened.. === CyberJacob|Away is now known as CyberJacob === _thumper_ is now known as thumper === CyberJacob is now known as CyberJacob|Away [09:47] Hi all [09:47] I'm a bit new to juju .. and I have a basic question [09:48] What is the difference/relationship between openstack and juju [09:48] ? [09:52] is it based in anyway on openstack?? [09:57] Shamaria, its not based on openstack. Juju sits a layer above openstack [09:57] Juju is an orchestration layer, that interfaces with your provisioner and deployer [09:58] lazypower: thanks for the answer [09:59] Anytime [09:59] so, does it require the presence of openstack? [09:59] for any reason? [09:59] Nope. It runs on HPCloud, AWS, Azure, and has support for LXC Containers via the local provider. [09:59] Its important to know you can deploy openstack with juju - since I left it off that last list. [10:00] interesting! [10:00] so it is good to have tool anyway! [10:01] That it is. I encourage you to head over to jujucharms.com and interface with the demo gui to get a feel for what it can offer you [10:01] I've seen a list of supported applications, they call it charms [10:02] that can be delpoyed for me [10:02] which very good [10:02] I will take the venture and try it [10:02] Yep, and anything that's not there you can write a charm for in your deployer of choice. Whether that be shell script, ansible, chef, compiled bins. [10:02] Wow [10:03] lazypower: I'm really glad talking to you today [10:03] Glad I could be of help. If you have any questions don't hesitate to ask [10:03] sure I will :) ... what is the best place to get stared? [10:04] I'm assuming you're running Ubuntu on a rig with at least 8gb of ram and 20gb of free disk space? [10:04] not really, but I'll handle such requirement [10:04] I got started with the local provider - https://juju.ubuntu.com/docs/config-local.html [10:05] does it need all the 8GB of ram?? [10:06] Only if you're planning on deploying 3+ services on a local provider configuration [10:06] I see [10:06] it runs quite well on AWS small instances [10:07] v.nice [10:07] actually i'm playing with virtual machines and null environment :D [10:07] ya! [10:07] Hows that coming ashipika? I haven't taken a look at the null provider in about a month. I htinkt hey just pushed another rev this week didn't they? [10:08] it's going great.. [10:09] one last question friends ... is the MAAS to Juju is like Hypervisor to Openstack?? [10:09] i created two images.. a "controller" image and a "compute" image.. controller is automatically bootstrapped when it starts (and has at least 5GB of persistence partition - labeled casper-rw) and when i boot up a compute VM (again with at least 5GB of persistence) it automatically adds itself to the juju environment.. [10:09] awesome :) [10:09] you can check it out here: xmaas.xlab.si (no connection to maas) [10:09] just writing a short tutorial for our guys [10:09] Shamaria, Correct. Maas is a provisioner, same as the hypervisor. [10:10] only, it works with bare metal not virtual machines. [10:10] u mean real servers? [10:10] Correct [10:10] and can't be VMs [10:10] yes.. read servers [10:10] Oh .. I see [10:11] well, dont say can't be vm's [10:11] LOOL .. I get you [10:11] because as I understand it, there is support for LXC containers coming to MAAS in the future [10:11] no ETA on it from me though, because its from the rumor mill at this point. [10:11] but MAAS requires you to have a separate network, because it needs to set up its own DHCP and DNS servers [10:11] I want to play with MAAS so bad, i just dont have the setup for it. [10:12] try my images.. close to maas, but not quite :) [10:12] and it works in VMs [10:12] that's great to hear ... isn't MAAS a base rquirement for Juju? [10:12] that juju can't work without? [10:12] Tell ya what ashi, when I'm not writing a plan for reducing cost of ownership on a network I'll do that. [10:13] Shamaria, incorrect. Juju is independent of MAAS [10:13] when mass is needed then [10:13] ? [10:13] only when you want to provision bare metal servers.. [10:13] and deploy your services on the [10:13] When you want to use MAAS as a provisioner, it would assume the role that one of the other providers is assuming (Read: AWS, HPCloud, LXC, Etc.) [10:13] them\ [10:14] does this mean juju uses a similar architecutre of openstack's?? [10:15] database, rabbitmq, ... [10:15] etc. [10:15] juju can deploy those for you.. [10:15] It uses a controller unit, rabbitmq, zookeeper, mongodb. [10:15] so not quite like openstack [10:15] but the same idea [10:15] i'm going to disclaim this - i'm not an openstack expert by *any* sense of the phrase [10:16] so take my comparisons with a grain of salt and maybe some light research. [10:16] Ok [10:16] openstack does not deploy services for you, does it? [10:16] it is an IAAS [10:16] i dont think so [10:16] yes [10:17] so it doesn't help you providing any service [10:17] juju deploys services and does orchestration in a beautiful way :) [10:17] exactlly [10:17] but it helps managing your cloud of servers [10:17] Yes [10:17] That's what I newly knew :) [10:18] so if you say juju deploy something it will by default as the provider to provision a new machine.. unless you specify --to option that lets you decide where you want to deploy stuff [10:19] so, can I make use of virtual cloud machines to be that new machine? [10:19] yep [10:19] yup [10:19] so it can be utilized on top of openstack [10:19] that;s really good [10:19] yes [10:20] why Juju is not that famous [10:20] or use maas if you have some extra machines around [10:20] does it have bugs or it is unreliable in any way? [10:20] ashipika: Yes [10:21] well.. it is in development.. so yes, expect some bugs.. i stumbled upon a few while testing.. but the good thing is that development is really active and bugs get fixed quickly [10:21] Shamaria, its gaining steam. The best part of juju is the quality gating through the charm store [10:22] your work will not be listed as public unless it passes the community review process [10:22] This works for building block charms, i'm helping a company here in Pittsburgh onboard with juju for their proprietary stuff since the orchestration just "makes sense" [10:24] I see [10:24] what is the mature similar application out there, I'm talking about open source ones? [10:24] I think the big draw for juju is the gui, and the fact you're not tied to a specific framework for your deployer. [10:24] br [10:24] b [10:24] The wordpress charm works really well, discourse, mongodb [10:25] I'm getting pretty close to pushing a release candidate for errbit [10:26] I thought Juju's power is its GUI [10:26] what do you mean by "specific framework for your deployer"?? [10:26] The gui is slick, but everything you do in the gui you can do with the CLI [10:26] of course [10:26] Meaning you're not tied to just chef, or ansible, or bash. [10:27] you can literally use whatever deployer framework you want [10:27] is that a bad thing? [10:27] nope, its flexible [10:27] yep [10:28] brb [10:28] the only thing i REALLY miss in GUI is the --to option [10:33] I'm back [10:33] One very important question [10:34] after installaing some architecture with the required connections between the apps [10:34] then I decided for any reason to uninstall the juju [10:34] yes? [10:34] will this affect by any mean the installed architecture [10:34] well.. no.. unless juju gets stuck destroying a unit or something.. [10:35] I don't think that's recommended. You can power down the controller unit when its not in use to help reduce overhead costs if thats you're concern [10:35] but i would say that really depends on the charms you deploy [10:37] lazypower: do i understand correctly that i must subscribe "charmers" if i want a charm to go through the review process? [10:38] Correct [10:38] https://juju.ubuntu.com/docs/authors-charm-store.html [10:39] in-case you need a refresher. [10:39] hello guys , i wonder after I installed ceph-radosgw, how do i test it from cli? [10:41] lazypower: , ashipika: one point is still not so clear to me ... is it possible that MAAS will consider VMs as bare-metals [10:42] i never played with VMs and MAAS.. since it uses PXE boot to provision new machine it need to set up its own DHCP server or change the existing one -> our admins would go bat-crazy if i tried that.. so i created a dedicated network just for MAAS testing.. [10:43] Shamaria, http://www.slideshare.net/openstackindia/maas-juju-introduction [10:43] this makes you opt for the virtualization [10:44] really good set of slides over Juju, Maas, and whats capable at a high level. [10:44] moreover, there must be a way to disable the isntallation of DHCP and DNS servers [10:47] lazypower: the presentation you sent means yes [10:47] MAAS can handle cloud instances as bare metal [10:48] Did I get it right? [10:48] Not a MAAS expert, last i tried maas it wanted bare metal. [10:48] i think theres a VMAAS coming down the tube, but its going to be experimental if its available [10:49] what if I wanted to deploy the service on multiple VMs [10:49] what shall be done [10:49] will I have to handle this manually? [10:50] Depends on the provider. If you're using one of the supported providers - no. It talks to the provider via their API and spins up a new server, bootstraps it, and then loads your service [10:50] if you're going with the null provider, provisioning machines is a manual process [10:51] I'm afraid I have a very basic question ... what is the provider ? [10:52] Juju supports provider environments. Think of the provider as whatever service is going to be "providing" your machines. If thats bare metal, virtual, or otherwise. [10:54] I see your point [10:54] do you have examples of providers? [10:54] Shamaria: as i wrote earlier.. if you want to play with VMs you can always try the images at xmaas.xlab.si and the null environment/provider [10:55] it also gives you the option of creating bootable CD/USB, plug it into a machine and have it "bare metal" [10:55] i.e. without virtualization [10:55] ashipika: Yes, you already said that .. exuese my novelty :) [10:55] Thanks a lot [10:56] ashipika, bookmarked for later :) [10:56] hahaha [10:56] > /dev/null :D [10:56] LOL [10:59] lazypower: , ashipika: I really thank you both a lot [10:59] I learned much from you today [10:59] Anytime. Happy to help [10:59] I'll keep returning to this room [10:59] Shamaria: you're welcome.. i'm just a juju beginner myself [11:00] but you helped a lot :) [11:00] You both have a really good day/night === morty_ is now known as morty === gary_poster|away is now known as gary_poster === BradCrittenden is now known as bac [13:53] Hei guys anyone care to test this charm for me https://bugs.launchpad.net/charms/+bug/795480 [13:53] <_mup_> Bug #795480: Charm needed: Trac === kirkland` is now known as kirkland [15:17] jcastro: remember when you used to be able to get PNGs of a juju deployment [15:17] was that in jitsu? [15:17] it wasn't png's it was a gource thing [15:17] we just piped status to gource [15:17] or do you mean like a picture of a deployment? I don't think we ever did that did we? [15:18] jcastro: we def did. I can't remember if it was juju status --format=png or if it was in jitsu [15:19] huh [16:18] marcoceppi, ok here we go [16:18] jcastro: where are we going! [16:18] I am going to test negronjl's sharding mongo config via the local provider [16:19] * marcoceppi holds breath [16:19] jcastro: good luck ( you'll need it ) :) [16:29] negronjl, load is 10! [16:30] jcastro: never tested it on local provider ... better you than me :P [16:30] yeah [16:30] it's not bad [16:30] machine is totally usable [16:31] load is now 15 and climbing [16:37] negronjl, dude, it's working [16:37] well, well on its way to working [16:37] jcastro: cool === medberry is now known as med_ [16:47] Nice! You're swamping me already, i only deployed 12 units [16:47] 3 shards, x repls + config servers + arbiter [16:48] Let me see your YAML when you're done please === Guest26569 is now known as Kyle [19:26] jorge@jilldactyl:~$ sudo juju bootstrap [19:26] ERROR cannot use 37017 as state port, already in use [19:26] marcoceppi, any ideas there? [19:32] hi fwereade [19:32] any idea why I would get this: [19:32] jorge@jilldactyl:~$ sudo juju bootstrap [19:32] ERROR cannot use 37017 as state port, already in use [19:32] jcastro: it means you've already got juju-db running [19:32] oh ok [19:32] so restart it? [19:32] initctl list | grep juju [19:33] sounds like a bad destroy [19:33] it is not running [19:33] but yeah, probably a bad destroy [19:33] something is using that port, what does ps -aef | grep mongo show? [19:33] jcastro, yeah, that sounds most likely [19:33] mongod is using the port [19:33] do I stop or restart it? [19:33] jcastro, if you set api-port and state-port you should be able to run multiple local providers fwiw [19:33] stop it [19:34] when I stop it it seems to fire back up [19:34] jcastro: ohhhhhh [19:35] jcastro: these are probably per user upstart jobs [19:35] maybe not, idk if juju is using thatyet [19:35] what does sudo initctl list | grep juju show? [19:36] http://paste.ubuntu.com/6722577/ [19:37] jcastro: yeah, sudo stop juju-db-root-local [19:37] jcastro: then [19:37] jcastro: I want you to try something different [19:37] ok [19:37] don't use sudo during bootstrap [19:43] jcastro: the suspense is killing me [19:47] ok [19:47] errors out with the normal "sudo must be used" [19:48] jcastro: ah, damn. Thought something magically had happened [19:48] should I try to sudo bootstrap again? [19:49] jcastro: yes [19:49] ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused [19:49] * thumper looks briefly at chatter [19:49] you guys tring to get multiple local providers working on one machine? [19:49] no [19:49] thumper: no, just one [19:49] oh [19:49] I am trying to get one local working [19:50] jcastro: try your good 'ol .jenv dump [19:50] jcastro: what is the tl;dr of the situation? [19:50] I ran out of disk space [19:51] so I added a drive and remounted /var/lib/lxc [19:52] ERROR environment is already bootstrapped [19:52] when I try to bootstrap, but there are no containers running [19:52] delete the local.jenv ? [19:52] yep [19:52] jcastro: are you looking for the definitive list of shit to delete? [19:52] jcastro: rm -f /etc/init/juju-* ? === CyberJacob|Away is now known as CyberJacob [19:53] there are to init files in /etc/init, one for the machine agent and one for the mongo db [19:53] there is a file in /etc/rsyslog.d for the logging [19:53] there are the containers defined in /var/lib/juju/containers [19:53] there are the containers themselves in /var/lib/lxc [19:53] there is the directory in ~/.juju/ [19:54] there is the .jenv file in ~/.juju/environments [19:54] nuke all those [19:54] * marcoceppi makes notes [19:54] which is the file for mongo? [19:54] * thumper looks [19:54] mongodb.conf? [19:55] nope [19:55] /etc/init/juju-db--.conf [19:55] /etc/init/juju-agent--.conf for the machine agent [19:56] should I move back to 1.16.5? [19:56] /etc/rsyslog.d/25-juju--.conf [19:56] jcastro: this hasn't really changed between 1.16.5 and 1.17 [19:56] sigh [19:56] this never works for me [19:57] I'll just skip this and come back to it [19:58] I'm supposed to be reviewing 2 charms a day, not one charm in 2 days! [19:58] :-( === freeflying is now known as freeflying_away